Une entreprise de jeux mobiles distribue des ressources de jeu à partir d'instances EC2 derrière un ALB dans deux régions. Les clients doivent récupérer les ressources de la région géographiquement la plus proche ; si les ressources ne sont pas disponibles dans la région la plus proche, les clients doivent basculer vers l'autre région. Comment un architecte de solutions doit-il implémenter ce comportement ?

La bonne réponse est de créer une vérification de l'état de santé Route 53 pour chaque ALB, puis de créer un enregistrement d'alias de latence Route 53 qui pointe vers les deux ALB, en activant Evaluate Target Health. Le routage de latence Route 53 dirige les utilisateurs vers la région offrant la latence la plus faible, ce qui correspond au besoin de récupérer les ressources de la région géographiquement la plus proche. L'activation d'Evaluate Target Health garantit que si la région la plus proche devient indisponible, Route 53 basculera automatiquement vers l'autre région saine. Les autres options sont incorrectes car : L'utilisation de CloudFront avec un groupe d'origines primaire/secondaire ne gère pas la latence géographique de manière optimale pour la sélection initiale de la région. Un enregistrement de routage de basculement Route 53 seul ne priorise pas la région la plus proche en fonction de la latence, mais bascule uniquement en cas de défaillance. Deux distributions CloudFront avec un routage de basculement Route 53 ne fournissent pas non plus la sélection initiale basée sur la latence requise.