Una empresa de juegos para móviles sirve los recursos del juego desde instancias EC2 detrás de un ALB en dos Regiones. Los clientes deben obtener los recursos de la Región geográficamente más cercana; si los recursos no están disponibles en la Región más cercana, los clientes deben conmutar por error a la otra Región. ¿Cómo debe implementar este comportamiento un arquitecto de soluciones?

La opción correcta es crear una comprobación de estado de Route 53 para cada ALB y luego un registro de alias de latencia de Route 53 que apunte a los dos ALB, habilitando Evaluate Target Health. El enrutamiento de latencia dirige a los usuarios a la región con la latencia más baja, lo que satisface el requisito de "geográficamente más cercana". La combinación con comprobaciones de estado y Evaluate Target Health asegura que, si la región más cercana no está disponible, Route 53 redirigirá automáticamente el tráfico a la otra región saludable, logrando la conmutación por error. Las otras opciones son incorrectas: CloudFront no es la solución principal para el enrutamiento basado en latencia y conmutación por error entre regiones de ALB. Aunque se puede usar para caché, el requisito principal es el enrutamiento de tráfico. Un registro de enrutamiento de conmutación por error de Route 53 por sí solo no garantiza el enrutamiento a la región más cercana inicialmente; solo maneja la conmutación por error. Crear dos distribuciones de CloudFront y un registro de conmutación por error de Route 53 es una configuración más compleja y no aborda directamente el requisito de latencia inicial de la misma manera que el enrutamiento de latencia de Route 53.