Un'azienda di giochi mobile distribuisce asset di gioco da istanze EC2 dietro un ALB in due Regioni. I client devono recuperare gli asset dalla Regione geograficamente più vicina; se gli asset non sono disponibili nella Regione più vicina, i client dovrebbero effettuare il failover all'altra Regione. Come dovrebbe implementare questo comportamento un architetto di soluzioni?

La risposta corretta è creare un health check di Route 53 per ogni ALB e quindi creare un record alias di latenza di Route 53 che punti ai due ALB, abilitando Evaluate Target Health. Questo approccio soddisfa entrambi i requisiti: la latenza dirige i client alla regione geograficamente più vicina, e gli health check combinati con Evaluate Target Health garantiscono il failover automatico all'altra regione se quella più vicina non è disponibile. Le altre opzioni sono meno efficaci: CloudFront con un gruppo di origini primario/secondario non gestisce il routing basato sulla latenza geografica per l'accesso iniziale. Un record di routing di failover di Route 53 da solo non considera la latenza per la scelta iniziale della regione. Due distribuzioni CloudFront con failover di Route 53 aggiunge complessità e non è la soluzione più diretta per il routing basato sulla latenza tra regioni.