Un ingegnere di rete ha creato quanto segue per connettere due VPC di produzione in Regioni diverse (Prod A in eu-west-1 con 10.0.0.0/16 e Prod B in eu-central-1 con 10.1.0.0/16): 1) un transit gateway in ogni Regione, 2) ha condiviso e accettato i transit gateway con gli account di produzione, 3) ha creato un peering attachment tra i transit gateway, 4) ha collegato ogni VPC al transit gateway della sua Regione, 5) ha creato tabelle di routing del transit gateway e attachment associati, 6) ha aggiunto route statiche in ogni tabella di routing del transit gateway per inviare il traffico al VPC remoto e 7) ha abilitato la propagazione delle route sulle tabelle di routing del VPC. Le connessioni da Prod A a Prod B non sono riuscite. Cosa dovrebbe fare l'ingegnere per ottenere la connettività richiesta?

Il problema risiede nel routing a livello di VPC. Sebbene i Transit Gateway siano configurati correttamente con peering e routing, i VPC stessi non sanno come raggiungere le subnet remote. L'opzione corretta risolve questo problema aggiungendo una route nella tabella di routing di ogni VPC, puntando al Transit Gateway locale per il traffico destinato al CIDR remoto (10.0.0.0/8 è un intervallo più ampio che include entrambi i CIDR dei VPC, 10.0.0.0/16 e 10.1.0.0/16, garantendo che tutto il traffico tra i VPC utilizzi il TGW). Le altre opzioni sono errate perché: Modificare l'indirizzo IP del peering attachment non è rilevante, poiché gli attachment non hanno indirizzi IP. Eliminare le route statiche nel TGW e abilitare la propagazione delle route non è la soluzione principale, poiché il problema è a livello di VPC. Le route statiche nel TGW sono necessarie per il peering. Modificare le tabelle di routing del TGW per propagare le route dinamicamente tra i VPC non è una configurazione standard e la propagazione avviene tipicamente dagli attachment al TGW, non tra i TGW stessi in questo contesto.