Два аккаунта 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, эта запись и будет ответом, и она избавит вас от повторного обсуждения тех же трёх вариантов в следующем проекте.