Une application utilise une distribution Amazon CloudFront avec un Application Load Balancer (ALB) public dans une Région comme origine par défaut. L'application est déployée dans une Région secondaire dans une configuration de veille active (warm-standby) et l'entreprise exige un RTO de zéro seconde pour les requêtes HTTP GET. Comment automatiser le basculement vers la Région secondaire afin que les requêtes HTTP GET respectent ce RTO ?

La bonne réponse est d'ajouter une nouvelle origine pour l'ALB secondaire et de créer un groupe d'origines. CloudFront Origin Group permet de configurer un basculement automatique entre les origines. En définissant l'ALB principal comme origine primaire et l'ALB secondaire comme origine secondaire, et en configurant le basculement en cas de réponses HTTP 5xx, CloudFront basculera automatiquement vers la région secondaire sans interruption visible pour l'utilisateur, répondant ainsi à l'exigence de RTO de zéro seconde pour les requêtes GET. Les autres options sont incorrectes car : Créer une deuxième distribution CloudFront et utiliser Route 53 pour le basculement introduirait une latence de propagation DNS, ce qui ne permettrait pas un RTO de zéro seconde. Utiliser Route 53 directement avec les ALB et un TTL de 0 ne garantit pas un basculement instantané pour les requêtes déjà en transit et peut entraîner des problèmes de mise en cache DNS. Une fonction CloudFront pour une redirection 307 introduirait une latence supplémentaire et ne serait pas un basculement transparent pour l'utilisateur, car le client devrait effectuer une nouvelle requête.