Ein großes Unternehmen betreibt Workloads in VPCs über Hunderte von AWS-Konten hinweg. Jede VPC verfügt über öffentliche und private Subnetze in mehreren AZs; NAT-Gateways in öffentlichen Subnetzen bieten Internetzugang für private Subnetze. In einem Hub-and-Spoke-Design müssen alle privaten Subnetze in Spoke-VPCs den Internet-gebundenen Datenverkehr über ein NAT-Gateway senden, das sich in einer zentralen Egress-VPC in einem zentralen Konto befindet. Ein NAT-Gateway existiert bereits in dieser Egress-VPC. Welche zusätzlichen Schritte sollte der Lösungsarchitekt unternehmen, um die Anforderung zu erfüllen?

Die korrekte Lösung ist die Verwendung eines AWS Transit Gateways. Dies ist die empfohlene Methode für die zentrale Verwaltung der Konnektivität zwischen Hunderten von VPCs in einer Hub-and-Spoke-Architektur. Das Transit Gateway ermöglicht es, alle Spoke-VPCs mit der Egress-VPC zu verbinden und den gesamten Internetverkehr über das zentrale NAT-Gateway zu leiten, was die Verwaltung vereinfacht und Kosten spart. VPC-Peering-Verbindungen wären bei Hunderten von VPCs unübersichtlich und schwer zu skalieren, da jede Spoke-VPC eine Peering-Verbindung zur Egress-VPC benötigen würde. Ein Transit Gateway in jedem Konto würde die Komplexität erhöhen und den Zweck einer zentralen Egress-VPC untergraben. AWS PrivateLink ist für den Zugriff auf Services innerhalb von AWS gedacht, nicht für den allgemeinen Internetzugang über ein NAT-Gateway.