Pojedyncza sieć VPC ma podsieci publiczne i prywatne w dwóch strefach dostępności. Statyczna zawartość witryny (obrazy) jest przechowywana w Amazon S3. Serwery WWW to instancje EC2 w prywatnych podsieciach, w grupie Auto Scaling za ALB. Środowisko wykorzystuje Direct Connect z publicznym VIF do dostępu do S3. Inżynier sieci odkrywa, że ruch EC2-do-S3 przechodzi przez bramę NAT, zwiększając koszty wraz ze wzrostem ruchu. Jak inżynier powinien zmienić łączność, aby uniknąć opłat za bramę NAT dla ruchu S3?

Poprawna odpowiedź to zaimplementowanie bramowych punktów końcowych VPC (gateway VPC endpoints) dla Amazon S3 i zaktualizowanie tabeli routingu VPC. Bramowe punkty końcowe VPC umożliwiają instancjom EC2 w prywatnych podsieciach dostęp do S3 bez przechodzenia przez bramę NAT lub publiczny internet. Ruch pozostaje w sieci AWS, eliminując koszty NAT Gateway dla tego ruchu. Niepoprawne opcje: Utworzenie prywatnego VIF Direct Connect: Prywatny VIF jest przeznaczony do dostępu do prywatnych zasobów VPC (np. instancji EC2) z sieci lokalnej, a nie do dostępu instancji EC2 do usług AWS, takich jak S3. Utworzenie tunelu AWS Site-to-Site VPN przez istniejący publiczny VIF: VPN jest używany do bezpiecznego łączenia sieci lokalnych z VPC i nie rozwiązuje problemu ruchu EC2-do-S3 w ramach VPC. Zaimplementowanie interfejsowych punktów końcowych VPC (interface VPC endpoints) dla Amazon S3: Interfejsowe punkty końcowe są oparte na technologii AWS PrivateLink i tworzą interfejsy sieciowe (ENI) w podsieciach. Chociaż działają dla wielu usług, S3 obsługuje bramowe punkty końcowe, które są bardziej odpowiednie i często tańsze dla tej usługi.