Una aplicación web se migra de un entorno on-premises a AWS. La API de terceros a la que llama solo permite que cada cliente incluya en la lista blanca un único bloque CIDR público. La aplicación web se ejecutará en instancias EC2 en subredes privadas detrás de un ALB en subredes públicas. Las NAT gateways proporcionan acceso a Internet para las instancias privadas. ¿Cómo debe asegurarse el arquitecto de que la API de terceros siga aceptando llamadas de la aplicación migrada utilizando el mismo bloque de IP de cliente?

La opción correcta garantiza que todo el tráfico saliente hacia la API de terceros provenga de un bloque CIDR único y conocido. Al registrar un bloque de IP públicas propiedad del cliente (BYOIP) en AWS y asignar EIPs de ese bloque a las NAT gateways, todas las instancias EC2 en subredes privadas que acceden a Internet a través de esas NAT gateways presentarán una dirección IP de origen dentro del bloque BYOIP. Esto permite que la API de terceros incluya en la lista blanca un único bloque CIDR. Las otras opciones son incorrectas porque: Asociar un bloque de IP públicas a la VPC y habilitar el direccionamiento IP público en subredes públicas no es aplicable a las instancias en subredes privadas que usan NAT gateways para el acceso a Internet. Asignar EIPs estáticas del bloque BYOIP al ALB no es relevante para el tráfico saliente de las instancias privadas. El ALB maneja el tráfico entrante. Usar AWS Global Accelerator con EIPs del bloque BYOIP y establecer el ALB como endpoint es para optimizar el acceso de los clientes a la aplicación, no para controlar la IP de origen del tráfico saliente de la aplicación a una API de terceros.