Общий Transit Gateway: кому принадлежат маршруты в AWS RAM
Совместное использование через RAM позволяет другой учётной записи подключить VPC, но таблицы маршрутов, ассоциации и распространения остаются у владельца шлюза. Вот граница.
Совместное использование Transit Gateway через Resource Access Manager делает одну конкретную вещь: позволяет другой учётной записи вызывать определённый набор API подключения к ресурсу, которым она не владеет. Оно не передаёт шлюз, его таблицы маршрутов или право решать, как перенаправляется трафик. Люди предполагают обратное, потому что подключение появляется в консоли получателя и сразу работает, что ощущается как владение. Механизм в основе — выдача разрешения на общий ресурс, и каждый дочерний объект остаётся в границах учётной записи владельца. Это разделение объясняет большинство обращений об отказе в доступе вокруг общего транзита.
Что совместное использование на самом деле делегирует
Совместное использование ресурса называет ресурс, субъекта и управляемое разрешение. Разрешение перечисляет действия, которые этот субъект может выполнять, и для Transit Gateway этот список охватывает операции подключения к общему ресурсу.
Всё вне списка завершается ошибкой в API, а не в консоли, поэтому ошибка часто появляется при первом запуске скрипта.
Таблицы маршрутов, ассоциации и распространения остаются у владельца
Переадресацию определяют три дочерних объекта: с какой таблицей маршрутов связана ассоциация, в какие таблицы она распространяется и какие маршруты содержат эти таблицы. Документация AWS о совместном использовании указывает, что получатель не может создавать, изменять или удалять таблицы маршрутов транзитного шлюза, а также их ассоциации и распространения через общий доступ. Эти вызовы принадлежат учётной записи владельца. Получатель, которому нужна новая ассоциация, запрашивает административное изменение, а не использует разрешение, которое забыл включить.
Таблица ниже — это разделение, которое я помещаю в проектные документы, потому что оно переживает смену персонала.
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
Прочитайте среднюю строку внимательно: владелец VPC управляет маршрутами своей подсети, владелец шлюза управляет центральным решением о переадресации, и рабочему пути нужно и то и другое. Ни одна из учётных записей не может завершить это в одиночку.
Один путь, две учётные записи
Проследите пакет от spoke VPC до локального префикса. Таблица маршрутов подсети spoke должна отправить этот префикс в подключение транзитного шлюза, что владелец VPC может изменить. Затем у шлюза в связанной таблице подключения должен быть маршрут, указывающий на подключение VPN, и это может изменить только владелец. Обратному трафику нужна зеркальная копия обоих. Пропустите любую сторону, и вы получите наполовину установленный путь, который выглядит как проблема с межсетевым экраном.
Запишите оба изменения в один тикет с двумя ответственными, иначе они будут завершены в разные недели.
Используйте идентификаторы зон доступности, когда размещение важно
Имена зон — это локальные псевдонимы учётной записи. us-east-1a в одной учётной записи не обязательно является той же физической зоной, что и us-east-1a в другой. Когда проекту нужно подключение и рабочая нагрузка в одной зоне, сравните идентификаторы AZ и запишите их.
Сравнение имён даёт схему, которая выглядит правильной, и профиль задержки, который таковым не является. Проверьте это, пока схема ещё рисуется, а не после того, как кто-то измерил разницу.
Отмена совместного использования не разрывает путь данных
Удаление общего доступа ощущается как отзыв, но это не мгновенная остановка трафика. AWS документирует, что подключение остаётся функциональным, когда шлюз перестаёт быть общим. Разрешение управлять ресурсом исчезает, а существующее подключение продолжает переадресацию, пока кто-то не удалит или не отключит его. Планируйте отзыв в два шага: удалите общий доступ, затем подключение, причём второй шаг выполняет владелец.
Если общий доступ — ваш единственный контроль, у вас нет контроля.
Храните запись об общем доступе и запись маршрутизации вместе
Два артефакта отвечают на два разных вопроса. Запись об общем доступе говорит, кто может работать с ресурсом. Таблицы маршрутов говорят, какие сети действительно могут общаться. Храните их вместе с одним и тем же списком владельцев, иначе следующий инцидент начнётся с того, что кто-то доказывает разрешение, которое никогда не было проблемой.
Затем проверьте один поток в каждом направлении и один префикс, который должен остаться недоступным.