Uma aplicação web é migrada de um ambiente on-premises para a AWS. A API de terceiros que ela chama permite que apenas um único bloco CIDR público seja incluído na lista de permissões por cada cliente. A aplicação web será executada em instâncias EC2 em sub-redes privadas, atrás de um ALB em sub-redes públicas. Gateways NAT fornecem acesso à internet para as instâncias privadas. Como o arquiteto deve garantir que a API de terceiros continue aceitando chamadas da aplicação migrada usando o mesmo bloco de IP do cliente?

A resposta correta é registrar um bloco de endereços IP públicos de propriedade do cliente na conta AWS, alocar IPs elásticos desse bloco e atribuí-los aos Gateways NAT. Isso garante que todo o tráfego de saída das instâncias EC2 privadas para a internet (incluindo a API de terceiros) origine-se de um IP dentro do bloco de IPs do cliente, atendendo ao requisito de lista de permissões da API. Associar um bloco de IPs públicos à VPC e habilitar endereçamento público nas sub-redes públicas não funcionaria, pois o tráfego de saída das instâncias privadas ainda passaria pelos IPs dos Gateways NAT, que não seriam do cliente. Criar IPs elásticos do bloco do cliente e atribuí-los ao ALB também não resolve, pois o ALB é um ponto de entrada, não de saída para a API de terceiros. Usar o AWS Global Accelerator com IPs elásticos do cliente seria uma solução complexa e desnecessária para este requisito específico de IP de saída.