Маршрутизация по хосту на AWS с Application Load Balancer — пошаговое руководство

Введение

Elastic Load Balancing (ELB) в AWS распределяет входящий трафик между несколькими целями (targets). Цели могут быть EC2-инстансами, контейнерами или IP-адресами в одной или нескольких зонах доступности. AWS поддерживает несколько типов балансировщиков нагрузки: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer и устаревший Classic Load Balancer. Каждый тип служит разным задачам и работает на разных сетевых уровнях.

Коротко о типах балансировщиков приводится ниже:

• Application Load Balancer — работает на уровне приложения (Layer 7). Поддерживает маршрутизацию на основе содержимого запроса (path-based routing) и на основе хоста (host-based routing).
• Network Load Balancer — работает на уровне транспорта (Layer 4). Оптимизирован для высокой пропускной способности и низкой задержки с обработкой TCP/UDP.
• Gateway Load Balancer — применяется для интеграции с виртуальными сетевыми устройствами (NGFW, IPS/IDS) и сочетает функции маршрутизации и балансирования.
• Classic Load Balancer — устаревший вариант, применяется только для старых EC2-Classic решений.

Определения терминов в одну строку:

• Target group — логическая группа конечных пунктов (EC2/IP), на которые ALB пересылает трафик.
• Listener — порт и протокол, на котором ALB слушает запросы (например, HTTP:80).
• Rule — правило слушателя, которое направляет запросы в таргет‑группы по условиям (host/path/header).

Что вы создадите в этом руководстве

• Два EC2-инстанса с простыми веб-серверами и разными путями (/signin и /signup).
• Две таргет‑группы: Sign-In и Sign-Up, с соответствующими health check путями.
• Application Load Balancer с слушателем HTTP и правилами маршрутизации по хосту.
• Route 53 простые записи типа A (Alias) на ALB для двух поддоменов.

Требования и предпосылки

• AWS аккаунт с правами на EC2, ELB и Route 53.
• VPC с минимум двумя зонами доступности и по крайней мере одной публичной подсетью в каждой зоне.
• Два EC2-инстанса (Amazon Linux) с установленным веб‑сервером (Apache/httpd) и открытым портом 80.
• На первом инстансе содержимое доступно по пути /signin, на втором по /signup. Например, /var/www/html/signin/index.html и /var/www/html/signup/index.html.

Важно: в рабочей среде используйте HTTPS (TLS) для listener и соответствующие сертификаты в ACM. В этом пошаговом руководстве для простоты примеры показаны на HTTP.

Настройка EC2 и веб‑сервисов

1. Установите Apache на каждом инстансе:

   sudo yum install -y httpd sudo systemctl enable httpd sudo systemctl start httpd

2. Создайте папки и простые index.html:

   sudo mkdir -p /var/www/html/signin sudo mkdir -p /var/www/html/signup echo «Welcome User? Sign in to proceed…» | sudo tee /var/www/html/signin/index.html echo «New User? Sign Up First…» | sudo tee /var/www/html/signup/index.html

3. Убедитесь, что security group инстансов разрешает входящие соединения на порт 80 с ALB (или с 0.0.0.0/0 для тестов).

4. Проверьте работу локально на каждом инстансе, используя curl или браузер по IP: curl http:///signin

Создание таргет‑групп

Цель: создать две таргет‑группы с health check по соответствующим путям.

Шаги:

1. В консоли AWS откройте раздел EC2 → Target Groups.
2. Нажмите Create target group.
3. Выберите Target type: Instances.
4. Укажите имя Target group: Sign-In.
5. Протокол: HTTP, Порт: 80, VPC: ваш VPC.
6. В разделе Health checks укажите Protocol: HTTP, Path: /signin.
7. Оставьте advanced параметры по умолчанию. Добавьте теги при необходимости.
8. Нажмите Next и зарегистрируйте соответствующий EC2-инстанс как цель (Include as pending below), затем Create target group.

Повторите создание для Sign-Up с Path: /signup и привяжите второй инстанс.

Практическая заметка: health check должен возвращать 2xx или 3xx код ответа. Если ваш index.html возвращает 200, всё в порядке.

Создание Application Load Balancer

1. В EC2 консоли откройте Load Balancers → Create Load Balancer → Application Load Balancer.
2. Укажите имя, например My-Path-ALB. Scheme: Internet-facing. IP address type: IPv4.

3. В Network mapping выберите VPC и укажите подсети в двух зонах доступности, где расположены инстансы.

4. Настройте Security groups для ALB. По умолчанию разрешите HTTP 80 (и HTTPS 443, если используете TLS).

5. Добавьте listener HTTP:80. В Default action укажите Forward to → Sign-In (или временно любую таргет‑группу).

6. Пропустите дополнительные опции и создайте ALB.

После создания дождитесь состояния Active.

Правила маршрутизации по хосту

Теперь добавим правила на listener для маршрутизации по имени хоста (Host header).

1. В списке Load Balancers найдите созданный ALB.

2. Перейдите на вкладку Listeners и выберите View/Edit rules для HTTP:80.
3. Нажмите + → Insert Rule.
4. В колонке IF добавьте условие Host is и укажите hostname, например www.signin.tecofers.com.
5. В колонке THEN добавьте действие Forward to → Sign-In.
6. Создайте отдельное правило для www.signup.tecofers.com и Forward to → Sign-Up.
7. Сохраните правила. Оставьте последним правилом Default action на случай несоответствия условий.

Практическая заметка: host-based правила используют значение заголовка Host в HTTP/1.1 и :authority в HTTP/2. Убедитесь, что клиенты отправляют правильный Host.

Настройка Route 53 для поддоменов

Чтобы домены указывали на ALB, создайте публичную hosted zone и Alias записи типа A.

Шаги:

1. Откройте Route 53 → Hosted zones → Create hosted zone. Укажите домен и выберите Public hosted zone.

2. Создайте запись Create record → Switch to wizard → Simple routing → Define simple record.
3. Заполните поле Name: поддомен (например www.signin). Тип записи: A.
4. Value/Route traffic to: Alias to Application and Classic Load Balancer → выберите регион и ваш ALB.
5. Нажмите Define simple record и повторите для второго поддомена.

Дополнение: если домен управляется у стороннего регистратора, укажите NS записи Route 53 у регистратора.

Проверка настройки

1. Подождите, пока DNS распространится (обычно несколько минут до часа). Для проверки используйте dig или nslookup:

   dig www.signin.tecofers.com +short

2. Откройте в браузере http://www.signin.tecofers.com — должен открыться контент из /signin.

3. Аналогично проверьте www.signup.tecofers.com — должен открыться контент из /signup.

Если вы получаете Default page или Page not found, проверьте порядок правил на ALB и правильность Host заголовка.

Отладка и частые ошибки

1. Health check показывает Unhealthy

   • Проверьте путь health check (/signin или /signup). Он должен возвращать 200.
   • Убедитесь, что security group инстансов разрешает трафик от ALB или на 0.0.0.0/0.
   • Проверьте маршруты и NACL в VPC.

2. Правило не срабатывает

   • Убедитесь, что Host header в запросе совпадает с условием (без лишних префиксов/суффиксов).
   • Проверяйте регистр и точность имени хоста.

3. DNS указывает не на ALB

   • Убедитесь, что в Route 53 создана Alias A запись на ALB, а не запись типа CNAME к IP.
   • Если домен зарегистрирован у другого провайдера, проверьте NS записи.

4. HTTPS не работает

   • Для HTTPS используйте сертификат в ACM, привязанный к listener 443.
   • Убедитесь, что security group ALB разрешает 443.

Безопасность и лучшие практики

• Используйте HTTPS для внешних сервисов. Храните сертификаты в AWS Certificate Manager и подключайте их к listener 443.
• В production настройте health checks на более специфичный endpoint, возвращающий статус приложения.
• Отключайте public access к вашим EC2, если он не требуется. ALB может быть Internet-facing, а инстансы — в приватных подсетях.
• Настройте WAF (Web Application Firewall) перед ALB при необходимости.
• Лимитируйте доступ к консоли и используйте IAM роли с минимальными правами.

Роли и чек‑листы

Архитектор

• Проверить соответствие дизайна требованиям безопасности.
• Выбрать зоны доступности и подсети.

Инженер сетей

• Настроить VPC и NACL.
• Убедиться в связности между ALB и инстансами.

Инженер приложений

• Установить веб‑сервер и обеспечить корректные endpoints для health checks.
• Тестировать ответы 200/302 на health endpoints.

DevOps инженер

• Создать target groups и ALB.
• Настроить Route 53 и мониторинг.

План тестирования и критерии приёмки

Критерии приёмки:

• DNS поддомены возвращают IP ALB и открывают правильную страницу (/signin или /signup).
• Health checks для каждой таргет‑группы в статусе Healthy.
• ALB правильно маршрутизирует по host header и fallback происходит на default action.
• Логи ALB и target group показывают ожидаемые request/response коды.

Тестовые сценарии:

• Позитивный: Запрос к www.signin. возвращает страницу /signin и статус 200.
• Позитивный: Запрос к www.signup. возвращает страницу /signup.
• Негативный: Запрос с неизвестным хостом должен попадать на Default target или возвращать стандартную страницу.
• Нагрузочный: Проверить поведение при одновременных запросах и убедиться в отсутствии 5xx ошибок.

Runbook при инциденте

Если пользователи не видят контент по поддоменам:

1. Проверить статус ALB — Active.
2. Проверить правила слушателя — правильные Host conditions и порядок правил.
3. Проверить здоровье таргет‑групп — если Unhealthy, выполнить curl с ALB в приватной сети к target ip.
4. Проверить security groups и routing.
5. Посмотреть логи ALB (Access logs) и CloudWatch metrics (HTTPCode_Target_5XX_Count).
6. При необходимости откатить последние изменения в Route 53 или правилах ALB.

Альтернативные подходы и когда они применимы

• Path-based routing вместо host-based — когда у вас один домен и разные контексты (/app1, /app2).
• Использование NLB — когда нужно TCP/UDP балансирование с высокой производительностью.
• Gateway Load Balancer — при интеграции с виртуальными сетевыми устройствами.

Когда host-based может не подойти:

• Если клиенты не поддерживают корректный Host header (редкие IoT устройства).
• Если нужно балансировать на уровне TCP для нестандартных протоколов.

Советы по миграции и совместимости

• При миграции с Classic Load Balancer убедитесь, что приложения совместимы с L7 правилами ALB.
• Переключайте DNS постепенно, используя низкий TTL для быстрого отката.

Краткое резюме

Маршрутизация по хосту с ALB позволяет направлять запросы к разным сервисам на основании Host заголовка. Это гибкий и распространённый способ организовать мультисервисную архитектуру под одним IP/ALB. Следуйте проверенным шагам: подготовьте инстансы и health checks, создайте таргет‑группы, настройте ALB и правила, затем опубликуйте DNS в Route 53.

Важные заметки

• В production используйте HTTPS и мониторинг.
• Тестируйте health checks и fallback-сценарии.

Краткая памятка

• Проверить health checks — статус Healthy.
• Проверить соответствие Host заголовков правилам ALB.
• Настроить Route 53 Alias записи на ALB.