Una empresa aloja un sitio web con un servicio de backend implementado en una región primaria de AWS y una región de recuperación ante desastres (DR). Una única distribución de Amazon CloudFront se encuentra al frente del sitio. La empresa creó un registro de conmutación por error de Route 53 con comprobaciones de estado que apuntan al backend de la región primaria y configuró ese registro como un origen para la distribución de CloudFront. Un registro secundario de conmutación por error de Route 53 apunta al backend de la región de DR. Ambos registros de Route 53 tienen un TTL de 60 segundos, pero la conmutación por error actualmente tarda más de un minuto. ¿Qué diseño proporciona el tiempo de conmutación por error más rápido?

La opción correcta es crear un grupo de origen de CloudFront con ambos backends y configurar la conmutación por error de origen. CloudFront Origin Failover permite que la distribución cambie automáticamente a un origen secundario si el origen primario devuelve códigos de error HTTP específicos o no responde, lo que resulta en una conmutación por error casi instantánea y transparente para el usuario final. Las otras opciones son incorrectas porque: Implementar una segunda distribución de CloudFront y usar Route 53 para conmutar por error entre ellas introduciría la latencia del DNS (incluso con un TTL bajo) y no sería tan rápido como la conmutación por error de origen nativa de CloudFront. Cambiar el TTL de Route 53 a 4 segundos reduciría el tiempo de conmutación por error de Route 53, pero aún dependería de la propagación del DNS y no sería tan rápido como la conmutación por error de origen de CloudFront. Además, un TTL tan bajo puede aumentar la carga en los servidores DNS. Usar una política de enrutamiento de latencia de Route 53 no es para conmutación por error, sino para dirigir a los usuarios al origen con la latencia más baja, lo cual no resuelve el problema de la conmutación por error en caso de falla del origen.