Uma aplicação web é executada em instâncias EC2 em sub-redes privadas em três Zonas de Disponibilidade, atrás de um ALB. O SSL/TLS é encerrado no ALB usando certificados ACM. Nos testes com uma única instância, tudo funcionou, mas após a implantação em produção, os usuários conseguem fazer login, mas cada nova solicitação web reinicia o fluxo de login. O que o engenheiro de rede deve fazer para corrigir isso?

A opção correta é modificar a configuração do grupo de destino do ALB habilitando a aderência (stickiness) com um cookie baseado na aplicação. O problema descrito, onde cada nova solicitação web reinicia o fluxo de login, indica que as solicitações do usuário não estão sendo direcionadas consistentemente para a mesma instância EC2 após o login inicial. A aderência de sessão (session stickiness) garante que as solicitações de um cliente específico sejam sempre enviadas para a mesma instância, mantendo o estado da sessão. Usar um cookie baseado na aplicação permite que a aplicação gerencie a sessão de forma mais granular. As outras opções estão incorretas porque: Modificar a configuração do listener do ALB para aderência no nível do grupo é uma opção, mas a aderência no grupo de destino é mais apropriada para gerenciar o estado da sessão em um ALB. Substituir o ALB por um Network Load Balancer (NLB) não resolveria o problema de aderência de sessão, pois o NLB opera na camada 4 e não tem a funcionalidade de aderência de sessão baseada em cookies HTTP/HTTPS como o ALB. Remover o ALB e usar o Route 53 com roteamento de failover não aborda a necessidade de manter o estado da sessão entre as solicitações do usuário.