Un transit gateway nell'Account A è condiviso tramite AWS RAM in modo che altri account possano connettere VPC nella stessa Regione. L'Account B ha un VPC (10.0.0.0/16) con subnet 10.0.0.0/24 (us-west-2a) e 10.0.1.0/24 (us-west-2b). Sono state aggiunte due nuove subnet: 10.0.2.0/24 (us-west-2b) e 10.0.3.0/24 (us-west-2c). Tutte le subnet utilizzano la stessa tabella di routing; la route predefinita 0.0.0.0/0 punta al transit gateway. Le risorse in 10.0.2.0/24 possono raggiungere altri VPC, ma le risorse in 10.0.3.0/24 non possono. Cosa deve fare l'ingegnere affinché le risorse in 10.0.3.0/24 possano raggiungere altri VPC?

La risposta corretta è aggiornare l'attachment del Transit Gateway (TGW) nell'Account B. Quando si crea un attachment VPC al TGW, è necessario specificare almeno una subnet in ogni Zona di Disponibilità (AZ) da cui si desidera instradare il traffico. Sebbene il VPC sia collegato al TGW, le nuove subnet in AZ diverse da quelle inizialmente specificate non saranno automaticamente associate all'attachment. Per consentire alle risorse nella subnet 10.0.3.0/24 (us-west-2c) di raggiungere altri VPC tramite il TGW, è necessario modificare l'attachment del TGW esistente e aggiungere l'ID della subnet 10.0.3.0/24. Le altre opzioni sono errate perché: Aggiungere route nella tabella di routing del VPC non è sufficiente; il TGW deve essere a conoscenza della subnet per instradare il traffico. La route predefinita 0.0.0.0/0 è già presente e punta al TGW. Aggiungere una route statica nel TGW (Account A) non è necessario, poiché il TGW apprende le route dai suoi attachment tramite propagazione. Ricreare la propagazione per 10.0.0.0/16 non risolverebbe il problema, poiché la propagazione funziona solo per le subnet associate all'attachment del TGW.