Une application web est migrée d'un environnement sur site vers AWS. L'API tierce qu'elle appelle n'autorise qu'un seul bloc CIDR public à être mis sur liste blanche par chaque client. L'application web s'exécutera sur des instances EC2 dans des sous-réseaux privés derrière un ALB dans des sous-réseaux publics. Les passerelles NAT fournissent un accès Internet aux instances privées. Comment l'architecte doit-il s'assurer que l'API tierce continue d'accepter les appels de l'application migrée en utilisant le même bloc d'adresses IP client ?

La bonne réponse est d'enregistrer un bloc d'adresses IP publiques appartenant au client auprès du compte AWS, d'allouer des adresses IP Elastic à partir de ce bloc et d'attribuer ces adresses IP Elastic aux passerelles NAT dans le VPC. Les passerelles NAT sont le point de sortie pour le trafic des instances privées vers Internet. En associant des adresses IP Elastic (EIP) provenant du bloc CIDR du client aux passerelles NAT, tout le trafic sortant vers l'API tierce utilisera ces EIP, garantissant ainsi que l'API tierce voit une adresse IP source unique et autorisée. L'option d'associer un bloc d'adresses IP publiques au VPC et d'activer l'adressage IP public sur les sous-réseaux publics est incorrecte car les instances sont dans des sous-réseaux privés et le trafic sortant passe par les passerelles NAT. L'attribution d'EIP statiques à l'ALB est incorrecte car l'ALB est un point d'entrée, pas de sortie, pour le trafic des instances privées vers l'API tierce. L'utilisation d'AWS Global Accelerator est une solution de performance et de routage, pas une méthode pour contrôler l'adresse IP source du trafic sortant des instances privées via les passerelles NAT.