Firma posiada 20 zespołów serwisowych, każdy we własnym koncie AWS i każdy VPC używający 192.168.0.0/22. Usługi działają na instancjach EC2 za ALB i obecnie komunikują się przez publiczny internet. Dział bezpieczeństwa wymaga teraz, aby cały ruch między usługami wykorzystywał HTTPS przez prywatną sieć, bez routingu przez internet. Rozwiązanie powinno minimalizować zmiany wymagane przez każdy zespół. Które podejście spełnia te wymagania?

Prawidłowa odpowiedź to utworzenie NLB w każdym VPC, udostępnienie ich za pośrednictwem AWS PrivateLink i użycie punktów końcowych VPC. PrivateLink umożliwia prywatną komunikację między usługami w różnych VPC i kontach AWS bez przechodzenia przez publiczny internet, spełniając wymagania bezpieczeństwa. Użycie punktów końcowych VPC minimalizuje zmiany w istniejących aplikacjach, ponieważ mogą one nadal używać nazw DNS, a ruch jest automatycznie kierowany prywatnie. Inne opcje są mniej odpowiednie: Tworzenie nowego konta i VPC z udostępnionymi podsieciami wymagałoby znacznych zmian w każdym z 20 zespołów, aby uruchomić nowe instancje i NLB w udostępnionych podsieciach. VPC peering między 20 VPC stworzyłby złożoną sieć typu "full mesh" (190 połączeń), trudną w zarządzaniu i skalowaniu, a także wymagałby ręcznej aktualizacji tabel routingu w każdym VPC. Użycie bramy tranzytowej (Transit Gateway) jest dobrym rozwiązaniem dla połączeń między VPC, ale nadal wymagałoby konfiguracji routingu i nie zapewnia natywnie prywatnego dostępu do usług w taki sposób, jak PrivateLink, który upraszcza konsumpcję usług.