Un solo ELB enruta el tráfico exactamente a un conjunto de instancias y distribuye el tráfico entrante a todas las instancias "detrás" de él. No enruta selectivamente el tráfico en función de ningún análisis de capa 7 del tráfico, como el Host:
encabezado.
Necesita un ELB para cada conjunto de instancias. Como lo describe, ese es un ELB para cada aplicación web.
Si su propósito principal para ejecutar ELB es descargar el SSL utilizando un certificado comodín (tengo un sistema diseñado así, con docenas de aplicaciones que viven en muchos-diferentes-dominios.my-wildcard-cert-domain.com), entonces las instancias "detrás" el ELB podría estar ejecutando un proxy inverso como HAProxy (u otras alternativas, como Varnish) que puede tomar decisiones de enrutamiento de capa 7 y luego reenviar el tráfico al subconjunto apropiado de máquinas detrás de ellos, lo que también permite equilibra la carga y tiene la ventaja de proporcionarle estadísticas y contadores de tráfico, agregados y separados.
/-- HAProxy \ /----- instances hosting app #1
ELB ---| >> ----- instances hosting app #2
\-- HAProxy / \----- instances hosting app #n
Las instancias ^^^^ intermedias pueden evaluar los Host:
encabezados (entre otras cosas) e incluso capturar el valor de la cookie de sesión en sus registros para su análisis.
Esta configuración también me permite ejecutar múltiples aplicaciones en subconjuntos de instancias superpuestas, cuando corresponda, y hacer muchas otras cosas que ELB por sí solo no admite directamente. También devuelve una página personalizada "503" en el caso de que una aplicación se sobrecargue o no esté disponible, lo que ELB no hace por sí solo. He representado 2 servidores proxy aquí, sin otra razón en particular que tu mención del número 2 en la pregunta. Mi configuración en realidad tiene 3, uno para cada zona de disponibilidad en la región donde se implementa.