Existem informações conflitantes sobre isso on-line. Alguns recursos dizem que o ELB repete uma solicitação se passar do tempo limite padrão de 60 segundos antes que uma resposta seja recebida do servidor, mas eles são minoria. Alguns dizem que o ELB não repete pedidos. A documentação da AWS não diga o que acontece quando um tempo limite do ELB é excedido - uma omissão bastante significativa. Com base no que eu li, tendem a pensar que, se o servidor back-end expirar, o cliente receberá um código de erro, provavelmente 408 de tempo limite. Você deve testar isso, e meu conselho abaixo é baseado nesta suposição. Se o ELB tentar novamente, meu conselho abaixo está incorreto.
Não acredito que seja possível usar o ELB para um aplicativo da web padrão devido à falta de novas tentativas. Maior imagem, você não pode garantir 100% de disponibilidade, é praticamente impossível. Você precisa definir sua disponibilidade para um nível realista e, em seguida, arquitetar seu sistema para conseguir isso. Por exemplo, você pode ter duas regiões ativas, o Route 53 fazendo o balanceamento de carga geográfico com o failover. No entanto, você não receberá 100% da sua configuração para testar e enviar solicitações para instâncias que possam ser consideradas saudáveis, e não para repetir solicitações se elas falharem.
O ELB não tentará novamente uma solicitação se um servidor estiver inativo ou expirar. Você teria que inserir sua própria lógica ou balanceador de carga, o que poderia falhar. O hardware fora da AWS pode funcionar, mas não é uma boa ideia, e seu próprio balanceador de carga dentro da AWS é uma má ideia, pois é improvável que você seja capaz de criar um balanceador de carga tão confiável quanto o ELB.
Sugiro que você se concentre em tornar seus servidores da web / aplicativos estáveis, escalonáveis e sem estado, para que possam ser ampliados e reduzidos conforme necessário.