Как я могу использовать статический IP-адрес с Application Load Balancer в режиме высокой доступности?
Я наблюдаю за интеграцией для клиента, и его поставщику требуется несколько IP-адресов для внесения в белый список. Исходный (ые) сервер (ы) - это Elastic Beanstalk Instance, запускаемый балансировщиком нагрузки приложений со всеми настройками через Route53.
Это не сработает, так как вы не можете назначить статический IP-адрес для Application Load Balancers по определению (и мне нужны функции уровня 7).
Я не могу просто передать конкретные запросы поставщику через код и дополнительный экземпляр EC2, потому что это двусторонняя интеграция.
Я прочитал эту статью, но это, откровенно говоря, похоже на хак, а не на то, что я бы делал в производственной среде.
Конечно, мне кажется, что мне нужна какая-то комбинация NLB с ALB, но опять же, в справочной статье представлено множество движущихся частей.
Редактировать:
- Я использую VPC
- Сам экземпляр живет в частной подсети
- ALB живет в общедоступной подсети, и оба имеют необходимую маршрутизацию для связи
- Я почти уверен, что я говорю по кругу, пытаясь убедить себя
Static IP !== Single Point of Failure
1 ответ
В настоящее время существует только один способ связать статические IP-адреса с Application Load Balancer (ALB) - AWS Global Accelerator.
Статические IP-адреса Anycast - Global Accelerator использует статические IP-адреса, которые служат фиксированной точкой входа для ваших приложений, размещенных в любом количестве регионов AWS. Эти IP-адреса являются Anycast из периферийных местоположений AWS. Это означает, что эти IP-адреса объявляются из нескольких периферийных местоположений AWS, что позволяет трафику проникать в глобальную сеть AWS как можно ближе к вашим пользователям. Вы можете связать эти адреса с региональными ресурсами или конечными точками AWS, такими как балансировщики сетевой нагрузки, балансировщики нагрузки приложений и эластичные IP-адреса. Вам не нужно вносить какие-либо клиентские изменения или обновлять записи DNS при изменении или замене конечных точек.
https://aws.amazon.com/blogs/aws/new-aws-global-accelerator-for-availability-and-performance/
Global Accelerator выделяет два статических IP-адреса из двух избыточных внутренних систем AWS, и они уникальны для вашего развертывания - не используются совместно. Они объявляются в Интернете через одноранговые соединения в нескольких местах в пограничной сети AWS (той же сети, в которой работают CloudFront, Route 53 и S3 Transfer Acceleration - у нее больше точек присутствия, чем только в регионах AWS и AWS-управляемые оптоволоконные соединения с регионами). Затем вы связываете конечные точки (ALB, NLB и / или EIP) с экземпляром Global Accelerator, и трафик от пограничного местоположения, куда поступают запросы, направляется NAT вашему балансировщику.
Поскольку устройство использует исходный NAT, вы не можете использовать такие вещи, как исходный IP-адрес клиента или X-Forwarded-For определить IP-адрес клиента в режиме реального времени, но вы можете кросс-коррелировать их позже, используя журналы потока, которые фиксируют кортежи источника / назначения, а также промежуточный адрес NAT, который увидит ваше приложение. Это заметное ограничение, но оно может быть целесообразным, если вам действительно нужны статические IP-адреса для вашей конечной точки - что действительно неизбежно в некоторых корпоративных средах.
Важно отметить, что ALB является только входящим (соединения устанавливаются только снаружи внутрь, независимо от конечного направления передачи данных), поэтому, если ваши серверы также инициируют соединения, вам необходимо отдельное решение для статического адреса источника - NAT Шлюз.
Один шлюз NAT на зону доступности, размещенный в общедоступной подсети, может служить шлюзом по умолчанию для одной или нескольких частных подсетей в зоне доступности, так что все экземпляры в этих подсетях используют один и тот же исходный IP-адрес при обращении в Интернет. NAT Gateway не является черным ящиком в физическом месте - это особенность сетевой инфраструктуры, поэтому он по сути является отказоустойчивым и не рассматривается как единственная точка отказа в пределах одного AZ. Вы можете совместно использовать один NAT-шлюз между зонами доступности, но тогда у вас будет одна точка отказа, если в этой зоне доступности произойдет что-то катастрофическое (и вы будете платить немного больше за транспортировку интернет-трафика через границы AZ по сравнению с размещением одной из них). Шлюз NAT в каждом AZ). NAT-шлюз не требует никаких изменений приложения, потому что это не прокси - это транслятор сетевых адресов, который прозрачен для экземпляров, которые расположены в подсетях, настроенных для его использования. Каждый шлюз NAT имеет статический EIP.
Это расстраивает, потому что нет хорошего способа сделать это, особенно если вы обслуживаете веб-сайт и хотите знать, кто заходит на ваш сайт,
Вариант 1: AWS Global Accelerator - который работает, но удаляет IP-адрес клиента, поэтому вы не будете знать, откуда приходят люди.
Вариант 2: Это действительно неясный метод: https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/ который вкратце требует ELB и ALB и т. д., который нарушает некоторые функциональные возможности в процессе и требует жесткого подхода.
По состоянию на 5/2019 это основные способы сделать это.