Один ELB направляет трафик ровно одному набору экземпляров и распределяет входящий трафик всем экземплярам, находящимся за ним. Он не осуществляет выборочную маршрутизацию трафика на основе анализа трафика любого уровня 7, такого как Host:заголовок.
Вам нужен один ELB для каждого набора экземпляров. Как вы описываете, это один ELB для каждого веб-приложения.
Если вашей основной целью запуска ELB является разгрузка SSL с использованием подстановочного сертификата (у меня есть одна система, спроектированная таким образом, с десятками приложений, расположенных по адресу many-different-domains.my-wildcard-cert-domain.com), тогда экземпляры «позади» ELB может работать обратный прокси-сервер, такой как HAProxy (или несколько других альтернатив, таких как Varnish), который может принимать решения о маршрутизации уровня 7, а затем перенаправлять трафик на соответствующее подмножество машин позади них, что также позволяет использовать более сложные балансировка нагрузки и имеет преимущество, предоставляя вам статистику и счетчики трафика, совокупные и раздельные.
/-- HAProxy \ /----- instances hosting app #1
ELB ---| >> ----- instances hosting app #2
\-- HAProxy / \----- instances hosting app #n
Промежуточные экземпляры ^^^^ могут оценивать Host:заголовки (помимо всего прочего) и даже записывать значение файла cookie сеанса в свои журналы для анализа.
Эта настройка также позволяет мне запускать несколько приложений на перекрывающихся подмножествах экземпляров, где это уместно, и делать много других вещей, которые ELB не поддерживает напрямую. Он также возвращает пользовательскую страницу «503» в случае, если приложение перегружено или иным образом становится недоступным, что ELB не делает самостоятельно. Здесь я изобразил 2 прокси-сервера, и ни по какой другой причине, кроме вашего упоминания номера 2 в вопросе. В моей настройке фактически 3, по одному на каждую зону доступности в регионе, где это развернуто.