Een mobiel gamebedrijf levert game assets vanuit EC2-instances achter een ALB in twee Regio's. Clients moeten assets ophalen uit de geografisch dichtstbijzijnde Regio; als assets niet beschikbaar zijn in de dichtstbijzijnde Regio, moeten clients failover uitvoeren naar de andere Regio. Hoe moet een solutions architect dit gedrag implementeren?

De correcte oplossing is het aanmaken van een Route 53 health check voor elke ALB en vervolgens een Route 53 latency alias record dat verwijst naar de twee ALB's, waarbij Evaluate Target Health wordt ingeschakeld. Dit zorgt ervoor dat gebruikers automatisch worden gerouteerd naar de geografisch dichtstbijzijnde gezonde ALB, wat voldoet aan de eis voor lage latency en failover. Als de dichtstbijzijnde Regio niet beschikbaar is (door de health check), zal Route 53 automatisch failover uitvoeren naar de andere gezonde Regio. Het gebruik van CloudFront met een origin group (optie 1) biedt wel caching en globale distributie, maar de failover-logica voor geografische nabijheid en failover tussen regio's wordt niet primair door de origin group afgehandeld op de manier die hier wordt gevraagd. Twee CloudFront-distributies met Route 53 failover (optie 3) is complexer dan nodig en voegt geen extra waarde toe voor de specifieke vereisten van geografische nabijheid en failover op basis van latency. Een Route 53 failover routing record (optie 2) zou failover afhandelen, maar niet de initiële routing op basis van latency naar de dichtstbijzijnde regio, wat een kernvereiste is.