Настройка балансировки нагрузки через AWS ALB/NLB
При миграции в AWS часто возникает вопрос: какой балансировщик выбрать? Неправильный выбор приводит к головной боли на продакшене. Мы настраивали балансировку для десятков проектов, от стартапов с одним инстансом до enterprise с сотнями микросервисов. В этой статье покажем реальные конфигурации AWS Application Load Balancer (ALB) и Network Load Balancer (NLB), которые работают в production. ALB (уровень L7) понимает HTTP/HTTPS, умеет маршрутизировать по path, hostname, заголовкам, query params. NLB (уровень L4) работает с TCP/UDP, сохраняет source IP, даёт статические IP и предсказуемо низкий latency. Использование NLB там где нужен ALB — потеря функциональности. ALB для TCP-протоколов где нужен source IP — неправильная архитектура.
Как выбрать между ALB и NLB?
Выбор зависит от протокола и требований. Если ваше приложение работает по HTTP/HTTPS, используйте ALB — он предоставляет продвинутую маршрутизацию, перезапись путей, взвешенные target groups и встроенный WAF. Если требуется низкая задержка и работа с UDP, сохранение source IP или нужны статические IP — выбирайте NLB. NLB также является основой для PrivateLink, что необходимо для межсетевого взаимодействия. Иногда используют комбинацию: NLB перед ALB для получения статического IP и сохранения source IP при необходимости.
ALB: настройка Listeners и Rules
ALB Listener — порт (80, 443) и протокол. На каждом listener — правила маршрутизации с приоритетами. Правила проверяются от наименьшего приоритета к наибольшему, первое совпавшее — побеждает.
Типичная конфигурация rules для microservices:
| Priority | Condition | Action |
|---|---|---|
| 1 | path /api/v2/* + header X-Version: 2 |
Forward → tg-api-v2 |
| 10 | path /api/* |
Forward → tg-api-v1 |
| 20 | path /auth/* |
Forward → tg-auth-service |
| 30 | host admin.example.com |
Forward → tg-admin |
| Default | — | Forward → tg-frontend |
Weighted target groups в одном rule — это built-in canary deployment. Rule: Forward 90% → tg-v1, 10% → tg-v2. Меняем веса без изменения DNS или кода приложения. Для blue/green: 100/0 → деплоим новую версию в tg-v2 → тестируем → переключаем 0/100 → удаляем tg-v1.
Почему health check важен?
Неправильные параметры health check приводят к тому, что ALB считает здоровые инстансы unhealthy (и дёргает Auto Scaling) или продолжает слать трафик на unhealthy таргеты.
Protocol: HTTP
Path: /health
Healthy threshold: 2
Unhealthy threshold: 3
Timeout: 5s
Interval: 30s
Success codes: 200-299/health endpoint должен отвечать быстро (< timeout) и проверять только готовность самого приложения. Не проверять БД через health check — если БД недоступна, снимать трафик со всех инстансов и перекладывать на другие не поможет (у них та же БД). Лучше: отдельный /readiness для traffic routing и /liveness для restarts.
Deregistration delay (connection draining) — по умолчанию 300 секунд. ALB перестаёт слать новые запросы на деплойминуемый инстанс, но ждёт завершения in-flight запросов. Для stateless HTTP-сервисов с быстрыми запросами — снижаем до 30-60 секунд чтобы деплой проходил быстрее.
SSL Termination и HTTPS настройка
ACM Certificate прикрепляется к ALB Listener. ALB делает SSL termination — соединение между клиентом и ALB зашифровано, между ALB и target group — опционально. Для трафика внутри VPC (private subnet) HTTP достаточно — шифрование на этом уровне даёт overhead без практической пользы если сеть изолирована.
Security Policy для TLS — выбираем ELBSecurityPolicy-TLS13-1-2-2021-06 для максимальной безопасности. Отключает TLS 1.0/1.1, оставляет TLS 1.2 (для legacy клиентов) и TLS 1.3.
Redirect HTTP → HTTPS через отдельное правило на port 80 listener:
Action: Redirect to HTTPS, port 443, status 301 Подробнее о Mutual TLS на ALB
Mutual TLS (mTLS) доступен с недавнего времени. Клиент предоставляет сертификат, ALB валидирует против trust store. Нужно для: service-to-service authentication, zero-trust architecture, compliance. Включается в listeners на порту 443. Наша команда успешно внедряла mTLS для финтех-проектов.NLB: когда и как
NLB сохраняет source IP клиента в TCP-пакетах — приложение видит реальный IP, не IP ALB. Это критично для: rate limiting по IP на уровне приложения, geo-фильтрации, аудит-логов с реальными IP клиентов.
Статические IP — у каждого NLB есть фиксированный IP в каждой AZ. Это нужно когда upstream должен добавить IP в whitelist (партнёрское API, legacy firewall). ALB не имеет статических IP.
UDP protocol support — NLB единственный из AWS LB поддерживает UDP. DNS-серверы, NTP, игровые сервера, VPN endpoints — всё это через NLB.
PrivateLink строится поверх NLB — для service-to-service connectivity между аккаунтами или VPC без VPC peering. NLB является backend для endpoint service.
Мониторинг ALB/NLB
CloudWatch метрики которые настраиваем обязательно:
| Метрика | Порог для алерта | Значение |
|---|---|---|
HTTPCode_ELB_5XX_Count |
> 10/min | LB ошибки (не target) |
HTTPCode_Target_5XX_Count |
> 5% from requests | Ошибки приложения |
TargetResponseTime |
P95 > SLO | Деградация latency |
UnHealthyHostCount |
> 0 | Таргеты выпали |
RejectedConnectionCount |
> 0 | Перегрузка LB |
ALB Access Logs → S3 → Athena — стандартная схема для анализа трафика. Включается в атрибутах LB. Формат: timestamp, ELB name, client IP, target IP, request, response code, latency, user agent.
Процесс работы
Настройка балансировки состоит из следующих этапов:
- Аудит текущей архитектуры и требований к трафику.
- Проектирование конфигурации балансировщиков, правил маршрутизации, health check'ов.
- Реализация: создание Target Groups, Listeners, Rules, настройка SSL.
- Тестирование: проверка маршрутизации, отказоустойчивости, задержки.
- Деплой в production и мониторинг в течение недели.
Сроки: стандартная настройка ALB с SSL и базовыми правилами занимает 1 день. Сложные сценарии (NLB + PrivateLink, mTLS, weighted routing) — от 2 до 3 дней. Стоимость рассчитывается индивидуально, при этом экономия на инфраструктуре может достигать 30% за счёт оптимизации правил маршрутизации.
Что входит в работу
В рамках услуги мы предоставляем:
- Документацию архитектуры балансировки (схема, описание правил, параметры).
- Доступы к AWS и скрипты для воспроизведения.
- Обучение команды до 2 часов.
- Поддержку в течение 2 недель после внедрения.
Имеем 5+ лет опыта в AWS, более 50 успешных проектов по балансировке нагрузки. Хотите настроить балансировку под ключ? Свяжитесь с нами — оценим проект за 1 день. Получите консультацию по выбору балансировщика и оптимизации существующей конфигурации.
