Транзитный шлюз в Account A используется совместно через AWS RAM, чтобы другие аккаунты могли подключать VPC в том же регионе. В Account B есть VPC (10.0.0.0/16) с подсетями 10.0.0.0/24 (us-west-2a) и 10.0.1.0/24 (us-west-2b). Были добавлены две новые подсети: 10.0.2.0/24 (us-west-2b) и 10.0.3.0/24 (us-west-2c). Все подсети используют одну и ту же таблицу маршрутизации; маршрут по умолчанию 0.0.0.0/0 указывает на транзитный шлюз. Ресурсы в 10.0.2.0/24 могут достигать других VPC, но ресурсы в 10.0.3.0/24 не могут. Что должен сделать инженер, чтобы ресурсы в 10.0.3.0/24 могли достигать других VPC?

Правильный ответ заключается в обновлении присоединения транзитного шлюза в Account B, чтобы включить подсеть us-west-2c. При присоединении VPC к транзитному шлюзу необходимо указать по одной подсети из каждой зоны доступности, которую VPC будет использовать для связи с транзитным шлюзом. Если подсеть 10.0.3.0/24 находится в новой зоне доступности (us-west-2c), которая ранее не была связана с присоединением транзитного шлюза, то трафик из этой подсети не сможет достичь транзитного шлюза. Добавление ID подсети us-west-2c к присоединению VPC обеспечивает маршрутизацию трафика из этой подсети через транзитный шлюз. Неправильные варианты: Добавление маршрутов в таблицу маршрутизации VPC для 10.0.2.0/24 и 10.0.3.0/24 не требуется, так как маршрут по умолчанию 0.0.0.0/0 уже указывает на транзитный шлюз, что должно быть достаточно, если присоединение транзитного шлюза настроено правильно. Добавление статического маршрута для 10.0.3.0/24 в таблицы маршрутизации транзитного шлюза в Account A не решит проблему, так как проблема заключается в невозможности трафика из 10.0.3.0/24 достичь самого транзитного шлюза. Пересоздание распространения для 10.0.0.0/16 в таблицах маршрутизации транзитного шлюза в Account A не поможет, поскольку распространение уже должно охватывать весь CIDR VPC, и проблема не в маршрутизации внутри транзитного шлюза, а в подключении к нему.