Una aplicación web se ejecuta en instancias EC2 en subredes privadas a través de tres zonas de disponibilidad detrás de un ALB. SSL/TLS termina en el ALB usando certificados ACM. En las pruebas con una sola instancia, todo funcionó, pero después de la implementación en producción, los usuarios pueden iniciar sesión, pero cada nueva solicitud web reinicia el flujo de inicio de sesión. ¿Qué debe hacer el ingeniero de redes para solucionar esto?

El problema de que los usuarios deban iniciar sesión repetidamente sugiere que las solicitudes se distribuyen entre diferentes instancias EC2, perdiendo el estado de la sesión. La persistencia de la sesión (sticky sessions) en el Application Load Balancer (ALB) es la solución. Al habilitar la persistencia en el grupo de destino del ALB y configurarla para usar una cookie basada en la aplicación con una duración que coincida con la sesión de la aplicación, el ALB dirigirá las solicitudes posteriores del mismo usuario a la misma instancia EC2. Las otras opciones son incorrectas porque: Modificar la configuración del listener del ALB para habilitar la persistencia a nivel de grupo no es la configuración correcta; la persistencia se configura en el grupo de destino. Reemplazar el ALB por un Network Load Balancer (NLB) no es adecuado. Los NLB operan en la capa 4 y no manejan la persistencia de sesiones basada en cookies de aplicación, que es necesaria aquí. Eliminar el ALB y usar Route 53 con certificados ACM para cada instancia EC2 elimina la funcionalidad de balanceo de carga y la terminación SSL/TLS centralizada, lo cual no resuelve el problema de la sesión y añade complejidad innecesaria.