Duże przedsiębiorstwo uruchamia obciążenia w VPC w setkach kont AWS. Każda VPC ma publiczne i prywatne podsieci w wielu strefach dostępności (AZ); bramy NAT w publicznych podsieciach zapewniają dostęp do Internetu dla prywatnych podsieci. W architekturze hub-and-spoke wszystkie prywatne podsieci w spoke VPC muszą wysyłać ruch wychodzący do Internetu przez bramę NAT znajdującą się w scentralizowanej egress VPC na koncie centralnym. Brama NAT już istnieje w tej egress VPC. Jakie dodatkowe kroki powinien podjąć architekt rozwiązań, aby spełnić to wymaganie?

AWS Transit Gateway to skalowalne rozwiązanie do łączenia tysięcy VPC i kont AWS. Umożliwia scentralizowane zarządzanie routingiem ruchu sieciowego, co jest kluczowe w architekturze hub-and-spoke. Tworząc Transit Gateway i dołączając do niego wszystkie VPC (egress VPC jako hub, pozostałe jako spoke), można skonfigurować tabele routingu tak, aby cały ruch wychodzący z prywatnych podsieci spoke VPC był kierowany do bramy NAT w egress VPC. Pozostałe opcje są mniej efektywne lub nieodpowiednie: Połączenia VPC peering są zarządzane indywidualnie i nie skalują się dobrze do setek VPC, co prowadziłoby do złożonej i trudnej w zarządzaniu siatki połączeń. Tworzenie Transit Gateway na każdym koncie jest nieefektywne i sprzeczne z ideą scentralizowanego zarządzania ruchem. AWS PrivateLink służy do prywatnego dostępu do usług, a nie do routingu ruchu internetowego przez centralną bramę NAT.