Une entreprise de télécommunications utilise AWS avec une connexion Direct Connect entre son environnement sur site et AWS. L'application s'exécute sur des instances EC2 dans plusieurs zones de disponibilité (AZ) derrière un ALB interne. Les clients du réseau sur site se connectent à l'application via HTTPS ; TLS se termine au niveau de l'ALB. L'ALB utilise plusieurs groupes cibles et un routage basé sur le chemin. L'entreprise va déployer une appliance de pare-feu sur site qui n'autorise le trafic que vers des adresses IP connues. Quelle solution permettra au trafic sur site d'atteindre l'application et de satisfaire l'exigence de liste d'autorisation du pare-feu ?

La bonne solution consiste à placer un Network Load Balancer (NLB) devant l'Application Load Balancer (ALB) existant. Le NLB peut être associé à des adresses IP statiques (Elastic IPs) dans chaque zone de disponibilité, ce qui répond à l'exigence du pare-feu sur site de n'autoriser le trafic que vers des adresses IP connues. Le NLB peut acheminer le trafic vers un groupe cible dont la cible est l'ALB existant. Cette approche permet de conserver les fonctionnalités de l'ALB, telles que la terminaison TLS et le routage basé sur le chemin, qui ne sont pas prises en charge par un NLB seul. Les clients sur site devront alors se connecter à l'adresse DNS du NLB. L'option d'attribuer des adresses IP statiques directement à l'ALB est incorrecte car les ALB ne prennent pas en charge les adresses IP statiques. Leurs adresses IP peuvent changer dynamiquement. L'option de remplacer l'ALB par un NLB est incorrecte car le NLB ne prend pas en charge la terminaison TLS ni le routage basé sur le chemin, qui sont des exigences de l'application. L'option d'utiliser un Gateway Load Balancer (GWLB) est incorrecte car les GWLB sont conçus pour insérer des appliances de sécurité tierces et non pour exposer directement une application.