ALB, NLB и GLB: когда что использовать

Elastic Load Balancing (ELB) автоматически распределяет входящий трафик приложения между несколькими целями — экземплярами EC2, контейнерами, функциями Lambda или IP-адресами. ELB — это управляемый сервис: AWS отвечает за подготовку, масштабирование и доступность самого балансировщика нагрузки в нескольких AZ.

AWS предлагает три типа балансировщиков нагрузки в составе ELB: Application Load Balancer (ALB), Network Load Balancer (NLB) и Gateway Load Balancer (GWLB). Каждый работает на своём уровне модели OSI и оптимизирован для разных сценариев использования.

ALB работает на уровне 7 (HTTP/HTTPS) модели OSI. Он может анализировать заголовки HTTP, пути, строки запросов, имена хостов и файлы cookie, чтобы принимать интеллектуальные решения о маршрутизации. ALB — основной выбор для веб-приложений, микросервисов и конечных точек API, которым нужна маршрутизация на основе содержимого.

Ключевые возможности ALB: маршрутизация по пути (/api/* в одну целевую группу, /static/* — в другую), маршрутизация по хосту (разные виртуальные хосты к разным серверным компонентам), маршрутизация по заголовкам HTTP и строкам запросов, поддержка WebSocket и HTTP/2. ALB может направлять трафик к экземплярам EC2, контейнерам (ECS/EKS), функциям Lambda и IP-адресам.

NLB работает на уровне 4 (TCP/UDP/TLS). Он маршрутизирует пакеты на основе данных протокола IP, не анализируя содержимое приложения. NLB предназначен для экстремальной производительности: он обрабатывает миллионы запросов в секунду с сверхнизкой задержкой (обычно менее 100 микросекунд).

Ключевые возможности NLB: статические IP-адреса для каждого AZ (один Elastic IP на подсеть), сквозная передача TLS (пересылка зашифрованного трафика без расшифровки), сохранение IP-адреса клиента и поддержка протоколов UDP (например, DNS, RADIUS, игровые серверы). NLB не может выполнять маршрутизацию на основе содержимого или анализировать заголовки HTTP.

GWLB работает на уровне 3 (сетевом уровне) и предназначен исключительно для развёртывания, масштабирования и управления виртуальными сетевыми устройствами сторонних производителей — межсетевыми экранами, системами обнаружения и предотвращения вторжений (IDS/IPS) и системами глубокой проверки пакетов.

GWLB использует протокол GENEVE (порт 6081), чтобы инкапсулировать трафик и отправлять его в парк Ваших устройств. Устройство проверяет пакет и возвращает его через ту же конечную точку GWLB. Трафик проходит прозрачно, без необходимости изменять маршрутизацию в исходной VPC. Это стандартный способ добавить централизованную проверку безопасности в потоки трафика AWS VPC.

Выбирайте ALB, если:

• Вам нужна маршрутизация HTTP/HTTPS на основе содержимого (пути, хоста, заголовка, строки запроса)
• Ваша серверная часть включает функции Lambda или контейнеры ECS
• Вам нужны соединения WebSocket или HTTP/2
• Вы хотите интегрировать AWS WAF для защиты веб-приложения на уровне балансировщика нагрузки
• Вы создаёте архитектуру микросервисов с множеством сервисов на разных путях URL
• Вам нужно завершение SSL/TLS на балансировщике нагрузки

ALB — правильный ответ для большинства вопросов экзамена SAA-C03 о балансировке нагрузки веб-приложений и REST API.

Выбирайте NLB, если:

• Вам нужна экстремальная производительность (миллионы запросов в секунду, задержка менее миллисекунды)
• Вам требуются статические IP-адреса, которые партнёры или межсетевые экраны могут добавить в список разрешённых
• Вам нужно обрабатывать трафик UDP (игры, DNS, RADIUS, IoT)
• Вы хотите использовать сквозную передачу TLS без расшифровки на балансировщике нагрузки (сквозное шифрование до цели)
• Вам нужно изначально сохранять исходный IP-адрес клиента на уровне TCP
• Вы используете AWS PrivateLink для предоставления сервисов другим VPC или аккаунтам (для PrivateLink требуется NLB)

Выбирайте GWLB, если Вам нужно:

• Добавить межсетевые экраны сторонних производителей (Palo Alto, Fortinet, Check Point) в поток сетевого трафика
• Выполнять глубокую проверку пакетов на уровне VPC для всего входящего и исходящего трафика
• Горизонтально масштабировать парк устройств IDS/IPS с автоматической балансировкой нагрузки

Архитектура: трафик проходит из исходной VPC → конечная точка GWLB → VPC устройств (где GWLB распределяет трафик между экземплярами устройств) → устройство возвращает трафик в GWLB → GWLB пересылает его исходному получателю. Источник и получатель не знают о промежуточной проверке.

Межзональная балансировка нагрузки равномерно распределяет трафик между всеми зарегистрированными целями во всех включённых AZ, независимо от того, в каком AZ узел балансировщика получил запрос. Без межзональной балансировки узел каждого AZ распределяет трафик только между целями в своём AZ.

В ALB межзональная балансировка нагрузки включена по умолчанию без дополнительной платы. В NLB межзональная балансировка нагрузки отключена по умолчанию — её включение влечёт плату за передачу данных между AZ. В GWLB межзональная балансировка нагрузки отключена по умолчанию. Включайте межзональную балансировку, если количество целей в AZ различается, чтобы избежать перегруженных участков.

Краткая сравнительная таблица для экзамена:

• Уровень OSI: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Протоколы: ALB = HTTP, HTTPS, WebSocket; NLB = TCP, UDP, TLS; GWLB = все протоколы IP через GENEVE
• Статический IP: ALB = нет (используйте схему NLB + ALB); NLB = да (1 на AZ); GWLB = неприменимо
• Интеграция с WAF: ALB = да; NLB = нет; GWLB = нет
• Цель Lambda: ALB = да; NLB = нет; GWLB = нет
• Дренирование соединений: все три поддерживают задержку отмены регистрации

ALB изначально интегрируется с AWS WAF для региональной защиты (в отличие от WAF в CloudFront, который обеспечивает глобальную защиту на периферии). Подключив Web ACL WAF к ALB, Вы можете фильтровать HTTP-запросы до того, как они достигнут приложения, блокируя внедрение SQL, XSS, известные вредоносные IP-адреса и клиентов, злоупотребляющих частотой запросов.

Используйте ALB + WAF, если Вам нужна проверка безопасности на уровне балансировщика нагрузки (например, для защиты API, которые не обслуживаются через CloudFront). Web ACL WAF, подключённые к ALB, должны находиться в том же регионе, что и ALB, и иметь область действия REGIONAL (в отличие от WAF CloudFront, которому требуется область действия CLOUDFRONT в us-east-1).

AWS PrivateLink использует NLB, чтобы предоставлять сервисы из одной VPC потребителям в других VPC или аккаунтах AWS без пиринга VPC, интернет-шлюза или NAT. Поставщик сервиса создаёт NLB перед своим сервисом и создаёт сервис конечной точки VPC. Потребители создают интерфейсную конечную точку VPC в своей VPC, указывающую на сервис.

Трафик проходит по частной сети AWS и никогда не выходит в интернет. PrivateLink — стандартный способ для поставщиков SaaS в AWS и предоставления общих сервисов (например, централизованного сервиса безопасности) нескольким внутренним аккаунтам AWS.

Проверьте понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что ALB выполняет маршрутизацию на уровне 7 (HTTP) с правилами на основе содержимого, интеграцией с WAF и целями Lambda, NLB выполняет маршрутизацию на уровне 4 (TCP/UDP) со статическими IP-адресами и экстремальной пропускной способностью, а GWLB развёртывает виртуальные сетевые устройства на уровне 3 с использованием GENEVE. Подбирайте балансировщик нагрузки в соответствии с требованиями к протоколу и возможностям. Далее мы рассмотрим целевые группы и проверки работоспособности.