Een grote onderneming draait workloads in VPC's over honderden AWS-accounts. Elke VPC heeft publieke en private subnets over meerdere AZ's; NAT gateways in publieke subnets bieden internettoegang voor private subnets. In een hub-and-spoke-ontwerp moeten alle private subnets in spoke VPC's internet-gebonden verkeer verzenden via een NAT gateway die zich bevindt in een gecentraliseerde egress VPC in een centraal account. Er bestaat al een NAT gateway in die egress VPC. Welke aanvullende stappen moet de solutions architect nemen om aan de vereiste te voldoen?

De correcte optie is het maken van een AWS Transit Gateway en deze delen met de andere AWS-accounts. Dit is de schaalbare en aanbevolen methode voor het verbinden van honderden VPC's in een hub-and-spoke-architectuur. De Transit Gateway fungeert als een centrale hub, waardoor alle spoke VPC's via één punt met de egress VPC kunnen communiceren en internetverkeer via de centrale NAT Gateway kunnen routeren. VPC peering is onpraktisch voor honderden VPC's vanwege het beheer van point-to-point verbindingen en routingtabellen, en schaalt niet goed. Een transit gateway maken in elk account is inefficiënt en duur, en lost het centrale egress-probleem niet op. AWS PrivateLink is bedoeld voor private connectiviteit tussen services en niet voor algemene internet-egress voor VPC's.