Une application web génère du contenu dynamique sur des instances Amazon EC2 au sein d'un groupe Auto Scaling derrière un Application Load Balancer (ALB). L'entreprise utilise CloudFront avec l'ALB configuré comme origine, et Route 53 possède un enregistrement A pour www.example.com pointant vers la distribution CloudFront. L'architecte de solutions doit rendre l'application hautement disponible et tolérante aux pannes dans plusieurs Régions. Quelle solution répond à cette exigence ?

La bonne réponse est de provisionner un ALB, un groupe Auto Scaling et des instances EC2 dans une autre Région AWS, puis de mettre à jour la distribution CloudFront pour ajouter une deuxième origine pour le nouvel ALB. Ensuite, créer un groupe d'origines comprenant les deux origines et configurer une origine comme primaire et l'autre comme secondaire. Cette approche utilise la fonctionnalité de basculement d'origine de CloudFront, qui permet de basculer automatiquement vers une origine secondaire en cas de défaillance de l'origine primaire, assurant ainsi une haute disponibilité et une tolérance aux pannes inter-régions. L'option de l'enregistrement de basculement Route 53 avec deux distributions CloudFront est moins efficace car elle nécessiterait des vérifications de santé sur les distributions CloudFront elles-mêmes, ce qui n'est pas la méthode standard pour le basculement d'application. L'ajout d'instances EC2 d'une autre région à un ALB existant n'est pas possible car les ALB sont régionaux. L'utilisation de Global Accelerator avec deux distributions CloudFront est une option viable mais plus complexe et potentiellement plus coûteuse que le basculement d'origine natif de CloudFront pour ce cas d'utilisation.