Architekt rozwiązań wdrożył aplikację internetową dostępną z dwóch regionów AWS pod niestandardową domeną, używając routingu opartego na opóźnieniach (latency-based routing) Amazon Route 53. Dla każdego regionu architekt utworzył ważone zestawy rekordów (weighted record sets), które wskazują na parę serwerów internetowych w różnych strefach dostępności. Podczas testu odzyskiwania po awarii wszystkie serwery internetowe w jednym regionie zostały zatrzymane, ale Route 53 nie przekierował automatycznie ruchu do drugiego regionu. Co z poniższych może wyjaśniać takie zachowanie? (Wybierz dwie odpowiedzi.)

Problem polega na tym, że Route 53 nie przekierował ruchu, mimo awarii serwerów. Dwie opcje wyjaśniają to zachowanie. Po pierwsze, jeśli ważone zestawy rekordów dla zatrzymanych serwerów internetowych nie mają skonfigurowanej kontroli stanu HTTP, Route 53 nie wie, że serwery są niedostępne. Kontrole stanu są kluczowe do automatycznego przełączania ruchu. Po drugie, jeśli zestaw rekordów aliasu opóźnienia dla regionu, w którym serwery zostały zatrzymane, nie ma włączonej opcji "Evaluate Target Health", Route 53 nie będzie brał pod uwagę stanu docelowego zasobu (np. Load Balancera) podczas routingu. Bez tej opcji, nawet jeśli kontrola stanu na poziomie ważonego rekordu działa, rekord aliasu może nadal kierować ruch do niedostępnego regionu. Pozostałe opcje są nieprawidłowe: Waga rekordu nie ma znaczenia, jeśli Route 53 nie wie o awarii. Awaria jednego serwera nie wyjaśnia braku przekierowania całego ruchu z regionu. Łączenie routingu opartego na opóźnieniach z ważonymi zestawami rekordów jest standardową praktyką.