Вопросы и ответы по Elastic Load Balancing

Application Load Balancer поддерживает целевые объекты с любой операционной системой, которую в настоящее время поддерживает сервис Amazon EC2.

Application Load Balancer поддерживает распределение нагрузки на приложения с помощью протоколов HTTP и HTTPS (Secure HTTP).

Да. В Application Load Balancer имеется встроенная поддержка протокола HTTP/2. Клиенты, которые поддерживают HTTP/2, могут подключаться к Application Load Balancer по TLS.

Можно перенаправлять трафик из Балансировщика сетевой нагрузки, который поддерживает PrivateLink и статический IP-адрес для каждой Зоны доступности, в Балансировщик нагрузки приложений. Создайте целевую группу нужного типа для Application Load Balancer, зарегистрируйте в ней свой балансировщик и настройте в Network Load Balancer перенаправление трафика в эту целевую группу.

Применить распределение нагрузки можно к следующим портам TCP: 1-65535.

Да. В Application Load Balancer имеется встроенная поддержка и готовность к использованию протоколов WebSocket и Secure WebSocket.

Да. Функция отслеживания запросов по умолчанию включена в Application Load Balancer.

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

Да.

Да.

Нет. Для Балансировщиков нагрузки приложений требуется новый набор интерфейсов прикладного программирования (API).

Консоль ELB позволяет управлять Application Load Balancer и Classic Load Balancer из одного интерфейса. При использовании интерфейса командной строки (CLI) или пакета средств разработки ПО (SDK) необходимо будет использовать для Application Load Balancer другой указатель сервиса. Например, в интерфейсе командной строки вы будете описывать свои Classic Load Balancer с помощью «aws elb describe-load-balancers», а свои балансировщики Application Load Balancer – с помощью «aws elbv2 describe-load-balancers».

Нет, преобразовать один тип балансировщика нагрузки в другой нельзя.

Да. Перейти на Балансировщик нагрузки приложений с Классического балансировщика нагрузки можно с помощью одного из способов, приведенных в этом документе.

Если требуются возможности уровня 4, следует использовать Network Load Balancer.

Да. Можно добавить получателей HTTP-порта 80 и HTTPS-порта 443 к одному Application Load Balancer.

Да. Чтобы получить журнал всех вызовов API Балансировщика нагрузки приложений для своего аккаунта, используйте сервис AWS CloudTrail.

Да, на Application Load Balancer можно выполнить HTTPS-терминацию. Нужно установить для балансировщика нагрузки сертификат Secure Sockets Layer (SSL). Балансировщик нагрузки использует этот сертификат для завершения подключения, а затем дешифрует запросы от клиентов перед их отправкой в целевые объекты.

Для получения сертификата SSL/TLS можно использовать Менеджер сертификатов AWS или создать запрос на получение сертификата из других источников. Затем необходимо подписать сертификат в центре сертификации и загрузить его с помощью Менеджера сертификатов AWS или Управления идентификацией и доступом AWS (AWS IAM).

Application Load Balancer интегрирован с сервисом AWS Certificate Manager (ACM). Интеграция с ACM позволяет очень легко привязать сертификат к балансировщику нагрузки, тем самым сильно упрощая весь процесс выгрузки SSL. Процесс приобретения, загрузки и обновления сертификатов SSL/TLS является длительным, сложным и требует ручной работы. Интеграция ACM с Application Load Balancer сводит весь процесс к запросу доверенного сертификата SSL/TLS и затем выбору сертификата ACM для распределения его балансировщику нагрузки.

Нет. Application Load Balancer поддерживает только шифрование для серверов.

SNI включается автоматически, если с одним обработчиком событий безопасности на балансировщике нагрузки связано несколько сертификатов TLS. Аналогичным образом режим SNI для обработчика событий безопасности отключается автоматически, если с этим обработчиком связан только один сертификат.

Да, с обработчиком событий безопасности можно связать несколько сертификатов для одного домена. Это позволяет связать, к примеру, следующее:

• сертификаты ECDSA и RSA;
• сертификаты с разными размерами ключей (например, 2К и 4К) для сертификатов SSL/TLS;
• однодоменные, многодоменные (SAN) сертификаты и сертификаты с использованием шаблонов подстановки.

Да. Протокол IPv6 поддерживается балансировщиком Application Load Balancer.

Можно настроить правила для каждого из слушателей, созданных на балансировщике нагрузки. Правила включают в себя условия и соответствующие действия, выполняемые в случае соблюдения условий. Поддерживаемые условия: заголовок хоста, путь, заголовки HTTP, методы, параметры запросов и IP-адреса источника бесклассовой междоменной маршрутизации (CIDR). Поддерживаемые действия: перенаправление, фиксированный ответ, проверка подлинности и переадресация. После настройки правил балансировщик нагрузки будет использовать эти правила для определения способа маршрутизации HTTP-запроса. В одном правиле можно использовать несколько условий и действий, при этом в каждом условии можно указать совпадение по нескольким значениям.

В вашем аккаунте AWS установлены эти ограничения для Балансировщика нагрузки приложений.

Балансировщик нагрузки приложений можно интегрировать с Брандмауэром веб-приложений AWS (WAF), который обеспечивает защиту от атак, позволяя задавать различные правила на основе IP-адресов, заголовков HTTP и специальных строк унифицированных идентификаторов ресурса (URI). На основании созданных правил AWS WAF выполняет блокировку, разрешение или отслеживание (подсчет) сетевых запросов, направленных в адрес интернет-приложения. См. подробности в Руководстве разработчика AWS WAF.

Можно использовать любой IP-адрес из диапазона CIDR VPC в качестве целевого объекта балансировщика нагрузки в VPC и любой IP-адрес из диапазонов RFC 1918 (10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16) или диапазона RFC 6598 (100.64.0.0/10) для целевых объектов, расположенных за пределами VPC балансировщика нагрузки (например, целевые объекты в VPC с пиринговым подключением, в инстансах Amazon EC2 Classic и в локальных местоположениях, доступных через подключения AWS Direct Connect или VPN).

Есть несколько способов настройки гибридной балансировки нагрузки. Если приложение выполняется на целевых объектах, распределенных между VPC и локальной средой, их можно добавить в одну и ту же целевую группу, используя соответствующие IP-адреса. Чтобы перейти на AWS без ущерба для работы приложения, постепенно добавляйте в целевую группу цели VPC и удаляйте из нее локальные цели. 

Если у вас есть два разных приложения, причем целевые объекты одного приложения находятся в VPC, а целевые объекты других приложений находятся в локальной среде, можно поместить цели VPC в одну целевую группу, а локальные цели – в другую целевую группу и использовать маршрутизацию на основе контента для направления трафика в каждую целевую группу. Можно также применять отдельные балансировщики нагрузки для VPC и локальных целевых объектов и использовать весовой коэффициент DNS для достижения взвешенной балансировки нагрузки между VPC и локальными целевыми объектами.

Балансировать нагрузку для инстансов EC2-Classic при регистрации в качестве целей их идентификаторов нельзя. Однако если связать эти инстансы EC2-Classic с VPC балансировщика нагрузки с помощью ClassicLink и использовать частные IP-адреса этих инстансов в качестве целей, можно балансировать нагрузку и для инстансов EC2-Classic. Если в настоящий момент вы используете инстансы EC2 Classic с Classic Load Balancer, можно легко перейти на Application Load Balancer.

Балансировка нагрузки между зонами доступности в Application Load Balancer включена по умолчанию.

Аутентификацию через Amazon Cognito следует использовать в следующих случаях.

• Вы хотите предоставить пользователям возможность аутентифицироваться через поставщиков социальных удостоверений (Google, Facebook и Amazon), корпоративных удостоверений (SAML) или через собственные каталоги пользователей в форме Amazon Cognito User Pool.
• Вы управляете несколькими поставщиками удостоверений, включая OpenID Connect, и хотите создать единое правило аутентификации в Application Load Balancer (ALB), которое Amazon Cognito сможет использовать для федерации нескольких поставщиков удостоверений.
• Вы хотите активно управлять профилями пользователей с одним или несколькими социальными поставщиками или поставщиками удостоверений OpenID Connect из единого центра. Например, можно распределить пользователей по группам и добавить настраиваемые атрибуты, чтобы отражать состояние пользователя и контролировать доступ для платных пользователей.

В отличие от перечисленных вариантов, если вы инвестировали в разработку собственных решений IdP и просто хотите проводить аутентификацию пользователей через единый поставщик удостоверений, совместимый с OpenID Connect, вам подойдет использование встроенного решения OIDC в Application Load Balancer.

Балансировщик поддерживает три типа перенаправлений.

HTTP в HTTP
http://hostA в http://hostB

HTTP в HTTPS
http://hostA в https://hostB
https://hostA:portA/pathA в https://hostB:portB/pathB

HTTPS в HTTPS
https://hostA в https://hostB

Поддерживаются следующие типы контента: text/plain, text/css, text/html, application/javascript, application/json.

HTTP(S)-запросы, получаемые балансировщиком нагрузки, обрабатываются правилами маршрутизации на основе контента. Если содержимое запроса соответствует правилу с действием перенаправления запроса в целевую группу с функцией Lambda в качестве целевого объекта, вызывается соответствующая функция Lambda. Содержимое запроса (в том числе заголовки и его основная часть) передается функции Lambda в формате JSON. Ответ от функции Lambda также должен быть получен в формате JSON. Ответ от функции Lambda преобразуется в HTTP-ответ и отправляется клиенту. Балансировщик нагрузки вызывает функцию Lambda, используя API вызова AWS Lambda, и требует предоставить сервису Elastic Load Balancing разрешения на вызов вашей функции Lambda.

Да. Application Load Balancer поддерживает вызов Lambda для запросов по протоколам HTTP и HTTPS.

Использовать Lambda в качестве целевого объекта в работе с Балансировщиком нагрузки приложений можно в таких Регионах AWS: Восток США (Северная Вирджиния), Восток США (Огайо), Запад США (Северная Калифорния), Запад США (Орегон), Азиатско-Тихоокеанский регион (Мумбаи), Азиатско-Тихоокеанский регион (Сеул), Азиатско-Тихоокеанский регион (Сингапур), Азиатско-Тихоокеанский регион (Сидней), Азиатско-Тихоокеанский регион (Токио), Канада (Центральная), ЕС (Франкфурт), ЕС (Ирландия), ЕС (Лондон), ЕС (Париж), Южная Америка (Сан-Паулу) и GovCloud (США – запад).

Да, Балансировщик нагрузки приложений доступен в Локальной зоне в Лос-Анджелесе. В пределах локальной зоны Лос-Анджелеса Application Load Balancer работает в одной подсети и автоматически масштабируется в зависимости от изменения уровня нагрузки приложений без вмешательства оператора.

Плата взимается за каждый полный или неполный час работы Application Load Balancer, а также за количество единиц ресурса балансировщика нагрузки (LCU), использованных в течение часа.

LCU – это новая метрика для расчета стоимости использования Application Load Balancer. LCU определяет максимальный объем ресурсов, выраженных в любом из параметров (новые соединения, активные соединения, пропускная способность и оценки правил), которые Application Load Balancer использовал для обработки трафика.

Нет, плата за использование Classic Load Balancer по-прежнему будет начисляться на основании пропускной способности и почасового использования.

Использование всех четырех параметров, которые составляют LCU, подробно показано в Amazon CloudWatch.

Количество LCU в час будет определяться на основе максимального потребленного ресурса из числа четырех параметров, на основании которых рассчитывается LCU.

Да.

Да. Для новых аккаунтов AWS уровень бесплатного пользования Application Load Balancer предусматривает 750 часов и 15 LCU. Данное предложение по уровню бесплатного пользования доступно только для новых клиентов AWS и в течение 12 месяцев с момента регистрации в AWS.

Да. Можно использовать Classic Load Balancer и Application Load Balancer с 15 ГБ и 15 LCU соответственно. 750 часов работы балансировщика нагрузки распределяются между Classic Load Balancer и Application Load Balancer.

Оценки правил определяются как произведение количества обработанных правил и средней частоты запросов в час.

Размер ключа сертификата при начислении платы за LCU влияет только на количество новых подключений в секунду. В таблице ниже перечислены значения этого показателя для разных размеров ключей сертификатов RSA и ECDSA.

Сертификаты RSA
Размер ключа: <= 2 КБ 
Количество новых подключений в секунду: 25

Размер ключа: <= 4 КБ 
Количество новых подключений в секунду: 5

Размер ключа: <= 8 КБ 
Количество новых подключений в секунду: 1

Размер ключа: > 8 КБ
Количество новых подключений в секунду: 0,25

Сертификаты ECDSA
Размер ключа: <= 256
Количество новых подключений в секунду: 25

Размер ключа: <= 384
Количество новых подключений в секунду: 5

Размер ключа: <= 521 
Количество новых подключений в секунду: 1

Размер ключа: > 521 
Количество новых подключений в секунду: 0,25

Нет. При использовании Application Load Balancer балансировка нагрузки между зонами нагрузки всегда включена, поэтому с вас не взимается плата за передачу данных такого типа в регионе.

Нет. За использование возможности аутентификации пользователей в Application Load Balancer отдельная плата не начисляется. При использовании Amazon Cognito с Application Load Balancer применяются тарифы сервиса Amazon Cognito.

Плата взимается как обычно: за каждый полный или неполный час работы Балансировщика нагрузки приложений, а также за количество единиц ресурса балансировщика нагрузки (LCU), использованных в течение часа. Что касается целевых объектов Lambda, каждая LCU обеспечивает 0,4 ГБ обработанных байтов в час, 25 новых подключений в секунду, 3000 активных подключений в минуту и 1000 оценок правил в секунду. Для измерения обработанных байтов каждая LCU предоставляет 0,4 ГБ в час для целевых объектов Lambda и 1 ГБ в час для всех остальных типов целевых объектов, таких как инстансы, контейнеры и IP-адреса Amazon EC2. Обратите внимание, что на вызовы Lambda из Application Load Balancer распространяются стандартные тарифы AWS Lambda.

Балансировщики нагрузки приложений создают два новых типа метрик CloudWatch. Метрика LambdaTargetProcessedBytes показывает, какое количество байтов было обработано целевыми объектами Lambda, а метрика StandardProcessedBytes – какое количество байтов было обработано всеми остальными типами целевых объектов.

Да. Балансировщики Network Load Balancer поддерживают получателей TCP, UDP и TCP+UDP (уровень 4), а также получателей TLS.

Балансировщик сетевой нагрузки обеспечивает балансировку нагрузки TCP и UDP (уровень 4). Он предназначен для обработки миллионов запросов в секунду, трафика с внезапной или меняющейся нагрузкой и обеспечивает чрезвычайно низкие задержки. Кроме того, Network Load Balancer поддерживает терминацию TLS, сохраняет исходные IP-адреса клиентов, обеспечивает стабильную поддержку протокола IP и зональную изоляцию. Он также поддерживает длительные соединения, которые очень полезны для приложений, использующих подключения типа WebSocket.

Да. Для этого можно использовать получателя TCP+UDP. Например, для службы DNS, которая использует как протокол TCP, так и UDP, можно создать получателя TCP+UDP на порту 53, и на этом порту балансировщик нагрузки будет обрабатывать трафик для запросов по обоим протоколам. Получателя TCP+UDP требуется связать с целевой группой TCP+UDP.

Балансировщик сетевой нагрузки сохраняет IP-адрес источника клиента, который в Классическом балансировщике нагрузки не сохраняется. Клиенты для получения IP-адреса источника могут с Classic Load Balancer использовать протокол прокси. Network Load Balancer автоматически предоставляет балансировщику нагрузки статический IP-адрес в каждой зоне доступности, а также позволяет назначать эластичный IP-адрес. Для Classic Load Balancer такая возможность не поддерживается.

Да. Перейти на Network Load Balancer с Classic Load Balancer можно с помощью одного из вариантов, приведенных в этом документе.

Да, подробнее см. в документации по ограничениям для Балансировщика сетевой нагрузки.

Да, для настройки Network Load Balancer можно использовать Консоль управления AWS, интерфейс командной строки AWS или API.

Чтобы создать Classic Load Balancer, используйте API версии 2012-06-01. Чтобы создать Network Load Balancer или Application Load Balancer, используйте API версии 2015-12-01.

Да, можно создать Балансировщик сетевой нагрузки в одной Зоне доступности, предоставив одну подсеть при создании балансировщика нагрузки.

Да. Возможности переброса сервиса DNS и проверки работоспособности Amazon Route 53 еще больше повышают доступность приложений, работающих за пределами балансировщиков Network Load Balancer. Переброс сервиса DNS с помощью Route 53 позволяет поддерживать работу приложений в разных зонах доступности AWS и назначать альтернативные балансировщики нагрузки для переброса сервиса в другие регионы. 

В случае если имеется Network Load Balancer, настроенный для нескольких зон доступности, и если нет работоспособных инстансов Amazon EC2, зарегистрированных в балансировщике нагрузки для этой зоны доступности, или если узлы балансировщика нагрузки в данной зоне неработоспособны, Route 53 переключится на альтернативные узлы балансировщика нагрузки в других, работоспособных зонах доступности.

Нет. Адреса Network Load Balancer должны полностью контролировать либо вы, либо ELB. Это делается для того, чтобы при использовании эластичных IP-адресов с Network Load Balancer все адреса, известные вашим клиентам, не менялись.

Нет. Балансировщик сетевой нагрузки может поддерживать только один публичный или имеющий выход в Интернет IP-адрес для каждой подсети, связанной с Балансировщиком сетевой нагрузки.

Эластичные IP-адреса, связанные с балансировщиком нагрузки, вернутся в выделенный пул и будут доступны для будущего использования.

Балансировщик сетевой нагрузки можно настроить как балансировщик нагрузки с выходом в Интернет или как внутренний балансировщик нагрузки. Аналогичные возможности имеются в Балансировщике нагрузки приложений и в Классическом балансировщике нагрузки.

Для каждой подсети, связанной с балансировщиком нагрузки, Network Load Balancer может поддерживать только один частный IP-адрес.

Да, для этого настройте получателей TCP, которые направляют трафик на целевые объекты, реализующие протокол WebSockets (https://tools.ietf.org/html/rfc6455). Поскольку WebSockets является протоколом уровня 7, а Network Load Balancer работает на уровне 4, Network Load Balancer не выполняет никакой специальной обработки для WebSockets или других протоколов более высокого уровня.

Да. Можно использовать любой IP-адрес из диапазона CIDR VPC в качестве целевого объекта балансировщика нагрузки в VPC и любой IP-адрес из диапазонов RFC 1918 (10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16) или диапазона RFC 6598 (100.64.0.0/10) для целевых объектов, расположенных за пределами VPC балансировщика нагрузки (например, целевые объекты в инстансах EC2 Classic и в локальных местоположениях, доступных через подключения AWS Direct Connect). Использование IP‑адреса в качестве целевого объекта для балансировки нагрузки доступно только для получателей TCP и на данный момент не поддерживается для получателей UDP.

Да, Балансировщики сетевой нагрузки со слушателями TCP и TLS можно использовать для настройки AWS PrivateLink. Настройка PrivateLink с получателями UDP на балансировщиках Network Load Balancer не поддерживается.

Хотя протокол UDP не предполагает установку соединения, для обслуживания UDP‑потока балансировщик нагрузки вычисляет хэш‑функцию с кортежем из 5 полей таким образом, чтобы пакеты, отправленные в рамках одного контекста, направлялись на один и тот же целевой объект. Поток считается активным, пока продолжается обмен пакетами и не истечет время ожидания в режиме простоя. По истечении времени ожидания балансировщик нагрузки сбрасывает привязку. Следующий входящий пакет UDP будет считаться новым потоком и в рамках распределения нагрузки будет направлен на новый целевой объект.

Время ожидания Балансировщика сетевой нагрузки в режиме простоя для TCP‑соединений составляет 350 секунд. Время ожидания в режиме простоя для UDP‑потоков составляет 120 секунд.

Каждый контейнер в инстансе теперь может иметь собственную группу безопасности и не требует использовать правила безопасности, общие с другими контейнерами. Группы безопасности можно подключить к эластичному сетевому интерфейсу (ENI), при этом каждый ENI инстанса может иметь отдельную группу безопасности. Контейнер можно связать с IP-адресом определенного ENI для привязки группы (групп) безопасности к контейнеру. Балансировка нагрузки с использованием IP-адресов также позволяет нескольким контейнерам, работающим на одном инстансе, использовать один и тот же порт (например, порт 80). Возможность использования одного и того же порта несколькими контейнерами позволяет контейнерам, расположенным на одном инстансе, взаимодействовать друг с другом через известные, а не через случайные порты.

Есть несколько способов настройки гибридной балансировки нагрузки. Если приложение выполняется на целевых объектах, распределенных между VPC и локальной средой, их можно добавить в одну и ту же целевую группу, используя соответствующие IP-адреса. Чтобы перейти на AWS без ущерба для работы приложения, постепенно добавляйте в целевую группу цели VPC и удаляйте из нее локальные цели. Можно также применять отдельные балансировщики нагрузки для VPC и локальных целевых объектов и использовать весовой коэффициент DNS для достижения взвешенной балансировки нагрузки между VPC и локальными целевыми объектами.

Балансировать нагрузку для инстансов EC2-Classic при регистрации в качестве целей их идентификаторов нельзя. Однако если связать эти инстансы EC2-Classic с VPC балансировщика нагрузки с помощью ClassicLink и использовать частные IP-адреса этих инстансов в качестве целей, можно балансировать нагрузку и для инстансов EC2-Classic. Если в настоящий момент вы используете инстансы EC2 Classic с Classic Load Balancer, можно легко перейти на Network Load Balancer.

Балансировку нагрузки между зонами можно включить только после создания Network Load Balancer. Это можно сделать, отредактировав раздел атрибутов балансировки нагрузки и установив после этого флажок поддержки балансировки нагрузки между зонами.

Да, при включении балансировки нагрузки между зонами доступности в Network Load Balancer взимается плата за передачу данных в регионе между зонами. Тарифы см. в разделе передачи данных на странице цен на инстансы по требованию Amazon EC2..

Да. Network Load Balancer в настоящее время поддерживает 200 целевых объектов на каждую зону доступности. К примеру, при размещении в двух зонах доступности можно иметь до 400 целевых объектов, зарегистрированных в Network Load Balancer. Если балансировка нагрузки между зонами включена, максимальное количество целевых объектов уменьшается с 200 на каждую зону доступности до 200 на балансировщик нагрузки. Приведенный выше пример показывает, что когда включена балансировка нагрузки между зонами, даже если балансировщик нагрузки находится в 2 зонах доступности, количество зарегистрированных целевых объектов для балансировщика нагрузки не может превышать 200.

Да, вы можете выполнять терминацию подключений TLS с помощью Балансировщика сетевой нагрузки. Нужно установить для балансировщика нагрузки сертификат SSL. Балансировщик нагрузки использует этот сертификат для завершения подключения, а затем дешифрует запросы от клиентов перед их отправкой в целевые объекты.

Исходный IP-адрес сохраняется даже при терминации TLS в Балансировщике сетевой нагрузки.

Можно использовать Менеджер сертификатов AWS для распределения сертификатов SSL/TLS или создать запрос на получение сертификата из других источников. В последнем случае необходимо подписать сертификат в центре сертификации и загрузить его с помощью Менеджера сертификатов AWS (ACM) или Управления идентификацией и доступом AWS (AWS IAM).

SNI включается автоматически, если с одним обработчиком событий безопасности на балансировщике нагрузки связано несколько сертификатов TLS. Аналогичным образом режим SNI для обработчика событий безопасности отключается автоматически, если с этим обработчиком связан только один сертификат.

Балансировщик сетевой нагрузки интегрирован с Менеджером сертификатов AWS (ACM). Интеграция с ACM позволяет очень легко привязать сертификат к балансировщику нагрузки, тем самым сильно упрощая весь процесс выгрузки SSL. Процесс приобретения, загрузки и обновления сертификатов SSL/TLS является длительным, сложным и требует ручной работы. Интеграция ACM с Network Load Balancer сводит весь процесс к запросу доверенного сертификата SSL/TLS и затем выбору сертификата ACM для распределения с помощью балансировщика нагрузки. Создав балансировщик Network Load Balancer, вы можете настроить прослушиватель TLS, а затем выбрать сертификат из ACM или Identity Access Manager (IAM). Этот способ похож на тот, который предусматривает использование Application Load Balancer или Classic Load Balancer.

Нет, Балансировщик сетевой нагрузки поддерживает только шифрование для внутренних серверов.

Балансировщик сетевой нагрузки поддерживает только сертификаты RSA с размером ключа 2K. В настоящий момент мы не поддерживаем сертификаты RSA с размером ключа, который превышает 2K, или сертификаты ECDSA в Network Load Balancer.

Использовать терминацию TLS в Network Load Balancer можно в таких регионах AWS: Восток США (Северная Вирджиния), Восток США (Огайо), Запад США (Северная Калифорния), Запад США (Орегон), Азиатско-Тихоокеанский регион (Мумбаи), Азиатско-Тихоокеанский регион (Сеул), Азиатско-Тихоокеанский регион (Сингапур), Азиатско-Тихоокеанский регион (Сидней), Азиатско-Тихоокеанский регион (Токио), Канада (Центральная), ЕС (Франкфурт), ЕС (Ирландия), ЕС (Лондон), ЕС (Париж), Южная Америка (Сан-Паулу) и GovCloud (США – запад).

Плата взимается за каждый полный или неполный час работы Network Load Balancer, а также за количество единиц ресурса балансировщика нагрузки (LCU), использованных в течение часа.

LCU – это новая метрика для расчета стоимости использования Network Load Balancer. LCU определяет максимальный объем ресурсов, выраженных в любом из параметров (новые соединения/потоки, активные соединения/потоки и пропускная способность), которые Network Load Balancer использовал для обработки трафика.

Метрики LCU для трафика TCP выглядят следующим образом:

• 800 новых TCP‑соединений в секунду;
• 100 000 активных TCP‑соединений (за минуту);
• 1 ГБ в час для инстансов Amazon EC2, контейнеров и IP‑адресов как целевых объектов.

Метрики LCU для трафика UDP выглядят следующим образом:

• 400 новых потоков в секунду;
• 50 000 активных UDP‑потоков (за минуту);
• 1 ГБ в час для инстансов Amazon EC2, контейнеров и IP‑адресов как целевых объектов.

Метрики LCU для трафика TLS выглядят следующим образом:

• 50 новых TLS‑соединений в секунду;
• 3000 активных TLS‑соединений (за минуту);
• 1 ГБ в час для инстансов Amazon EC2, контейнеров и IP‑адресов как целевых объектов.

Нет, для каждого протокола плата начисляется только по одному из трех показателей (который характеризуется наибольшим использованием в течение часа).

Несколько запросов могут быть отправлены через одно соединение.

Плата за использование Классического балансировщика нагрузки по-прежнему будет начисляться на основании пропускной способности и почасового тарифа.

Использование всех трех параметров, на основании которых рассчитывается LCU, отображается в Amazon CloudWatch.

Нет. Количество LCU в час будет определяться на основе максимального ресурса, потребленного среди трех параметров, на основании которых рассчитывается LCU.

Да.

Да. Для новых аккаунтов AWS уровень бесплатного пользования Network Load Balancer предусматривает 750 часов и 15 LCU. Данное предложение по уровню бесплатного пользования доступно только для новых клиентов AWS и в течение 12 месяцев с момента регистрации в AWS.

Да. Можно использовать Application Load Balancer и Network Load Balancer с 15 LCU каждый и Classic Load Balancer с 15 ГБ. 750 часов работы балансировщика нагрузки распределяются между Application Load Balancer, Network Load Balancer и Classic Load Balancer.

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

Балансировщик нагрузки шлюза работает в пределах Зоны доступности.

Балансировщик нагрузки шлюза обеспечивает возможности балансировки шлюзов уровня 3 и уровня 4. Это прозрачное устройство защиты, которое не изменяет ни одну часть пакета. Оно предназначен для обработки миллионов запросов в секунду, трафика с внезапной или меняющейся нагрузкой и обеспечивает чрезвычайно низкую задержку. Подробнее о функциях Балансировщика нагрузки шлюза в этой таблице. 

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

Балансировщик нагрузки шлюза не поддерживает состояние приложения, однако он поддерживает закрепление потоков за конкретным устройством, используя для этого кортеж из пяти (для потоков TCP/UDP) или из трех полей (для остальных потоков).

Балансировщик нагрузки шлюза по умолчанию определяет поток как комбинацию из 5 кортежей, которая содержит IP-адрес источника, IP-адрес назначения, протокол, порт источника, порт назначения. Балансировщик нагрузки шлюза (GWLB) использует хэш кортежа из 5 полей и гарантирует, что оба направления этого потока (т.е. от источника к получателю и от получателя к источнику) последовательно перенаправляются к одному и тому же целевому объекту. Поток считается активным, пока продолжается обмен пакетами и не истечет время ожидания в режиме простоя. По истечении времени ожидания балансировщик нагрузки сбрасывает привязку. Следующий входящий пакет трафика будет считаться новым потоком и в рамках распределения нагрузки может быть направлен на новый целевой объект.

Стабильность по умолчанию из 5 кортежей (исходный IP-адрес, IP-адрес назначения, протокол IP, исходный порт и порт назначения) обеспечивает наиболее оптимальное распределение трафика между целевыми объектами и подходит для большинства приложений на основе TCP и UDP, за некоторыми исключениями. Стабильность по умолчанию из 5 кортежей не подходит для приложений на основе TCP или UDP, использующих отдельные потоки или номера портов для управления и данных, таких как FTP, Microsoft RDP, Windows RPC и SSL VPN. Управляющие потоки и потоки данных в таких приложениях могут располагаться на различных целевых устройствах, которые могут привести к прерыванию трафика. Если вы хотите поддерживать такие протоколы, вы можете включить закрепление потоков GWLB, используя 3 кортежа (IP источника, IP назначения, протокол IP) или 2 кортежа (IP источника, IP назначения).

Некоторые приложения вообще не используют транспорт TCP или UDP, а используют IP-протоколы, такие как SCTP и GRE. Поскольку GWLB по умолчанию использует 5 кортежей, потоки трафика по этим протоколам могут передаваться на разные целевые устройства и приводить к сбоям в работе. Если вы хотите поддерживать такие протоколы, вы можете включить закрепление потоков GWLB, используя 3 кортежа (IP источника, IP назначения, протокол IP) или 2 кортежа (IP источника, IP назначения).

О том, как изменить тип закрепления потоков, см. в документации по закреплению потоков.

Время ожидания Балансировщика нагрузки шлюза в режиме простоя для TCP‑соединений составляет 350 секунд. Время ожидания в режиме простоя для потоков кроме TCP составляет 120 секунд. Данные тайм-ауты фиксированы и не могут быть изменены.

Балансировщик GWLB работает в коммуникационном канале прозрачно, поэтому сам не фрагментирует и не собирает пакеты.

GWLB только пересылает фрагменты UDP от одних устройств к другим. Но учтите, что GWLB отбрасывает фрагменты TCP и ICMP, поскольку в них отсутствует заголовок уровня 4.

Кроме того, если целевое устройство разделит исходный входящий пакет на фрагменты и отправит их обратно в GWLB, эти новые фрагменты также будут удалены, поскольку не содержат заголовков уровня 4. Чтобы предотвратить фрагментацию на целевом устройстве, рекомендуем включить Jumbo-кадры или настроить для сетевого интерфейса использование максимального MTU, обеспечив тем самым прозрачную пересылку с сохранением всего содержимого исходного пакета. 

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

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

Да. Несколько балансировщиков нагрузки шлюза могут взаимодействовать с одним и тем же набором виртуальных устройств.

Балансировщик нагрузки шлюза – это прозрачное устройство защиты, которое прослушивает все виды IP-трафика (включая TCP, UDP, ICMP, GRE, ESP и другие). Следовательно, в Gateway Load Balancer можно создать только IP-прослушиватель.

Да, подробнее см. в документации по ограничениям для Балансировщика нагрузки шлюза.

Да, для настройки Балансировщика нагрузки шлюза можно использовать Консоль управления AWS, AWS CLI или API.

Да, можно создать Балансировщик нагрузки шлюза в одной Зоне доступности, предоставив одну подсеть при создании Балансировщика нагрузки. Тем не менее, мы рекомендуем использовать несколько зон доступности, чтобы повысить уровень доступности. Зоны доступности для балансировщика нагрузки шлюза нельзя удалить после его создания.

По умолчанию балансировка нагрузки между Зонами доступности отключена. Балансировку нагрузки между зонами можно включить только после создания Gateway Load Balancer. Это можно сделать, отредактировав раздел атрибутов балансировки нагрузки и установив после этого флажок поддержки балансировки нагрузки между зонами доступности.

Да, при включении балансировки нагрузки между Зонами доступности в Балансировщике нагрузки шлюза взимается плата за передачу данных между зонами. Тарифы см. в разделе передачи данных на странице цен на инстансы по требованию Amazon EC2.

Да. Gateway Load Balancer в настоящее время поддерживает 300 целевых объектов на каждую зону доступности. К примеру, при создании Gateway Load Balancer в 3 зонах доступности можно иметь до 900 зарегистрированных целевых объектов. Если балансировка нагрузки между зонами включена, максимальное количество целевых объектов уменьшается с 300 на каждую зону доступности до 300 на один балансировщик Gateway Load Balancer.

Плата взимается за каждый полный или неполный час работы Балансировщика нагрузки шлюза, а также за количество единиц ресурса Балансировщика нагрузки шлюза (GLCU), использованных им в течение часа.

LCU – это параметр Эластичной балансировки нагрузки (ELB), который показывает размер платы за Балансировщик нагрузки шлюза. LCU определяет максимальный объем ресурсов, выраженных в любом из параметров (новые подключения/потоки, активные подключения/потоки и пропускная способность), которые Gateway Load Balancer использовал для обработки трафика.

Метрики LCU для трафика TCP выглядят следующим образом:

• 600 новых потоков (или соединений) в секунду;
• 60 000 активных потоков или соединений (поминутно);
• 1 ГБ в час для инстансов EC2, контейнеров и IP‑адресов как целевых объектов.

Нет, плата начисляется только по одному из трех показателей (который характеризуется наибольшим использованием в течение часа).

Несколько запросов могут быть отправлены через одно соединение.

Вы можете отследить использование всех трех измерений LCU через Amazon CloudWatch.

Да.

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

Благодаря использованию адреса балансировщика нагрузки шлюза устройства могут находиться в разных учетных записях AWS и в разных VPC. Это позволяет централизовать устройства в одном местоположении и, как следствие, упростить управление и снизить операционные расходы.

Адреса балансировщиков нагрузки шлюза представляют собой новый тип адреса VPC, который использует технологию PrivateLink. Во время передвижения сетевого трафика от источника (шлюз Интернета, VPC и т. п.) к балансировщику нагрузки шлюза и в обратном направлении адрес балансировщика нагрузки шлюза гарантирует частное подключение между ними. Весь трафик движется по сети AWS, а данные не имеют доступа к Интернету, что позволяет повысить не только безопасность, но и производительность.

Адрес интерфейса PrivateLink связан с Network Load Balancer (NLB), что обеспечивает возможность распределения трафика TCP и UDP, предназначенного для интернет-приложений. Адреса балансировщиков нагрузки шлюза используются с балансировщиками нагрузки шлюза для подключения к источнику и адресату трафика. Трафик движется от адреса балансировщика нагрузки шлюза к балансировщику нагрузки через виртуальные устройства и в обратном направлении к адресату через защищенные подключения PrivateLink.

Адрес балансировщика нагрузки шлюза является адресом VPC, и количество адресов VPC, которые можно подключить к сервису, использующему балансировщик нагрузки шлюза, не ограничено. Однако мы рекомендуем подключать к одному балансировщику нагрузки шлюза не более 50 адресов балансировщиков нагрузки шлюза, чтобы снизить риск обширного влияния при сбое сервиса.

Classic Load Balancer поддерживает инстансы Amazon EC2 с любыми операционными системами, которые на данный момент поддерживает сервис Amazon EC2.

Classic Load Balancer поддерживает распределение нагрузки на приложения с помощью протоколов HTTP, HTTPS (Secure HTTP), SSL (Secure TCP) и TCP.

Применить распределение нагрузки можно к следующим портам TCP:

• [EC2-VPC] 1-65535;
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535.

Да. С каждым Classic Load Balancer связано имя DNS с протоколом IPv4, IPv6 и двойным стеком (одновременно IPv4 и IPv6). IPv6 не поддерживается в VPC. Для VPC можно использовать балансировщик Application Load Balancer, обладающий встроенной поддержкой IPv6.

Да.

При использовании Amazon Virtual Private Cloud (Amazon VPC) для интерфейса Классических балансировщиков нагрузки можно настроить группы безопасности.

Да. Порт 80 для HTTP и порт 443 для HTTPS можно привязать к одному и тому же Classic Load Balancer.

Для Classic Load Balancer не предусмотрено максимальное количество попыток подключения с целью распределения нагрузки на инстансах Amazon EC2. Это количество масштабируется в соответствии с количеством одновременных запросов HTTP, HTTPS или SSL либо с количеством одновременных подключений TCP, которые принимает Classic Load Balancer.

На инстансах Amazon EC2, запущенных с помощью платного AMI с портала AWS Marketplace, можно распределять нагрузку. Однако Классический балансировщик нагрузки не поддерживает инстансы, запущенные с помощью платных образов AMI с веб-сайта Amazon DevPay.

Да. См. веб-страницу об Эластичной балансировке нагрузки (ELB).

Да. Чтобы получить журнал всех обращений API Classic Load Balancer к вашему аккаунту, просто включите сервис CloudTrail в Консоли управления AWS.

Да, Классический балансировщик нагрузки поддерживает SSL-терминацию. Для этого на балансировщике нагрузки должен быть установлен сертификат SSL. Балансировщики нагрузки используют этот сертификат для терминации подключения, а затем дешифрует запросы от клиентов перед их отправкой к серверным инстансам.

Для получения сертификата SSL/TLS можно использовать Менеджер сертификатов AWS (ACM) или создать запрос на получение сертификата из других источников. Затем необходимо подписать сертификат в центре сертификации и загрузить его с помощью Управления идентификацией и доступом AWS (AWS IAM).

Балансировщики Classic Load Balancer теперь интегрированы с сервисом AWS Certificate Manager (ACM). Интеграция с ACM позволяет очень легко привязать сертификат к балансировщику нагрузки, тем самым сильно упрощая весь процесс выгрузки SSL. Обычно процесс приобретения, загрузки и обновления сертификатов SSL/TLS является длительным, сложным и требует ручной работы. Интеграция ACM с Classic Load Balancer сводит весь процесс к запросу доверенного сертификата SSL/TLS и затем выбору сертификата ACM для распределения его по всем балансировщикам нагрузки.

Балансировку нагрузки между Зонами доступности можно включить с помощью консоли, CLI или AWS SDK. Подробнее см. в документации по балансировке нагрузки между Зонами доступности.

Нет, при включении балансировки нагрузки между Зонами доступности в Классическом балансировщике нагрузки плата за передачу данных в регионе между Зонами доступности не взимается.