Podstawowy region AWS hostuje aplikację internetową, a region pomocniczy jest w trybie gotowości na wypadek awarii. Wymagania: dane sesji muszą być replikowane między regionami niemal w czasie rzeczywistym; 1% ruchu powinno być stale kierowane do regionu pomocniczego; automatyczne przełączanie awaryjne do regionu pomocniczego w przypadku zakłócenia w regionie podstawowym; region pomocniczy musi skalować się, aby obsłużyć pełny ruch. Jak należy spełnić te wymagania?

Poprawna odpowiedź spełnia wszystkie wymagania. AWS Elastic Beanstalk upraszcza wdrażanie aplikacji w obu regionach. Tabele globalne Amazon DynamoDB zapewniają niemal natychmiastową replikację danych sesji między regionami. Polityka routingu ważonego Amazon Route 53 z kontrolami stanu kieruje 1% ruchu do regionu pomocniczego (testowanie kanarkowe) i automatycznie przełącza ruch w przypadku awarii regionu podstawowego. Region pomocniczy, hostujący pełną aplikację, może skalować się, aby obsłużyć cały ruch. Pozostałe opcje są nieprawidłowe, ponieważ: Użycie polityki routingu failover Route 53 nie pozwala na ciągłe kierowanie 1% ruchu do regionu pomocniczego. Użycie AWS Lambda i Amazon RDS z replikacją międzyregionową jest bardziej złożone i nieoptymalne dla danych sesji, a także wymagałoby dodatkowej logiki po stronie klienta, co nie jest idealne. Włączanie ważonej dystrybucji Amazon CloudFront nie jest mechanizmem routingu między regionami dla aplikacji webowych w kontekście failoveru i testowania kanarkowego, a raczej dla dostarczania treści.