Instancje EC2 w prywatnych podsieciach muszą inicjować wszystkie żądania wychodzące, włączając w to ruch do centrum danych on-premises przez Direct Connect. Żadne zasoby zewnętrzne nie mogą inicjować połączeń z tymi instancjami EC2. Brama klienta on-premises używa stanowej zapory sieciowej, która filtruje ruch dla wielu VPC, a firma preferuje użycie pojedynczego dopasowania IP na zaporze, aby zezwolić na cały ruch EC2. Która opcja spełnia wymagania przy najmniejszym nakładzie operacyjnym?

Prawidłowa odpowiedź to wdrożenie bramy NAT (NAT gateway) w prywatnej podsieci i skonfigurowanie zapory sieciowej on-premises, aby zezwalała na połączenia z adresem IP przypisanym do bramy NAT. Instancje EC2 w prywatnych podsieciach mogą inicjować ruch wychodzący przez bramę NAT, która tłumaczy ich prywatne adresy IP na pojedynczy publiczny lub prywatny adres IP bramy NAT. Dzięki temu zapora on-premises potrzebuje tylko jednej reguły zezwalającej na ruch z tego pojedynczego adresu IP, co spełnia wymaganie "pojedynczego dopasowania IP". Brama NAT jest usługą zarządzaną, co minimalizuje nakład operacyjny. Pozostałe opcje są nieprawidłowe: Utworzenie połączenia VPN przez Direct Connect i blokowanie całego ruchu z on-premises do AWS nie pozwala instancjom EC2 na inicjowanie ruchu do on-premises. Konfiguracja zapory sieciowej on-premises do filtrowania wszystkich żądań z on-premises do instancji EC2 nie rozwiązuje problemu pojedynczego dopasowania IP, ponieważ instancje EC2 miałyby wiele prywatnych adresów IP. Wdrożenie instancji NAT (NAT instance) wymaga zarządzania instancją, co zwiększa nakład operacyjny w porównaniu z zarządzaną bramą NAT.