Высокая доступность и AWS VPN

У меня вопрос о достижении высокой доступности через AWS VPN.

Контекст:

У меня есть требование установить VPN-соединение между сайтами между моим AWS VPC и большой корпорацией. Эта ссылка VPN требуется для поддержки входящих HTTP-подключений к приложению в моем AWS VPC. По разным причинам большая компания, к которой я подключаюсь, не выделит мне неконфликтную частную (RFC1918) подсеть для использования. Вместо этого они требуют, чтобы я использовал NAT, чтобы предоставлять свои услуги через VPN на публичном IP-адресе по моему выбору (тот, который я зарезервировал). Я считаю, что мне удалось успешно настроить это (при условии тестирования) с правильной комбинацией правил маршрутизации, следуя этот guide (без отдельного прокси), однако я могу направлять входящие соединения только на один IP.

Вопрос:

Мне интересно, есть ли способ, которым я могу вместо этого направить подключения к высокодоступному балансировщику нагрузки? Это обеспечит лучшую масштабируемость, а также высокую доступность. Я рассмотрел:

Использование AWS внешний ELB:
- У них нет надежных IP-адресов или достаточно узкого диапазона. Я не смог бы добавить такой диапазон в правила маршрутизации с правой стороны, поскольку такой диапазон может конфликтовать с любым другим сервисом, размещенным на AWS.
Использование AWS внутренний ELB:
- У них есть общедоступная DNS-запись и предсказуемый диапазон, однако они находятся в частных диапазонах IP-адресов и поэтому не могут использоваться клиентской системой, поскольку им разрешено создавать статические маршруты только к общедоступным IP-адресам, отличным от RFC1918.
Реализация собственного балансировщика нагрузки, такого как HAproxy:
- Это решит проблему масштабируемости, но все же оставит единственную точку отказа в системе (сам узел высокой доступности).
- Кроме того, это еще одна машина, которую мне нужно обслуживать.

Кто-нибудь знает, есть ли способ ссылаться на ELB в таблицах маршрутизации VPC? Или есть другие предложения, как этого добиться?

Спасибо

Машина, завершающая туннель, уже является единственной точкой отказа, не так ли? Если это так, запуск HAProxy прямо здесь кажется правильным (и я говорю об этом не только потому, что я так делаю, хотя это так).

Я могу подсчитать сбои в производстве, вызванные haproxy, на одной руке, не используя никаких пальцев (или большого пальца). Асинхронный DNS в версии 1.6 (все еще находящейся в разработке на момент написания этой статьи) позволит вам использовать внутренний ELB в качестве серверной части для haproxy, что позволит вам в значительной степени установить, забыть и использовать существующие интеграции ELB / EC2 для фактического масштабирования емкости. .

Типы экземпляров C3, C4, M3, R3 и T2 также поддерживают относительно новые восстановление экземпляра , которая останавливает, воссоздает и перезапускает ваш экземпляр на другом оборудовании, но с тем же идентификатором экземпляра, эластичным IP-адресом и томами EBS, если он перестает положительно реагировать на проверки работоспособности экземпляра.