Une application existante a été migrée vers AWS et s'exécute sur trois instances EC2 (une dans chacune des trois AZ) dans des sous-réseaux privés. Ces instances sont des cibles pour un Application Load Balancer (ALB) dans trois sous-réseaux publics. L'application doit appeler des systèmes sur site qui n'acceptent le trafic que d'une seule adresse IP d'entreprise. L'équipe de sécurité n'a apporté que cette seule IP au cloud et a alloué une Elastic IP pour celle-ci. La solution doit permettre à l'application d'atteindre les systèmes sur site et de gérer automatiquement les défaillances. Quelle conception répond à ces exigences ?

La bonne réponse est de déployer une seule passerelle NAT dans un sous-réseau public et de lui attribuer l'Elastic IP. Cette approche centralise le trafic sortant via une seule adresse IP, répondant à l'exigence des systèmes sur site. L'utilisation de CloudWatch avec une métrique personnalisée et d'une fonction Lambda permet une reprise automatique en cas de défaillance de la passerelle NAT, en la recréant et en réaffectant l'Elastic IP. Les autres options sont incorrectes car : Déployer trois passerelles NAT ne répond pas à l'exigence d'une seule adresse IP source pour le trafic vers les systèmes sur site. Remplacer l'ALB par un NLB et lui attribuer l'Elastic IP ne fonctionnerait pas car l'ALB est pour le trafic entrant et les instances EC2 sont dans des sous-réseaux privés, nécessitant une passerelle NAT pour le trafic sortant vers l'extérieur d'AWS. Attribuer l'Elastic IP à l'ALB est incorrect car l'ALB gère le trafic entrant, pas le trafic sortant vers les systèmes sur site.