Aplikacja korzysta z dystrybucji Amazon CloudFront z publicznym Application Load Balancerem (ALB) w regionie jako domyślnym źródłem. Aplikacja jest wdrożona w regionie pomocniczym w konfiguracji warm-standby, a firma wymaga zerowego RTO dla żądań HTTP GET. Jak zautomatyzować przełączanie awaryjne do regionu pomocniczego, aby żądania HTTP GET spełniały to RTO?

Poprawna odpowiedź automatyzuje przełączanie awaryjne w ramach istniejącej dystrybucji CloudFront, co jest kluczowe dla zerowego RTO (Recovery Time Objective) dla żądań HTTP GET. Dodanie pomocniczego ALB jako nowego źródła i utworzenie grupy źródeł z podstawowym ALB jako głównym oraz pomocniczym jako zapasowym, pozwala CloudFront na automatyczne przełączenie ruchu w przypadku błędów 5xx z podstawowego źródła. Aktualizacja domyślnego zachowania dystrybucji, aby używało tej grupy źródeł, zapewnia, że CloudFront samodzielnie zarządza przełączaniem awaryjnym, bez konieczności zmian po stronie klienta czy modyfikacji DNS. Pierwsza opcja jest nieprawidłowa, ponieważ tworzenie drugiej dystrybucji CloudFront i zarządzanie przełączaniem awaryjnym za pomocą Route 53 wprowadza opóźnienia związane z propagacją DNS, co narusza wymóg zerowego RTO. Trzecia opcja również opiera się na Route 53 i jego propagacji DNS, a ustawienie TTL na 0 nie gwarantuje natychmiastowego przełączenia awaryjnego we wszystkich scenariuszach, a także może zwiększyć obciążenie serwerów DNS. Czwarta opcja, użycie funkcji CloudFront do przekierowania 307, wprowadza dodatkowe opóźnienia i nie jest idealnym rozwiązaniem dla automatycznego przełączania awaryjnego z zerowym RTO, ponieważ wymagałoby to dwukrotnego połączenia klienta.