Два акаунти AWS, одна локальна мережа: який шлях?
Спільний Transit Gateway, два незалежні VPN або один вузький проксі: обирайте за володінням і масштабом наслідків, а не за тим, який маршрут найлегше додати сьогодні.
Очевидна рамка — peering проти VPN, і це неправильна рамка. Під'єднаний через peering VPC не може позичити VPN-з'єднання сусіда для маршрутизації від краю до краю, тож цей варіант ніколи не розглядався, хоч би що підказувала таблиця маршрутів. Насправді ви обираєте між спільним мережевим концентратором, двома незалежними шляхами VPN і вузьким входом застосунку. Кожен відповідає на своє питання про те, кому належить маршрутизація.
Три варіанти і той, який не варіант
Почніть з видалення ідеї peering, потім порівняйте решту за володінням, а не за простотою схеми. Таблиця нижче — рішення у стиснутому вигляді.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
Якщо акаунту A потрібен доступ до всієї локальної мережі, рядок із проксі має неправильну форму. Якщо акаунту A потрібен один API, перші два рядки — це більше мережі, ніж просила вимога.
Коли перемагає спільний Transit Gateway
Transit Gateway під'єднує кожну VPC і VPN як окремі мережі, а спільне використання між акаунтами дозволяє власникам VPC користуватися концентратором без об'єднання акаунтів. У цьому привабливість: одне місце, де локальні префікси зустрічаються з мережами AWS, і одне місце, де можна обміркувати, яке під'єднання вивчить який маршрут.
Під'єднати все не означає дозволити все. Асоціація і поширення визначають, яке під'єднання використовує яку таблицю маршрутів, тому два префікси VPC можуть кожен досягти локального сервісу, тоді як їхній взаємний доступ залишається виключеним дизайном концентратора. Локальній стороні все ще потрібні зворотні маршрути для префіксів AWS, і це заявка на зміну іншої команди.
Вартість організаційна не меншою мірою, ніж фінансова. Власник концентратора керує маршрутними відносинами, від яких залежать інші команди, тому зміна одного під'єднання може перемістити трафік сервісу, про який власник концентратора ніколи не чув. Години під'єднання й обробка даних додаються з кожною мережею, яку ви під'єднуєте, тому концентратори зазвичай ростуть швидше за команду, яка ними керує.
Коли перемагають окремі VPN або вузький проксі
Два незалежні VPN підходять для невеликого розгортання з реальними операційними межами: кожен акаунт змінює свої тунелі, і жоден не може зламати інший, редагуючи таблицю маршрутів. Обмеження на локальній стороні. Парному шлюзу потрібна ємність для додаткових тунелів, плани адрес не повинні перетинатися, а двом конфігураціям, що анонсують однакові префікси, потрібна навмисна перевага, а не надія.
Проксі — найвужчий інтерфейс. Якщо акаунту A потрібна одна база даних або один API в акаунті B, обмежений посередник дає визначений вхід із власною історією автентифікації, журналювання та доступності. Це й варіант, який найчастіше використовують неправильно: посередник, що пересилає до кожного приватного призначення, став необмеженим реле з зайвими кроками, і він не поводитиметься як прозора передача з VPC у локальну мережу ні для чого іншого.
Обмеження peering для VPC варто прочитати до всього цього, бо вони пояснюють, чому четверта ідея повертається знову і знову і чому вона не може працювати.
Виберіть найвужчий інтерфейс, що задовольняє вимогу
Упорядкуйте питання: чи потрібна A мережа, набір мереж або один сервіс? Чи хоче локальна команда один шлях чи кілька? Кому дозволено змінювати маршрутизацію трафіку іншої команди? Перша відповідь, що дає найвужчий інтерфейс, — це архітектура, а все після неї — реалізація.
Запишіть відповідь разом із планом префіксів, володінням маршрутами, інвентарем тунелів або під'єднань і режимом відмови, якого очікує кожна сторона. Коли хтось пізніше запитає, чому акаунт A не може просто використати VPN акаунта B, цей запис і буде відповіддю, і він позбавить вас повторного обговорення тих самих трьох варіантів у наступному проєкті.