Starsza aplikacja została zmigrowana do AWS i działa na trzech instancjach EC2 (po jednej w każdej z trzech stref dostępności – AZ) w prywatnych podsieciach. Instancje te są celami dla Application Load Balancer (ALB) w trzech publicznych podsieciach. Aplikacja musi wywoływać systemy lokalne, które akceptują ruch tylko z jednego firmowego adresu IP. Zespół ds. bezpieczeństwa przeniósł tylko ten jeden adres IP do chmury i przydzielił mu Elastic IP. Rozwiązanie musi umożliwiać aplikacji dostęp do systemów lokalnych i automatycznie obsługiwać awarie. Który projekt spełnia te wymagania?

Poprawna odpowiedź to wdrożenie pojedynczej bramy NAT w publicznej podsieci z przypisanym Elastic IP. Brama NAT umożliwia instancjom EC2 w prywatnych podsieciach dostęp do Internetu (lub systemów lokalnych poprzez VPN/Direct Connect) przy użyciu jednego publicznego adresu IP. Monitorowanie stanu bramy NAT za pomocą Amazon CloudWatch i niestandardowej metryki, w połączeniu z funkcją AWS Lambda do automatycznego odtwarzania bramy NAT w przypadku awarii, zapewnia wysoką dostępność i spełnia wymaganie automatycznej obsługi awarii. Pozostałe opcje są nieprawidłowe: Wdrażanie trzech bram NAT z Elastic IP jest niepotrzebne i kosztowne, ponieważ ruch do systemów lokalnych musi wychodzić z jednego IP. Ponadto, ręczne tworzenie bramy NAT i przypisywanie Elastic IP nie jest automatyczne. Zastąpienie ALB przez NLB i przypisanie Elastic IP do NLB nie rozwiązuje problemu wychodzącego adresu IP dla instancji EC2, ponieważ NLB jest używany do ruchu przychodzącego. Przypisanie Elastic IP do ALB nie zmienia wychodzącego adresu IP instancji EC2. ALB jest load balancerem dla ruchu przychodzącego.