Я наблюдаю за интеграцией для клиента, и его поставщику требуется несколько IP-адресов для внесения в белый список. Исходный сервер (ы) - это экземпляр Elastic Beanstalk, на который выходит Application Load Balancer со всеми обрезками через Route53.
Это не сработает, поскольку вы не можете назначить статический IP-адрес балансировщикам нагрузки приложений по определению (а мне нужны функции уровня 7).
Я не могу просто проксировать определенные запросы поставщику через код и дополнительный экземпляр EC2, потому что это двусторонняя интеграция.
Я прочитал Эта статья, но, честно говоря, это похоже на взлом, а не то, что я бы сделал в производственной среде.
Конечно, кажется, что мне нужна какая-то комбинация NLB с ALB, но опять же, в справочной статье представлено множество движущихся частей.
редактировать:
Static IP !== Single Point of Failure
В настоящее время существует только один способ связать статические 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 Edge (в той же сети, где работают CloudFront, Route 53 и S3 Transfer Acceleration - у нее больше точек присутствия, чем только в регионах AWS и AWS. -управляемые оптоволоконные соединения с регионами). Затем вы связываете конечные точки - ALB, NLB, EIP или EC2 Instance (без EIP) - с экземпляром Global Accelerator, и трафик из пограничного местоположения, куда поступают запросы, преобразуется в ваш балансировщик через NAT.
Когда Global Accelerator был первоначально запущен, он полагался на Source NAT для привязки глобальных адресов к устройствам VPC, поэтому вы не могли использовать исходный IP-адрес клиента или X-Forwarded-For
заголовок из ALB для определения IP-адреса клиента в реальном времени; тем не мение, это изменилось - X-Forwarded-For
теперь правильно определяет IP-адрес клиента, когда ALB используется с Global Accelerator в большинстве регионов AWS.
Сохранение IP-адреса клиента только работает когда конечная точка является экземпляром ALB или EC2 (без EIP). Он не работает с конечными точками EIP или балансировщиками сетевой нагрузки; в этих случаях вы можете только позже сопоставить их с помощью журналы потоков, которые захватывают кортежи источника / назначения, а также промежуточный адрес NAT, который будет видеть ваше приложение.
Важно отметить, что ALB является только входящим (соединения устанавливаются только снаружи вовнутрь, независимо от конечного направления передачи данных), поэтому, если ваши серверы также инициируют соединения, вам потребуется отдельное решение для статического адреса источника - a NAT-шлюз.
Один шлюз NAT для каждой зоны доступности, размещенный в общедоступной подсети, может служить в качестве шлюза по умолчанию для одной или нескольких частных подсетей в зоне доступности, так что все экземпляры в этих подсетях используют один и тот же исходный IP-адрес при подключении к Интернету. NAT Gateway - это не черный ящик в физическом месте - это особенность сетевой инфраструктуры, поэтому он изначально отказоустойчив и не рассматривается как единая точка отказа в пределах одной зоны доступности. Вы можете использовать один NAT-шлюз в разных зонах доступности, но тогда у вас будет единая точка отказа, если в этой одной зоне доступности произойдет что-то катастрофическое (и вы заплатите немного больше за транспортировку интернет-трафика через границы зоны доступности по сравнению с размещением одного NAT-шлюз в каждой зоне доступности). Шлюз NAT не требует изменений приложения, потому что это не прокси - это транслятор сетевых адресов, который прозрачен для экземпляров, расположенных в подсетях, настроенных для его использования. Каждый NAT-шлюз имеет статический EIP.
¹ сетевая зона является новая терминология AWS, представленный в Global Accelerator. Он описывает тот факт, что два IP-адреса внутри обрабатываются разной инфраструктурой.
Это расстраивает, потому что нет хорошего способа сделать это, особенно если вы обслуживаете веб-сайт и хотите знать, кто заходит на ваш сайт,
Вариант 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 это основные способы сделать это.