Aplikacja internetowa jest przenoszona z lokalnego środowiska do AWS. Wywoływane przez nią API innej firmy zezwala na umieszczenie na białej liście tylko jednego publicznego bloku CIDR dla każdego klienta. Aplikacja internetowa będzie działać na instancjach EC2 w prywatnych podsieciach za ALB w publicznych podsieciach. Bramy NAT zapewniają dostęp do Internetu dla prywatnych instancji. W jaki sposób architekt powinien zapewnić, że API innej firmy będzie nadal akceptować wywołania z migrowanej aplikacji, używając tego samego bloku IP klienta?

Poprawna odpowiedź zapewnia, że cały ruch wychodzący z prywatnych instancji EC2 do API stron trzecich będzie pochodził z przewidywalnego, statycznego bloku adresów IP należących do klienta. Rejestracja bloku IP klienta w AWS umożliwia przydzielenie adresów Elastic IP z tego bloku. Przypisanie tych EIP do bram NAT sprawia, że bramy NAT używają tych adresów jako źródłowych dla ruchu wychodzącego do Internetu, co pozwala na umieszczenie tego bloku na białej liście przez API strony trzeciej. Pierwsza niepoprawna opcja nie rozwiąże problemu, ponieważ ruch z prywatnych podsieci nadal będzie przechodził przez bramy NAT, które domyślnie używają dynamicznych adresów IP AWS. Trzecia opcja jest błędna, ponieważ ALB obsługuje ruch przychodzący, a nie wychodzący z instancji EC2 do API stron trzecich. Czwarta opcja, choć Global Accelerator może zapewnić statyczne adresy IP, jest przeznaczona głównie do optymalizacji ruchu przychodzącego i nie jest standardowym rozwiązaniem do kontrolowania wychodzących adresów IP z prywatnych podsieci przez bramy NAT w tym scenariuszu.