У меня есть 3 веб-сервера (экземпляры ec2) в общедоступной подсети vpc, и все они имеют EIP.
У меня есть обычный интернет-шлюз с маршрутом, чтобы эти экземпляры могли вызывать внешние службы, и балансировщик нагрузки (ELB), чередующий входящий трафик между этими экземплярами.
Основная проблема заключается в том, что приложение на серверах будет подключаться к множеству внешних сервисов / API, но для некоторых из этих сервисов требуется белый список IP. Теперь мы назначаем EIP экземпляру, переходим на панель управления указанной службы, добавляем новый EIP и продолжаем работать, но мы достигли предела, как по количеству EIP, доступных для нашей учетной записи (да, Я знаю, что это можно изменить, но все же) и сколько IP-адресов внесено в белый список этих внешних служб.
Учитывая, что мы хотели бы сохранить автоматическое масштабирование, я хотел бы попросить идеи о том, как маршрутизировать весь генерируемый экземпляром трафик через один EIP без потери текущей внутренней работы. Фиксированный специальный маршрут к этим сервисам не очень гибкий, если он не будет использовать DNS, в основном потому, что мы не можем заранее знать все их пулы IP-адресов.
Я читал о шлюзах NAT, но я не уверен, что часть архитектуры балансировки нагрузки останется включенной, смогут ли веб-серверы отвечать на запросы и т. Д.
Да, вы можете использовать шлюз NAT. или экземпляр NAT в сочетании с ELB ... и это наиболее разумный способ занести в белый список исходящий трафик, инициированный изнутри, с внешними службами.
Шлюз NAT всегда имеет статический общедоступный IP-адрес.
Вы должны [...] указать эластичный IP-адрес для связи со шлюзом NAT при его создании.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html
Эта конфигурация требует, чтобы экземпляры НЕ имели собственных общедоступных IP-адресов и НЕ находились в общедоступной подсети с маршрутом по умолчанию, указывающим на Интернет-шлюз. Маршрут по умолчанию для подсети экземпляра должен указывать на устройство NAT после его настройки.
В свою очередь, это означает, что ваш ELB не может находиться в той же подсети, что и экземпляры, поскольку подсеть ELB ДОЛЖНА иметь интернет-шлюз в качестве маршрута по умолчанию.
Трафик ответов от экземпляров направляется на внутренний IP-адрес ELB, поэтому на него не влияет маршрут подсети экземпляров по умолчанию, поэтому эта конфигурация не прерывает трафик ответов на запросы ELB.
Как ни странно это кажется некоторым, это стандартная конфигурация для размещения ELB в разных подсетях от экземпляров, стоящих за ними. В отличие от обычной сети, где маршрутизатор может быть узким местом, здесь не учитывается отрицательная производительность, связанная с тем, что ELB и его сбалансированные экземпляры находятся в разных подсетях друг от друга. Вся сеть VPC представляет собой программно определяемую виртуальную сеть, поэтому нахождение в разных подсетях не означает, что трафик будет проходить через ненужный маршрутизатор, как это было бы в физической сети Ethernet. Весь трафик между экземплярами проходит по одинаковому пути через инфраструктуру VPC.
Смотрите также Зачем нужны частные подсети в VPC? о переполнении стека.
Хорошие новости - Amazon добавила для этого новый тип балансировщика нагрузки (Network Load Balancer). Вы можете назначить ему эластичный IP-адрес и вуаля - статический IP-адрес для балансировщика нагрузки!
Он работает по протоколу TCP, а не по HTTP, поэтому вы не можете использовать SSL на балансировщике нагрузки (каждому веб-серверу потребуется сертификат), и у него нет опции «Прилипчивость» (но она очень липкая). В остальном он работает так же, как балансировщик нагрузки «Приложение».