Назад | Перейти на главную страницу

Соединение двух регионов AWS: почему бы не использовать два виртуальных частных шлюза?

Я пытаюсь подключить два региона AWS. В документации AWS предлагается запустить экземпляр с обеих сторон для запуска программного обеспечения IPSec (OpenSWAN или StrongSWAN), предоставив обоим экземплярам эластичный IP-адрес и используя его в качестве туннеля. Это все хорошо, но теперь у нас есть единственная точка отказа с обеих сторон.

AWS выпустила Руководство по подключению VPC в июле, в котором подробно описаны возможные варианты подключения двух VPC вместе. Я добавил ссылку на этот PDF-файл на страницу 15, где объясняются параметры.

Каждый параметр, который он перечисляет, имеет существенные недостатки, поскольку в большинстве случаев весь трафик проходит через один (аварийный) экземпляр. Пока что кажется, что лучше всего использовать программный туннель с одной стороны и виртуальный частный шлюз с другой. Говорят, хоть с одной стороны получается избыточность. Это все еще кажется неоптимальным.

Есть ли способ соединить два виртуальных частных шлюза вместе, чтобы получить лучшее из обоих миров - управляемую Amazon избыточность и простоту хранения всего этого в моей конфигурации VPC? Или VGW в основном предназначены только для клиентов?

Нет, в настоящее время невозможно подключить два виртуальных частных шлюза в разных регионах. Я уверен, что это новая функция, поскольку пиринг VPC доступен для VPC в одном регионе.

Что касается «Вы несете ответственность за внедрение решений высокой доступности для всех конечных точек VPN (если требуется)», я обсуждал в предыдущий ответ Существуют различные методы обработки отказа экземпляра VPN / NAT. Недавно я разговаривал с коллегой, который не только настраивал полную сетку VPN с автоматическим масштабированием и сценариями для повторной инициализации отказавших экземпляров VPN / NAT, но также имел дополнительные сценарии, которые изменяли таблицы маршрутов VPC для немедленного перехвата маршрутов другой зоной доступности. пока отказавший экземпляр VPN / NAT не переродился. Они также не смогли выполнить обратный маршрут после того, как экземпляр VPC / NAT был включен и ENI повторно подключился. На github есть много скриптов для мониторинга NAT, которые делают похожие вещи. Также есть Статья AWS который описывает процесс.

Достойная высокая доступность? Да. Простая конфигурация? К сожалению нет.