Una empresa tiene 10 instancias EC2 de servidor web en un grupo de Auto Scaling en una VPC de producción y 10 servidores web on-premises. Un Direct Connect de 10 Gbps enlaza el centro de datos con la VPC. La solución debe aceptar HTTPS de miles de usuarios externos y distribuir las sesiones entre los servidores de AWS y los on-prem. Cada solicitud HTTPS debe permanecer en el mismo servidor backend durante toda la sesión, independientemente de la ubicación del servidor. ¿Qué diseño satisface estos requisitos?

La opción correcta es la única que cumple con todos los requisitos. Un Application Load Balancer (ALB) es ideal para distribuir tráfico HTTPS y ofrece afinidad de sesión basada en la aplicación (sticky sessions), lo cual es crucial para mantener a los usuarios en el mismo servidor durante toda la sesión. El tipo de objetivo 'ip' permite registrar tanto las instancias EC2 como los servidores on-premises (accesibles a través de Direct Connect) en el mismo grupo objetivo, ya que se pueden especificar sus direcciones IP. Las opciones incorrectas fallan porque: Un Network Load Balancer (NLB) no es adecuado para la afinidad de sesión basada en la aplicación (sticky sessions) ni para el tráfico HTTPS a este nivel, y el vaciado de conexiones (connection draining) no es lo mismo que la afinidad de sesión. Las opciones que especifican 'instance' como tipo de objetivo no permiten registrar servidores on-premises directamente, ya que estos no son instancias EC2.