Ответ 1

Обновление 2017-04-05

После запуска нового Балансировщика нагрузки приложений с поддержкой маршрутной маршрутизации прошлым летом (см. предыдущее обновление) AWS теперь также добавила Поддержка маршрутизации на основе хоста для AWS Application Load Balancers:

[...] Теперь вы можете создавать правила балансировки нагрузки приложения, которые маршрутизируют входящие трафик на основе имени домена, указанного в заголовке Host. Запросы api.example.com могут быть отправлены в одну целевую группу, запросы на mobile.example.com на другой, а все остальные (по умолчанию правило) может быть отправлено на третью. Вы также можете создавать правила, которые объединяют хост-маршрутизацию и маршрутизацию на основе маршрутов. Это позволит вам запрос маршрута на api.example.com/production и api.example.com/sandbox для различных целевых групп.

Обновление 2016-08-11

AWS только что (11 августа 2016 г.) запустил новый Балансировщик нагрузки приложения для службы балансировки эластичной нагрузки, который предназначен для повышения гибкости и производительность приложений реального времени, микросервисов, контейнерных архитектур и потоковых приложений:

Этот новый балансировщик нагрузки, который также поддерживает протокол WebSocket и HTTP/2, работает на уровне приложения и предоставляет контент маршрутизации. Это позволяет балансировщику нагрузки приложения маршрутизировать запросы через несколько служб или контейнеров, работающих на одном или нескольких Экземпляры Amazon Elastic Compute Cloud (Amazon EC2), помогающие уменьшить затрат и упрощения поиска услуг. [акцент мой]

Как подчеркивалось в вводном сообщении в блоге, эта новая опция Load Load Balancer для ELB [...] работает на уровне 7 и поддерживает количество дополнительных функций [whereras] исходный вариант (теперь называемый Classic Load Balancer) по-прежнему доступен вам и продолжает предлагать функциональные возможности уровня 4 и уровня 7.

В частности, ELB теперь поддерживает сценарий под рукой, поскольку каждый Балансировщик нагрузки приложений позволяет определить до 10 правил на основе URL для маршрутизации запросов к целевым группам (планы AWS дают вам доступ к другим методам маршрутизации с течением времени).

Исходный ответ

Это невозможно - Amazon ELB в основном (но см. ниже) обеспечивает балансировку нагрузки на транспортном уровне (OSI уровень 4), который основывает свои решения по балансировке нагрузки исключительно на TCP-соединении, но игнорирует полезную нагрузку приложения. Последнее позволило бы сбалансировать нагрузку на уровне приложений (OSI уровень 7), где полезная нагрузка приложения принимается во внимание для решений по балансировке нагрузки.

Конфигурация по умолчанию в Amazon ELB фактически обеспечивает базовую поддержку уровня приложения для HTTP/HTTPS/SSL (например, завершение соединений SSL и вставка заголовков X-Forwarded-*), но вы не можете настроить эту конфигурацию; по-другому, ELB действительно ищет HTTP-запрос здесь, но вы не контролируете поведение ELB в этом отношении.

Это более подробно объясняется в Выбор прослушивателей для балансировки нагрузки, например:

Использование TCP/SSL (уровень 4) с балансировкой упругой нагрузки

Когда вы используете TCP для интерфейсных и внутренних подключений, ваш балансировщик нагрузки перенаправляет запрос на внешние экземпляры без изменения заголовков. Эта конфигурация также не будет вставить файлы cookie для прикрепления сеанса или заголовки X-Forwarded- *.

[...]

Использование HTTP/HTTPS (уровень 7) с балансировкой упругой нагрузки

Когда вы используете HTTP (уровень 7) как для интерфейсных, так и для внутренних соединений, ваш балансировщик нагрузки анализирует заголовки в запросе и завершает соединение перед повторной отправкой запроса на зарегистрированный экземпляр (ы). Это стандартная конфигурация, предоставляемая Эластичная балансировка нагрузки.

[акцент мой]

Архитектурный обзор содержит иллюстрации и более подробную информацию.

Ответ 2

Прошли годы с тех пор, как вы опубликовали свой вопрос, но Amazon недавно объявила о функциональности балансировки нагрузки приложения (уровень 7). Это должно поддерживать то, что вы ищете.

В принципе, вы можете определить разные целевые группы, на которые трафик маршрутизируется на основе "правила" (например, шаблона пути URL). При необходимости правила могут быть приоритетными.

Подробнее см. https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/

Ответ 3

Вот возможное решение, которое я видел. Это не так идеально, как использование родного Nginx Plus для балансировки нагрузки, но если вам нужно использовать ELB, он работает.

Давайте представим себе такую ​​архитектуру:

                        ELB
                         |
          Server 1    Server 2   Server...
          (Current)   (Current)  (Current)
              \           |         /
                      Server X
                      (Legacy)

Каждый из серверов первого уровня выполняет "текущую" реализацию. Они также запускают Nginx или Apache в качестве веб-сервера (это, как правило, лучший опыт перед любым веб-приложением, IMO) перед уровнем приложения.

Каждый из конфигурационных файлов Nginx/Apache содержит строку, проверяющую параметр URL, указывающий, что это устаревший вызов, который проксирует запрос на сервер X. Если это не унаследованный вызов, он просто продолжает запрос к текущему приложению.

Недостатком является то, что вы используете несколько циклов на текущих серверах для прокси-сервера для старого сервера, но ваша архитектура довольно проста и у вас есть централизованный поток.