Você pode tentar usar um balanceador de carga TCP / SSL . Ele funciona na camada TCP (camada 4), ao contrário da camada de aplicação que escuta http / https (camada 7). O protocolo de proxy também pode ajudar.
Com os balanceadores de carga SSL e HTTPS, acho que o ELB encerra a conexão TCP e inicia outra conexão do ELB para o serviço de backend. Você poderia considerar outras soluções de balanceamento de carga. ELB é gerenciado HAProxy, você pode executar uma instância do EC2 com qualquer balanceador de carga que desejar e colocá-lo em um grupo de dimensionamento automático com um tamanho de um, caso ele falhe, ele volta automaticamente.
Os conjuntos de recursos ponderados do Route 53 podem ser outra maneira de abordar isso. Basicamente, os clientes são roteados para servidores com base nos pesos que você especifica. Você criaria vários registros no mesmo conjunto, apontando para diferentes instâncias do EC2. Não é realmente escalável, e é manual, então não é uma ótima solução.
A melhor opção pode ser dimensionar verticalmente (ou seja, obter uma instância maior) e não se incomodar com um balanceador de carga. Se todos os servidores terminarem o TCP e a autenticação, eles devem lidar com muito tráfego. Como alternativa, você pode reconsiderar como está fazendo a autenticação.
Atualizar Com base no que Michael disse no comentário eu fiz um pouco mais de leitura. Acho que ele provavelmente está certo, um balanceador de carga TCP ( SSL) é mais provável que sejam as conexões de passagem sem alterá-las, como um roteador.
Minha sugestão de escalar verticalmente é porque você pode achar que até uma m4.16XL pode ser suficiente, se ela atender aos requisitos de capacidade e confiabilidade. Seria mais fácil implantar um único servidor do que um balanceador de carga e vários servidores, além de economizar o custo do ELB. Provavelmente será menos confiável.