Спільний 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 в іншому. Коли проєкт потребує підключення й робочого навантаження в одній зоні, порівняйте ID AZ і запишіть їх.
Порівняння назв дає схему, що виглядає правильно, і профіль затримки, який таким не є. Перевірте це, поки схема ще малюється, а не після того, як хтось виміряв різницю.
Скасування спільного доступу не розриває шлях даних
Видалення спільного доступу відчувається як відкликання, і це не миттєва зупинка трафіку. AWS документує, що підключення залишається працездатним, коли шлюз виходить зі спільного доступу. Дозвіл керувати ресурсом зникає, а наявне підключення продовжує переспрямовувати, доки хтось його не видалить або не вимкне. Плануйте відкликання у два кроки: видаліть спільний доступ, потім підключення, і другий виконує власник.
Якщо спільний доступ — ваш єдиний контроль, у вас немає контролю.
Тримайте запис про спільний доступ і запис маршрутизації разом
Два артефакти відповідають на два різні питання. Запис про спільний доступ каже, хто може працювати з ресурсом. Таблиці маршрутів кажуть, які мережі справді можуть спілкуватися. Зберігайте їх разом з одним і тим самим списком власників, інакше наступний інцидент почнеться з того, що хтось доводить дозвіл, який ніколи не був проблемою.
Потім перевірте один потік у кожному напрямку й один префікс, що має залишитися недосяжним.