Налаштування балансування навантаження через 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 для restart.
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 день. Отримайте консультацію з вибору балансувальника та оптимізації існуючої конфігурації.
Джерело: AWS Documentation - Elastic Load Balancing На основі реальних проєктів з балансування навантаження AWS
Ми гарантуємо якість налаштування: наші сертифіковані AWS Solutions Architects мають понад 5 років досвіду. Завдяки оптимізації правил маршрутизації економія на інфраструктурі може досягати 30%, що становить від $500 до $5000 на місяць для середніх проєктів. ALB у 2 рази швидше обробляє запити порівняно з Classic Load Balancer, а NLB забезпечує затримку на 50% меншу, ніж ALB на TCP-трафіку. Для правильного вибору балансувальника важливо враховувати такі ключові параметри, як протокол, затримка та вимоги до source IP. Якщо вам потрібна гарантія результатів і сертифікований досвід — звертайтесь.
