Um único ELB roteia o tráfego para exatamente um conjunto de instâncias e distribui o tráfego recebido para todas as instâncias "por trás" dele. Ele não roteia seletivamente o tráfego com base em qualquer análise da camada 7 do tráfego, como o Host:cabeçalho.
Você precisa de um ELB para cada conjunto de instâncias. Como você descreve, esse é um ELB para cada aplicativo da web.
Se o seu objetivo principal de executar o ELB for descarregar o SSL usando um certificado curinga (eu tenho um sistema projetado assim, com dezenas de aplicativos vivendo em muitos domínios diferentes.my-wildcard-cert-domain.com), as instâncias "atrás", o ELB pode estar executando um proxy reverso, como o HAProxy (ou várias outras alternativas, como o Varnish), que pode tomar decisões de roteamento da camada 7 e encaminhar o tráfego para o subconjunto apropriado de máquinas por trás deles, o que também permite mais sofisticado balanceamento de carga e tem a vantagem de fornecer estatísticas e contadores de tráfego, agregados e separados.
/-- HAProxy \ /----- instances hosting app #1
ELB ---| >> ----- instances hosting app #2
\-- HAProxy / \----- instances hosting app #n
As instâncias intermediárias podem avaliar os Host:cabeçalhos (entre outras coisas) e até capturar o valor do cookie da sessão em seus logs para análise.
Essa configuração também me permite executar vários aplicativos em subconjuntos de instâncias sobrepostos, quando apropriado, e fazer muitas outras coisas que o ELB por si só não suporta diretamente. Ele também retorna uma página "503" personalizada no caso em que um aplicativo fica sobrecarregado ou fica indisponível, o que o ELB não faz por conta própria. Eu descrevi dois servidores proxy aqui, por nenhum motivo específico além da sua menção ao número 2 na pergunta. Minha configuração na verdade tem 3, um para cada zona de disponibilidade na região em que isso é implantado.