Firma produkująca gry mobilne udostępnia zasoby gier z instancji EC2 za ALB w dwóch regionach. Klienci muszą pobierać zasoby z najbliższego geograficznie regionu; jeśli zasoby są niedostępne w najbliższym regionie, klienci powinni przełączyć się na drugi region. Jak architekt rozwiązań powinien zaimplementować to zachowanie?

Poprawna odpowiedź to utworzenie Route 53 health check dla każdego ALB, a następnie utworzenie Route 53 latency alias record, który wskazuje na dwa ALB, włączając Evaluate Target Health. Rekord opóźnienia (latency record) Route 53 kieruje ruch do regionu, który zapewnia najniższe opóźnienie dla użytkownika, spełniając wymóg geograficznej bliskości. Włączenie Evaluate Target Health w połączeniu z kontrolami stanu (health checks) ALB zapewnia automatyczne przełączanie ruchu do drugiego regionu, jeśli zasoby w bliższym regionie staną się niedostępne, zapewniając wysoką dostępność. Pozostałe opcje są mniej odpowiednie: CloudFront z grupą pochodzenia: CloudFront jest CDN i może poprawić wydajność, ale grupa pochodzenia nie zapewnia automatycznego przełączania awaryjnego między regionami na podstawie opóźnienia w taki sposób, jak Route 53 latency routing. Route 53 failover routing record: Rekord failover jest przeznaczony do aktywnego/pasywnego przełączania awaryjnego, a nie do kierowania ruchem na podstawie opóźnienia. Dwie dystrybucje CloudFront z Route 53 failover: To rozwiązanie jest zbyt złożone i nie wykorzystuje w pełni możliwości Route 53 w zakresie routingu opartego na opóźnieniu.