Un seul ELB achemine le trafic vers exactement un ensemble d'instances et distribue le trafic entrant à toutes les instances "derrière". Il n'achemine pas le trafic de manière sélective sur la base d'une analyse de la couche 7 du trafic, telle que l'en- Host:tête.
Vous avez besoin d' un ELB pour chaque ensemble d'instances. Comme vous le décrivez, c'est un ELB pour chaque webapp.
Si votre objectif principal pour exécuter ELB est de décharger le SSL à l'aide d'un certificat générique (j'ai un système conçu comme celui-ci, avec des dizaines d'applications vivant sur many-different-domains.my-wildcard-cert-domain.com), alors les instances "derrière" l'ELB pourrait exécuter un proxy inverse tel que HAProxy (ou plusieurs autres alternatives, comme Varnish) qui peut prendre des décisions de routage de couche 7, puis transférer le trafic vers le sous-ensemble approprié de machines derrière eux, ce qui permet également des opérations plus sophistiquées. l'équilibrage de charge et a l'avantage de vous fournir des statistiques et des compteurs de trafic, agrégés et séparés.
/-- HAProxy \ /----- instances hosting app #1
ELB ---| >> ----- instances hosting app #2
\-- HAProxy / \----- instances hosting app #n
Les instances intermédiaires ^^^^ peuvent évaluer les en- Host:têtes (entre autres) et même capturer la valeur du cookie de session dans leurs journaux pour analyse.
Cette configuration me permet également d'exécuter plusieurs applications sur des sous-ensembles d'instances qui se chevauchent, le cas échéant, et de faire beaucoup d'autres choses que ELB en soi ne prend pas directement en charge. Il renvoie également une page "503" personnalisée dans le cas où une application est surchargée ou devient indisponible, ce que ELB ne fait pas de lui-même. J'ai représenté 2 serveurs proxy ici, sans autre raison que votre mention du numéro 2 dans la question. Ma configuration a en fait 3, un pour chaque zone de disponibilité dans la région où cela est déployé.