Una región primaria de AWS aloja una aplicación web y una región secundaria está en espera para la recuperación ante desastres. Requisitos: los datos de sesión deben replicarse entre regiones casi en tiempo real; el 1% del tráfico debe enrutarse a la secundaria continuamente; conmutación por error automática a la secundaria en caso de interrupción de la primaria; la secundaria debe escalar para manejar el tráfico completo. ¿Cómo se deben cumplir estos requisitos?

La opción correcta cumple con todos los requisitos. Elastic Beanstalk simplifica la implementación de la aplicación en ambas regiones. Las tablas globales de DynamoDB proporcionan replicación casi en tiempo real de los datos de sesión, esencial para la persistencia de la sesión entre regiones. Una política de enrutamiento ponderado de Route 53 con comprobaciones de estado permite enviar el 1% del tráfico a la región secundaria para pruebas continuas y, en caso de interrupción de la primaria, las comprobaciones de estado fallarían, redirigiendo automáticamente el tráfico a la secundaria. La secundaria, al estar implementada de manera similar, puede escalar para manejar el tráfico completo. Las opciones incorrectas fallan por varias razones: La opción con política de enrutamiento de conmutación por error de Route 53 solo enviaría tráfico a la secundaria si la primaria falla, no el 1% continuamente. La opción con Lambda y RDS for PostgreSQL introduce complejidad innecesaria para los datos de sesión y la replicación, y la lógica del lado del cliente para llamar a API Gateway no es la forma estándar de enrutar tráfico entre regiones para una aplicación web. La opción con CloudFront no es la herramienta principal para el enrutamiento de tráfico entre regiones con lógica de conmutación por error y ponderación basada en el estado de la aplicación, y no aborda la replicación de datos de sesión de manera óptima.