Una aplicación heredada se migró a AWS y se ejecuta en tres instancias EC2 (una en cada una de las tres AZ) en subredes privadas. Estas instancias son destinos para un Application Load Balancer (ALB) en tres subredes públicas. La aplicación debe llamar a sistemas on-premises que aceptan tráfico solo desde una única dirección IP de la empresa. El equipo de seguridad ha traído solo esa IP a la nube y ha asignado una Elastic IP para ella. La solución debe permitir que la aplicación llegue a los sistemas on-premises y gestione automáticamente los fallos. ¿Qué diseño cumple estos requisitos?

La opción correcta establece un único NAT Gateway en una subred pública y le asigna la Elastic IP. Esto asegura que todo el tráfico saliente desde las instancias EC2 hacia los sistemas on-premises utilice la dirección IP estática requerida. El monitoreo con CloudWatch y una función Lambda para recrear el NAT Gateway en caso de fallo, reasignando la Elastic IP, proporciona alta disponibilidad y resiliencia. Las opciones incorrectas son: Implementar tres NAT gateways con la misma Elastic IP no es posible, ya que una Elastic IP solo puede asociarse a una interfaz de red a la vez. Además, la reasignación manual en caso de fallo no es una solución automatizada. Reemplazar el ALB con un NLB y asignarle la Elastic IP no es adecuado porque el tráfico saliente de las instancias EC2 no pasaría por el NLB, sino que requeriría un NAT Gateway para la salida a Internet con una IP estática. Asignar la Elastic IP al ALB no es la solución correcta porque el ALB gestiona el tráfico entrante a las instancias, no el tráfico saliente de las instancias hacia sistemas on-premises.