Pojedynczy ELB kieruje ruch do dokładnie jednego zestawu instancji i dystrybuuje ruch przychodzący do wszystkich instancji „za nim”. Nie kieruje selektywnie ruchu na podstawie analizy ruchu w warstwie 7, takiej jak Host:nagłówek.
Potrzebujesz jednego ELB dla każdego zestawu instancji. Jak to opisujesz, jest to jeden ELB dla każdej aplikacji internetowej.
Jeśli Twoim głównym celem uruchamiania ELB jest odciążanie SSL przy użyciu certyfikatu wieloznacznego (mam jeden system zaprojektowany w ten sposób, z dziesiątkami aplikacji żyjących na wielu-domen-domen.my-wildcard-cert-domain.com), to instancje „za” ELB może uruchamiać zwrotny serwer proxy, taki jak HAProxy (lub kilka innych alternatyw, takich jak Varnish), który może podejmować decyzje dotyczące routingu w warstwie 7, a następnie przekazywać ruch do odpowiedniego podzbioru maszyn za nimi, co pozwala również na bardziej wyrafinowane równoważenie obciążenia i ma tę zaletę, że zapewnia statystyki i liczniki ruchu, agreguje i rozdziela.
/-- HAProxy \ /----- instances hosting app #1
ELB ---| >> ----- instances hosting app #2
\-- HAProxy / \----- instances hosting app #n
Pośrednie instancje ^^^^ mogą oceniać Host:nagłówki (między innymi), a nawet przechwytywać wartość pliku cookie sesji w swoich dziennikach do analizy.
Ta konfiguracja pozwala mi również uruchamiać wiele aplikacji na nakładających się podzbiorach instancji, tam gdzie jest to właściwe, i wykonywać wiele innych rzeczy, których ELB nie obsługuje bezpośrednio. Zwraca również niestandardową stronę „503” w przypadku, gdy aplikacja zostanie przeciążona lub w inny sposób stanie się niedostępna, czego ELB nie robi samodzielnie. Zilustrowałem tutaj 2 serwery proxy, bez konkretnego powodu oprócz Twojej wzmianki o numerze 2 w pytaniu. Moja konfiguracja ma 3, po jednej dla każdej strefy dostępności w regionie, w którym jest wdrożona.