Inżynier sieciowy utworzył następujące elementy, aby połączyć dwie produkcyjne sieci VPC w różnych regionach (Prod A w eu-west-1 z 10.0.0.0/16 i Prod B w eu-central-1 z 10.1.0.0/16): 1) po jednej bramie tranzytowej (transit gateway) w każdym regionie, 2) udostępnił i zaakceptował bramy tranzytowe z kontami produkcyjnymi, 3) utworzył peering attachment między bramami tranzytowymi, 4) podłączył każdą sieć VPC do bramy tranzytowej swojego regionu, 5) utworzył tabele routingu bram tranzytowych i powiązane załączniki, 6) dodał statyczne trasy w każdej tabeli routingu bramy tranzytowej, aby wysyłać ruch do zdalnej sieci VPC, oraz 7) włączył propagację tras w tabelach routingu VPC. Połączenia z Prod A do Prod B nie powiodły się. Co powinien zrobić inżynier, aby osiągnąć wymaganą łączność?

Poprawna odpowiedź to utworzenie nowej trasy w tabelach routingu VPC. Inżynier poprawnie skonfigurował Transit Gateway i połączenia międzyregionalne, ale zapomniał o trasach w tabelach routingu samych VPC. Aby ruch z VPC A mógł dotrzeć do VPC B, musi istnieć trasa w tabeli routingu VPC A kierująca ruch do Transit Gateway A. Podobnie dla VPC B. Zakres 10.0.0.0/8 obejmuje oba CIDR-y VPC (10.0.0.0/16 i 10.1.0.0/16), co jest efektywnym sposobem na skierowanie całego ruchu wewnętrznego do Transit Gateway. Modyfikacja adresu IP peering attachment jest niepotrzebna, ponieważ peering attachment nie ma adresu IP. Usunięcie statycznych tras i włączenie propagacji tras w Transit Gateway nie rozwiąże problemu braku tras w tabelach routingu VPC. Modyfikacja tabel routingu Transit Gateway w celu dynamicznej propagacji tras między VPC jest nieprawidłowa, ponieważ propagacja tras w Transit Gateway dotyczy załączników, a nie bezpośrednio między VPC.