Una grande azienda esegue carichi di lavoro in VPC su centinaia di account AWS. Ogni VPC ha sottoreti pubbliche e private su più AZ; i gateway NAT nelle sottoreti pubbliche forniscono accesso a Internet per le sottoreti private. In un design hub-and-spoke, tutte le sottoreti private nei VPC spoke devono inviare il traffico destinato a Internet attraverso un gateway NAT situato in un VPC di egress centralizzato in un account centrale. Un gateway NAT esiste già in quel VPC di egress. Quali passaggi aggiuntivi dovrebbe intraprendere l'architetto di soluzioni per soddisfare il requisito?

La soluzione corretta è AWS Transit Gateway perché è progettato per interconnettere migliaia di VPC e account AWS in modo scalabile e centralizzato, facilitando il routing del traffico tra di essi. Permette di consolidare l'accesso a Internet attraverso un singolo gateway NAT nel VPC di egress, riducendo la complessità di gestione rispetto a molteplici connessioni di peering. Le connessioni di VPC peering (opzione 1) non sono scalabili per centinaia di account, poiché richiedono una connessione diretta tra ogni VPC spoke e il VPC di egress, creando una rete complessa e difficile da gestire (N(N-1)/2 connessioni). Creare un transit gateway in ogni account (opzione 3) è inefficiente e non rispetta il requisito di un gateway NAT centralizzato. AWS PrivateLink (opzione 4) è progettato per l'accesso privato ai servizi, non per il routing del traffico Internet tra VPC.