В чем разница между Network Load Balancer и Application Load Balancer?

Различия между Network Load Balancer (NLB) и Application Load Balancer (ALB) в AWS

Основное различие между Network Load Balancer (NLB) и Application Load Balancer (ALB) заключается в их месте работы в модели OSI, целевом использовании и возможностях. NLB работает на транспортном уровне (L4), а ALB — на прикладном уровне (L7), что определяет их архитектуру, производительность и сценарии применения.

Уровень работы в модели OSI

Network Load Balancer (NLB):

• Работает на транспортном уровне (L4), фокусируясь на IP-адресах и портах.
• Видит только сетевые пакеты (TCP/UDP), не анализируя содержимое HTTP/HTTPS.
• Пример обработки: перенаправление трафика на основе IP:порт без понимания URL или заголовков.

Application Load Balancer (ALB):

• Работает на прикладном уровне (L7), анализируя содержимое HTTP/HTTPS запросов.
• Может принимать решения на основе URL пути, заголовков, метода запроса (GET/POST) и т.д.
• Пример: маршрутизация /api/* к одним серверам, а /static/* к другим.

Ключевые особенности и сценарии использования

Network Load Balancer (NLB)

• Высокая производительность и низкая задержка: обрабатывает миллионы запросов в секунду с задержкой ~100 мс.
• Статические IP-адреса: можно закрепить Elastic IP за NLB, что критично для white-list сетей.
• Сохранение исходного IP: передает исходный IP-адрес клиента на целевые серверы (без прокси-заголовков).
• Поддержка TCP/UDP: идеален для не-HTTP трафика (базы данных, игровые сервера, VoIP).
• Интеграция с AWS: Native AWS PrivateLink, зональная изоляция.

Пример конфигурации NLB через Terraform:

resource "aws_lb" "nlb_example" {
  name               = "network-lb"
  internal           = false
  load_balancer_type = "network"
  subnets            = [aws_subnet.public.*.id]

  enable_deletion_protection = false
}

Application Load Balancer (ALB)

• Умная маршрутизация: маршрутизация на основе пути, хоста, заголовков, query-параметров.
• Поддержка WebSocket и HTTP/2: нативные без дополнительной конфигурации.
• Аутентификация: интеграция с Cognito, OIDC, аутентификация на уровне ALB.
• Медленные старты (slow start): постепенное увеличение трафика на новые цели.
• Контейнерные сервисы: идеален для ECS с динамическими портами.

Пример маршрутизации ALB по пути:

{
  "Rules": [
    {
      "Conditions": [
        {
          "Field": "path-pattern",
          "Values": ["/api/*"]
        }
      ],
      "Priority": 1,
      "Actions": [
        {
          "Type": "forward",
          "TargetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/api-targets/1234567890abcdef"
        }
      ]
    }
  ]
}

Сравнительная таблица

Практические рекомендации по выбору

Выбирайте Network Load Balancer, когда:

• Требуется максимальная производительность для TCP/UDP трафика
• Нужны статические IP-адреса для входящих подключений
• Работаете с не-HTTP протоколами (VoIP, игровые сервера, кастомные протоколы)
• Критична минимальная задержка (финансовые транзакции, торгующие системы)

Выбирайте Application Load Balancer, когда:

• Нужна интеллектуальная маршрутизация на основе содержимого запроса
• Работаете с веб-приложениями (HTTP/HTTPS)
• Требуется аутентификация на уровне балансировщика
• Используете сервисные архитектуры (микросервисы) с разными путями
• Нужна поддержка WebSocket или HTTP/2

Гибридные подходы

В реальных сценариях часто используется комбинация:

• NLB как внешний балансировщик для входящего TCP-трафика
• ALB за NLB для внутренней HTTP-маршрутизации
• NLB для приватных сервисов через AWS PrivateLink

Пример архитектуры:

Клиенты → NLB (статический IP) → ALB (маршрутизация) → Микросервисы
                     ↑
                Финансовые API (низкая задержка)

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