솔루션스 아키텍트는 Amazon Route 53 지연 시간 기반 라우팅을 사용하여 사용자 지정 도메인으로 두 AWS 리전에서 액세스할 수 있는 웹 앱을 배포했습니다. 각 리전에 대해 아키텍트는 서로 다른 가용 영역에 있는 한 쌍의 웹 서버를 가리키는 가중치 레코드 세트를 생성했습니다. 재해 복구 테스트 중에 한 리전의 모든 웹 서버가 중지되었지만 Route 53은 다른 리전으로 트래픽을 자동으로 라우팅하지 않았습니다. 다음 중 이 동작을 설명할 수 있는 것은 무엇입니까? (두 가지 선택)

정답은 "서버가 중지된 리전의 도메인에 대한 지연 시간 별칭 레코드 세트에 Evaluate Target Health 옵션이 활성화되어 있지 않습니다"와 "중지된 웹 서버에 해당하는 가중치 레코드 세트 중 하나 이상에 연결된 HTTP 상태 확인이 구성되어 있지 않습니다"입니다. Route 53은 기본적으로 레코드 세트의 상태를 확인하지 않습니다. 지연 시간 기반 라우팅에서 한 리전의 모든 웹 서버가 중지되었음에도 트래픽이 다른 리전으로 전환되지 않은 것은, 해당 리전의 지연 시간 별칭 레코드 세트에 '대상 상태 평가(Evaluate Target Health)' 옵션이 활성화되지 않았거나, 개별 가중치 레코드 세트에 연결된 HTTP 상태 확인이 구성되지 않았기 때문입니다. 이 옵션이 활성화되면 Route 53은 별칭 대상의 상태를 확인하고, 대상이 비정상이면 다른 정상적인 리소스로 트래픽을 라우팅합니다. 상태 확인이 없으면 Route 53은 웹 서버가 중지되었는지 알 수 없습니다. 다른 오답들은 다음과 같습니다. "중지된 웹 서버가 있는 리전의 레코드 세트에 할당된 가중치가 다른 리전의 가중치보다 큽니다."는 가중치 라우팅 정책에서 트래픽 분배에 영향을 미치지만, 모든 서버가 중지된 상황에서 상태 확인이 없다면 트래픽이 계속 해당 리전으로 전송됩니다. "대체 리전의 웹 서버 중 하나가 HTTP 상태 확인에 실패했습니다."는 다른 리전으로의 페일오버를 방해할 수 있지만, 문제의 핵심은 원래 리전의 실패 감지 부족입니다. "지연 시간 기반 리소스 레코드 세트는 가중치 기반 리소스 레코드 세트와 결합할 수 없습니다."는 사실이 아닙니다. 두 라우팅 정책은 함께 사용될 수 있습니다.