Как я могу использовать статический IP-адрес с Application Load Balancer для обеспечения высокой доступности?
Я наблюдаю за интеграцией для клиента, и его поставщику требуется несколько IP-адресов для внесения в белый список. Исходный сервер (и) - это экземпляр Elastic Beanstalk, на который выходит Application Load Balancer со всеми обрезками через Route53.
Это не сработает, поскольку вы не можете назначить статический IP-адрес балансировщикам нагрузки приложений по определению (а мне действительно нужны функции уровня 7).
Я не могу просто передать конкретные запросы поставщику через прокси. через код и дополнительный экземпляр EC2, потому что это двусторонняя интеграция.
Я прочитал эту статью , но, честно говоря, это похоже на взлом, а не на то, что я бы сделал в производственной среде .
Определенно кажется, что мне нужна какая-то комбинация NLB с ALB, но, опять же, в справочной статье представлена масса движущихся частей.
Изменить :
- Я использую VPC
- Сам экземпляр находится в частной подсети
- ALB живет в общедоступной подсети, и у обоих есть необходимая маршрутизация для связи
- Я почти уверен, что говорю кругами, пытаясь убедить себя
Статический IP! == Единая точка отказа
В настоящее время существует только один способ связать статические 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 Edge (в той же сети, где работают 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-шлюз - это не черный ящик в физическом месте - это особенность сетевой инфраструктуры, поэтому он по своей сути является отказоустойчивым и не считается единственной точкой отказа в пределах одной зоны доступности. Вы можете использовать один NAT-шлюз в разных зонах доступности, но тогда у вас будет единая точка отказа, если в этой одной зоне доступности произойдет что-то катастрофическое (и вы заплатите немного больше за транспортировку интернет-трафика через границы зоны доступности по сравнению с размещением одного NAT-шлюз в каждой зоне доступности). Шлюз 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 это основные способы сделать это.