Amazon ANS-C01: Балансировка нагрузки и управление трафиком — Руководство по подготовке
Часть AWS Advanced Networking Specialty ANS-C01 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.
Основная концепция
Балансировка нагрузки в AWS работает на двух фундаментальных уровнях: L4 (транспортный) и L7 (прикладной). Network Load Balancer (NLB) обеспечивает распределение на уровне L4 (TCP/UDP/TLS) и оптимизирован для экстремальной производительности, сохраняя исходный IP-адрес клиента и поддерживая миллионы одновременных соединений с очень низкой задержкой и стабильностью соединений. Application Load Balancer (ALB) работает на уровне L7 (HTTP/HTTPS/WebSocket и HTTP/2/gRPC), обеспечивает маршрутизацию на основе хоста и пути, проверку заголовков, проверки состояния на основе HTTP и привязку сессий на основе cookie (cookie stickiness), а также выполняет терминирование TLS при настройке с сертификатами из ACM. Gateway Load Balancer (GWLB) — это специализированный балансировщик нагрузки для масштабирования сторонних виртуальных устройств (межсетевых экранов, IDS/IPS) с использованием инкапсуляции GENEVE и эндпоинтов Gateway Load Balancer (GWLBe), что позволяет выполнять встроенную проверку трафика без ручного масштабирования устройств.
Прослушиватели (listeners) и их правила — это точки входа L4/L7, которые сопоставляют протоколы/порты с целевыми группами (target groups). Прослушиватель на ALB может иметь сложные правила, которые проверяют хост, путь, заголовки, CIDR исходного IP-адреса и перенаправляют трафик в разные целевые группы; ALB также может разгружать (терминировать) TLS и передавать целевым ресурсам заголовки X-Forwarded-For, X-Forwarded-Proto и X-Forwarded-Port. Прослушиватель NLB обычно является прослушивателем TCP/UDP/TLS, который перенаправляет трафик в целевые группы без анализа содержимого пакетов (если вы не включаете терминирование TLS на NLB): при использовании сквозной передачи TCP (passthrough) вы сохраняете сквозное шифрование TLS, поэтому бэкенд должен предоставлять и проверять сертификаты для взаимной аутентификации TLS (mTLS). Целевые группы — это связующее звено между прослушивателем балансировщика нагрузки и набором эндпоинтов (инстанс, IP-адрес или Lambda), и они предоставляют атрибуты, такие как протокол/порт/путь для проверки состояния, задержка отмены регистрации (connection draining) и свойства привязки сессий (stickiness).
Ключевые сервисы и конфигурация
Выбирайте подходящий балансировщик в зависимости от характеристик трафика и требований безопасности. Используйте ALB, когда вам нужна маршрутизация на основе хоста/пути, функции HTTP/HTTPS, такие как WebSockets или HTTP/2/gRPC с маршрутизацией, учитывающей особенности приложения, и привязка сессий на основе cookie. Настраивайте прослушиватели ALB с помощью CreateListener или через AWS::ElasticLoadBalancingV2::Listener, прикрепляйте сертификаты из ACM и устанавливайте правила прослушивателя с помощью CreateRule с условиями (Field=path-pattern, host-header, http-header). Включите привязку сессий (stickiness) для целевых групп ALB с помощью ModifyTargetGroupAttributes, установив Key=stickiness.enabled,Value=true и Key=stickiness.lb_cookie.duration_seconds,Value=<seconds>, чтобы использовать cookie, генерируемые балансировщиком нагрузки.
Используйте NLB для высокопроизводительных, долгоживущих TCP-соединений и когда требуется сохранение исходного IP-адреса клиента на бэкенде. Создайте NLB с помощью aws elbv2 create-load-balancer –name my-nlb –type network –subnets <subnet-ids> и добавьте TCP-прослушиватель с помощью aws elbv2 create-listener –load-balancer-arn <arn> –protocol TCP –port 443 –default-actions Type=forward,TargetGroupArn=<tg-arn>. Для сквозной передачи TLS (passthrough) и mTLS настройте прослушиватель NLB как TCP, чтобы терминирование TLS выполнялось на бэкенде; установите для целевой группы тип target-type ip при регистрации IP-адресов подов для Kubernetes. Используйте ModifyTargetGroupAttributes, чтобы установить Key=deregistration_delay.timeout_seconds,Value=<seconds> для корректного завершения соединений (connection draining); для NLB вы также можете включить привязку к исходному IP (source IP affinity), что является аналогом привязки сессий для целевой группы, где это необходимо.
Gateway Load Balancer настраивается с помощью CreateLoadBalancer Type=gateway, использует целевые группы с вашими инстансами-устройствами (или scale set в группе автомасштабирования) и применяет эндпоинт Gateway Load Balancer в VPC-потребителях для направления трафика на устройства в сервисном VPC. Используйте этот паттерн, когда вам нужна прозрачная проверка трафика и вы хотите, чтобы устройства автоматически масштабировались вместе с трафиком; создайте прослушиватели на порту 6081 (инкапсуляция GENEVE) и зарегистрируйте ENI устройств в целевой группе GWLB.
Операционные настройки, которыми вы должны управлять программно, включают межсетевую балансировку нагрузки (cross-zone load balancing), задержку отмены регистрации (connection draining) и настройку проверок состояния. Для межсетевой балансировки установите атрибуты на балансировщике нагрузки (aws elbv2 modify-load-balancer-attributes –load-balancer-arn <arn> –attributes Key=load_balancing.cross_zone.enabled,Value=true), чтобы обеспечить распределение трафика по всем зонам доступности (AZ), а не перекос в сторону мощностей отдельной AZ. Установите интервал, тайм-аут и пороги для состояний healthy/unhealthy в целевых группах, чтобы избежать «хлопанья» (flapping) состояния во время событий автомасштабирования.
Архитектурные шаблоны и компромиссы
Для сквозного TLS и взаимной аутентификации TLS (mTLS), когда трафик должен оставаться зашифрованным, а клиентские сертификаты должны предоставляться бэкенду, предпочтительнее использовать сквозную передачу 4-го уровня (L4 passthrough) с помощью NLB и TCP-прослушивателей. Это сохраняет сессию TLS нетронутой, позволяя бэкендам проверять клиентские сертификаты X.509; настройте целевые группы (target groups) на использование IP-адресов в качестве целей (IP targets), чтобы IP-адреса подов Kubernetes могли регистрироваться напрямую, а AWS Load Balancer Controller мог управлять жизненным циклом целей. Компромисс заключается в потере функций 7-го уровня (L7) ALB, таких как маршрутизация по хосту/пути, интеграция с Web Application Firewall и встроенная поддержка привязки сессий (sticky sessions) по HTTP-cookie на уровне балансировщика нагрузки.
Когда вам нужна маршрутизация на основе содержимого, завершение TLS-сессии и расширенные функции HTTP, используйте ALB и завершайте TLS на самом ALB (с помощью сертификатов, управляемых через ACM). Чтобы сохранить IP-адрес клиента для логирования и правил WAF, считывайте заголовок X-Forwarded-For, который заполняет ALB, или используйте уровень, который добавляет исходный IP-адрес клиента в заголовки. Если вам нужно, чтобы сетевой стек ОС бэкенда видел IP-адрес клиента на уровне сокета, используйте NLB (или включите Proxy Protocol для передачи исходного IP). Однако учтите, что Proxy Protocol должен быть включен в целевой группе, а ваше приложение или прокси-сервер (например, Envoy) должны уметь его разбирать (парсить).
Обработка привязанных сессий (sticky sessions) в среде с автомасштабированием требует тщательного подхода. Привязка сессий по cookie в ALB может привязать клиента к цели на определенное время, что может мешать сбалансированному масштабированию подов при интенсивном трафике сессии. Альтернативные шаблоны включают использование кратковременной привязки в сочетании с выносом состояния сессии во внешнее хранилище, такое как ElastiCache (Redis) или DynamoDB, или использование sidecar-прокси (Envoy) для управления привязкой сессий (session affinity) с помощью консистентного хеширования. Плавный вывод из эксплуатации (connection draining или deregistration delay) критически важен для корректного завершения работы: установите deregistration_delay.timeout_seconds на значение, превышающее длительность самого долгого запроса RPC/HTTP, чтобы избежать резкого прерывания соединений и ошибок у клиентов во время завершения работы пода. Настройте хуки preStop в Kubernetes для координации жизненного цикла пода с процессом снятия с регистрации.
GWLB — это подходящий шаблон, когда вам требуется масштабируемая потоковая инспекция трафика между множеством VPC и централизованное управление безопасностью. При необходимости комбинируйте GWLB с архитектурами на основе Transit Gateway или VPC peering; компромиссом здесь являются стоимость и операционная сложность управления устройствами (appliances) по сравнению с использованием управляемых сервисов, таких как AWS Network Firewall.
← DNS и Route 53 · Все домены · Сетевая безопасность и соответствие требованиям →
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →