기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# DNS 장애 조치 구성
동일한 기능을 수행하는 2개 이상의 리소스(예: 1개 이상의 HTTP 서버 또는 메일 서버)가 있는 경우, Amazon Route 53를 구성하여 리소스들의 상태를 확인하고 정상적인 리소스만을 사용하여 DNS 쿼리에 응답하도록 할 수 있습니다. 예를 들어, 전 세계에 3개의 데이터 센터에서 각각 2개의 서버, 즉 6개의 서버 상에서 example.com라는 웹 사이트가 호스팅된다고 가정합니다. 이러한 서버들의 상태를 확인하고 현재 정상적인 서버만을 사용하여 example.com에 대한 DNS 쿼리에 응답하도록 Route 53를 구성할 수 있습니다.
Route 53는 단순 구성 및 복잡 구성 모두에서 리소스의 상태를 확인할 수 있습니다.
+ 단순 구성에서 이름과 유형이 모두 동일한 레코드의 그룹(예: 유형이 A인 example.com에 대한 가중치 기반 레코드의 그룹)을 생성합니다. 그런 다음 Route 53를 구성해 해당 리소스의 상태를 확인합니다. Route 53는 리소스의 상태를 기반으로 DNS 쿼리에 응답합니다. 자세한 내용은 [단순 Amazon Route 53 구성에서 상태 확인 작동 방식단순 구성에서 상태 확인 작동 방식](dns-failover-simple-configs.md) 섹션을 참조하세요.
+ 더욱 복잡한 구성에서는 여러 기준을 기반으로 트래픽을 라우팅하는 레코드 트리를 생성합니다. 예를 들어, 사용자에 대한 지연 시간이 가장 중요한 기준인 경우 지연 시간 별칭 레코드를 사용하여 최적의 지연 시간을 제공하는 리전으로 트래픽을 라우팅할 수 있습니다. 지연 시간 별칭 레코드에서 각 리전의 가중치 기반 레코드를 별칭 대상으로 보유할 수 있습니다. 가중치 기반 레코드는 인스턴스 유형을 기반으로 트래픽을 EC2 인스턴스로 라우팅할 수 있습니다. 단순 구성에서와 마찬가지로 Route 53가 리소스 상태를 기반으로 트래픽을 라우팅하도록 구성할 수 있습니다. 자세한 내용은 [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식상태 확인이 복잡한 구성에서 작동하는 방식](dns-failover-complex-configs.md) 섹션을 참조하세요.
**Topics**
+ [DNS 장애 조치 구성을 위한 작업 목록](dns-failover-how-to.md)
+ [단순 Amazon Route 53 구성에서 상태 확인 작동 방식](dns-failover-simple-configs.md)
+ [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식](dns-failover-complex-configs.md)
+ [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md)
+ [액티브-액티브 및 액티브-패시브 장애 조치](dns-failover-types.md)
+ [프라이빗 호스팅 영역에서 장애 조치 구성](dns-failover-private-hosted-zones.md)
+ [Amazon Route 53가 장애 조치 문제를 방지하는 방법](dns-failover-problems.md)
# DNS 장애 조치 구성을 위한 작업 목록
Route 53를 사용하여 DNS 장애 조치를 구성하려면 다음 작업을 수행하세요.
1. 구성에 대한 완전한 트리 다이어그램을 그리고 각 노드마다 어떤 유형의 레코드(가중치 기반 별칭, 장애 조치, 지연 시간 등)를 생성하는지 나타냅니다. 트리 상단에 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 도메인 이름(예: example.com)에 대한 레코드를 놓습니다.
트리 다이어그램에 표시되는 레코드의 종류는 구성의 복잡성에 따라 다릅니다.
+ 단순 구성에서 다이어그램에 어떠한 별칭 레코드도 포함하지 않거나 별칭 레코드가 다른 Route 53 레코드 대신 ELB 로드 밸런서와 같은 리소스에 직접 트래픽을 라우팅합니다. 자세한 내용은 [단순 Amazon Route 53 구성에서 상태 확인 작동 방식단순 구성에서 상태 확인 작동 방식](dns-failover-simple-configs.md) 섹션을 참조하세요.
+ 복잡한 구성에서는 [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식상태 확인이 복잡한 구성에서 작동하는 방식](dns-failover-complex-configs.md) 주제의 예제처럼 다중 트리에서 별칭 레코드(가중치 기반 별칭, 장애 조치 별칭 등)와 비 별칭 레코드의 조합이 다이어그램에 포함됩니다.
**참고**
복잡한 라우팅 구성에 대한 레코드를 빠르고 쉽게 생성한 후 상태 확인에 연결하려면 트래픽 흐름 시각적 편집기를 사용하고 구성을 트래픽 정책으로 저장할 수 있습니다. 그런 다음 동일한 호스팅 영역이나 여러 호스팅 영역의 하나 이상의 도메인 이름(예: example.com) 또는 하위 도메인 이름(예: www.example.com)과 해당 트래픽 정책을 연결할 수 있습니다. 새 구성이 예상대로 수행되지 않을 경우 업데이트를 롤백할 수도 있습니다. 자세한 내용은 [트래픽 흐름을 사용하여 DNS 트래픽 라우팅](traffic-flow.md) 섹션을 참조하세요.
자세한 내용은 다음 설명서를 참조하세요.
+ [라우팅 정책 선택](routing-policy.md)
+ [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md)
1. 데이터 센터에서 실행 중인 Amazon EC2 서버 및 이메일 서버와 같은 별칭 레코드를 생성할 수 없는 리소스의 상태 확인을 생성합니다. 이러한 상태 확인을 비 별칭 레코드와 연결합니다.
자세한 내용은 [상태 확인의 생성, 업데이트 및 삭제](health-checks-creating-deleting.md) 섹션을 참조하세요.
1. 필요한 경우 상태 확인에서 지정한 엔드포인트에 대해 Route 53가 규칙적으로 요청을 전송할 수 있도록 하기 위해서는 라우터 및 방화벽 규칙을 구성합니다. 자세한 내용은 [Amazon Route 53 상태 확인을 위한 라우터 및 방화벽 규칙 구성상태 확인을 위한 라우터 및 방화벽 규칙 구성](dns-failover-router-firewall-rules.md) 섹션을 참조하세요.
1. 다이어그램에서 비 별칭 레코드 전체를 생성하고 2단계에서 생성한 상태 확인을 해당 레코드와 연결합니다.
별칭 레코드가 없는 단순 구성에서 DNS 장애 조치를 구성하는 경우 남은 작업을 건너뜁니다.
1. ELB 로드 밸런서 및 CloudFront 배포와 같은 AWS 리소스로 트래픽을 라우팅하는 별칭 레코드를 생성합니다. 리소스가 비정상일 때 Route 53가 트리의 다른 가지를 시도하도록 하려면 별칭 레코드 각각에 대해 **대상 상태 평가(Evaluate Target Health)** 값을 **예(Yes)**로 설정합니다. (일부 AWS 리소스에서는 **대상 상태 평가가** 지원되지 않습니다.)
1. 1단계에서 생성한 트리 다이어그램의 하단에서 4단계와 5단계에서 생성한 레코드로 트래픽을 라우팅하는 별칭 레코드를 생성합니다. 비 별칭 레코드 전체가 트리의 가지에서 비정상인 경우 Route 53가 트리의 다른 가지를 시도하도록 하려면 별칭 레코드 각각에 대해 **대상 상태 평가(Evaluate Target Health)**의 값을 **예(Yes)**로 설정합니다.
다른 레코드를 생성하기 전까지 다른 레코드로 트래픽을 라우팅하는 별칭 레코드를 생성할 수 없다는 것에 유의하십시오.
# 단순 Amazon Route 53 구성에서 상태 확인 작동 방식
동일한 기능을 수행하는 둘 이상의 리소스(예: example.com에 대한 둘 이상의 웹 서버)가 있으면 다음 상태 확인 기능을 사용하여 트래픽을 정상적인 리소스에만 라우팅할 수 있습니다.
**EC2 인스턴스 및 기타 리소스(비 별칭 레코드)의 상태 확인**
EC2 인스턴스와 같이 별칭 레코드를 생성할 수 없는 리소스로 트래픽을 라우팅하는 경우 각 리소스에 대해 레코드 및 상태 확인을 생성합니다. 그런 다음 각 상태 확인을 해당 레코드와 연결합니다. 상태 확인은 해당 리소스의 상태를 주기적으로 확인하고, Route 53는 상태 확인 보고에 따라 정상인 리소스에만 트래픽을 라우팅합니다.
** AWS 리소스의 상태 평가(별칭 레코드)**
[별칭 레코드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)를 사용하여 ELB 로드 밸런서와 같은 선택한 AWS 리소스로 트래픽을 라우팅하는 경우 리소스의 상태를 평가하고 정상인 리소스로만 트래픽을 라우팅하도록 Route 53을 구성할 수 있습니다. 별칭 레코드를 구성하여 리소스의 상태를 확인하는 경우 리소스에 대한 상태 확인을 생성할 필요가 없습니다.
단순 구성에서 Route 53가 리소스의 상태를 확인하도록 구성하는 방법에 대한 개요입니다.
1. Route 53가 모니터링할 리소스를 식별합니다. 예컨대 example.com 대한 요청에 응답하는 HTTP 서버 전체를 모니터링하기 원할 수도 있습니다.
1. 고유 데이터 센터의 EC2 인스턴스 또는 서버와 같은 레코드의 별칭을 생성할 수 없는 리소스의 상태 확인을 생성합니다. 리소스에 상태 확인 요청을 전송하는 방법을 지정합니다. 즉, 사용할 프로토콜(HTTP, HTTPS, 또는 TCP), 사용할 IP 주소 및 포트, 그리고 HTTP/HTTPS 상태 확인을 위한 도메인 이름 및 경로를 알려줍니다.
**참고**
ELB 로드 밸런서와 같이 별칭 레코드를 생성할 수 있는 리소스를 사용하는 경우 이러한 리소스에 대한 상태 확인을 생성하지 않습니다.
기본 구성은 각 리소스마다 하나의 상태 확인을 생성하고 리소스마다 상태 확인 엔드포인트를 위한 동일한 IP 주소를 사용하는 것입니다. 상태 확인은 지정된 IP 주소로 요청을 전송합니다.
**참고**
Route 53는 IP 주소가 로컬, 프라이빗, 라우팅 불가, 또는 멀티캐스트 범위에 있는 리소스의 상태는 확인할 수 없습니다. 상태 확인을 생성할 수 없는 IP 주소에 대한 자세한 내용은 [RFC 5735, Special Use IPv4 Addresses](https://datatracker.ietf.org/doc/html/rfc5735)와 [RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](https://datatracker.ietf.org/doc/html/rfc6598)를 참조하십시오.
상태 확인 생성에 대한 자세한 내용은 [상태 확인의 생성, 업데이트 및 삭제](health-checks-creating-deleting.md) 단원을 참조하십시오.
1. 상태 확인에서 지정한 엔드포인트에 대해 Route 53가 규칙적으로 요청을 전송할 수 있도록 하기 위해서는 라우터 및 방화벽 규칙을 구성할 필요가 있을 수 있습니다. 자세한 내용은 [Amazon Route 53 상태 확인을 위한 라우터 및 방화벽 규칙 구성상태 확인을 위한 라우터 및 방화벽 규칙 구성](dns-failover-router-firewall-rules.md) 섹션을 참조하세요.
1. 리소스(예: 가중치 기반 레코드 그룹)에 대한 레코드 그룹을 생성합니다. 별칭 및 비 별칭 레코드를 조합할 수 있습니다. 하지만 모두 동일한 [**Name**], [**Type**] 및 [**Routing Policy**] 값을 보유해야 합니다.
Route 53가 리소스의 상태를 확인하도록 구성하는 방법은 별칭 레코드 또는 비 별칭 레코드 생성 여부에 따라 다릅니다.
+ **별칭 레코드(Alias records)** - **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 지정합니다.
+ **비 별칭 레코드(Non-alias records)** - 2단계에서 생성한 상태 확인을 해당 레코드와 연결합니다.
완료되면 구성은 다음 다이어그램과 비슷해지며, 비 별칭 레코드만을 포함합니다.
![\[3개의 가중치 기반 레코드 및 해당 상태 확인.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-weighted.png)
Route 53 콘솔을 사용하여 레코드를 생성하는 방법에 대한 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 섹션을 참조하세요.
1. 상태 확인을 생성한 경우 Route 53는 각 상태 확인 시 엔드포인트로 요청을 주기적으로 전송하지만, DNS 쿼리를 수신할 때는 상태 확인을 수행하지 않습니다. Route 53는 응답을 근거로 엔드포인트가 정상인지 판단하고 그 정보를 이용하여 어떻게 쿼리에 응답할 것인지 결정합니다. 자세한 내용은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
Route 53는 example.com의 A 레코드에서 지정된 IP 주소와 같이 레코드에 지정된 리소스의 상태를 확인하지 않습니다. 상태 확인을 레코드와 연결하면 Route 53는 상태 확인에서 지정한 엔드포인트의 상태를 확인하기 시작합니다. 또한 Route 53가 다른 상태 확인의 상태 또는 CloudWatch 경보의 데이터 스트림을 모니터링하도록 구성할 수도 있습니다. 자세한 내용은 [Amazon Route 53 상태 확인 유형상태 확인의 유형](health-checks-types.md) 섹션을 참조하세요.
Route 53가 example.com에 대한 쿼리를 수신할 때 다음 현상이 발생합니다.
1. Route 53는 라우팅 정책을 기반으로 레코드를 선택합니다. 이 경우에는 가중치를 기반으로 레코드를 선택합니다.
1. 선택한 레코드에 대한 상태 확인의 상태를 확인하여 해당 레코드의 현재 상태를 판단합니다.
1. 선택한 레코드가 비정상인 경우 Route 53는 다른 레코드를 선택합니다. 이 경우 비정상적인 레코드는 고려 대상이 아닙니다.
자세한 내용은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 섹션을 참조하세요.
1. Route 53가 정상인 레코드를 찾으면 A 레코드의 IP 주소와 같이 해당되는 값으로 쿼리에 응답합니다.
다음 예제에서는 세 번째 레코드가 비정상적인 가중치 기반 레코드의 그룹을 보여 줍니다. 처음에 Route 53는 3개의 레코드 전체의 가중치를 기반으로 레코드를 선택합니다. 처음에 비정상적인 레코드를 선택하는 일이 발생하면 Route 53는 다른 레코드를 선택하지만 이번에는 세 번째 레코드의 가중치를 계산에서 제외합니다.
+ Route 53가 처음에 3개의 레코드 전체 중에서 선택할 때는 10/(10 \$1 20 \$1 20)이라는 시간의 약 20% 동안만 최초 레코드를 사용하여 요청에 응답합니다.
+ 이 세 번째 레코드가 비정상이라고 판단할 때는 10/(10 \$1 20)이라는 시간의 약 33% 동안만 최초 레코드를 사용하여 요청에 응답합니다.
![\[3개의 가중치 기반 레코드 및 해당 상태 확인. 세 번째 상태 확인이 비정상이기 때문에 Route 53은 연결된 레코드가 비정상이라 간주합니다.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-weighted-failed-hc.png)
레코드 그룹에서 1개 이상의 레코드에 대한 상태 확인을 생략한 경우 Route 53가 해당 리소스의 상태를 확인할 방법이 없습니다. Route 53에서는 해당 레코드를 정상으로 취급합니다
![\[3개의 가중치 기반 레코드, 그 중 둘만이 상태 확인 보유. Route 53은 항상 세 번째 레코드를 정상으로 간주합니다.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-weighted-missing-health-check.png)
# 상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식
복잡한 구성에서 리소스의 상태를 확인하는 것은 단순한 구성에 이루어지는 방식과 상당 부분 같습니다. 그러나 복잡한 구성에서는 별칭 레코드(가중치 기반 별칭, 장애 조치 별칭 등)와 비 별칭 레코드의 조합을 사용하여 Route 53가 요청에 응답하는 방식을 더 잘 제어할 수 있게 해주는 판단 트리를 구축합니다.
예를 들어 지연 시간 별칭 레코드를 사용하여 사용자에게 가까운 리전을 선택하고 각 리전 내의 둘 이상의 리소스에 대한 가중치 기반 레코드를 사용하여 단일 엔드포인트 또는 가용 영역의 실패를 방지할 수 있습니다. 다음 다이어그램은 이 구성을 보여줍니다.
![\[지연 시간 별칭 레코드와 가중치 기반 별칭 레코드를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted.png)
Amazon EC2 및 Route 53가 구성되는 방법은 다음과 같습니다. 트리의 하단에서 시작합니다. 레코드를 생성하는 순서이기 때문입니다.
+ us-east-1 및 ap-southeast-2의 두 리전 각각에서 2개의 EC2 인스턴스를 갖습니다. Route 53가 정상 여부를 기반으로 EC2 인스턴스로 트래픽을 라우팅하고자 하는 경우 각 인스턴스에 대해 상태 확인을 생성합니다. 각 상태 확인을 구성하여 상태 확인 요청을 해당 인스턴스의 탄력적 IP 주소에 있는 해당 인스턴스로 전송합니다.
Route 53는 전역 서비스이므로 상태 확인을 생성하고자 하는 리전을 지정하지 않습니다.
+ 인스턴스 유형을 기반으로 각 리전에 있는 2개의 인스턴스로 트래픽을 라우팅하고자 하는 경우 각 인스턴스에 대한 가중치 기반 레코드를 생성하고 각 레코드에 가중치를 부여합니다. (이후 가중치를 변경하여 인스턴스로의 트래픽 라우팅을 늘리거나 줄일 수 있습니다.) 또한 해당 상태 확인을 각 인스턴스와 연결합니다.
레코드를 생성할 때 us-east-1-www.example.com 및 ap-southeast-2-www.example.com과 같은 이름을 사용합니다. 레코드에 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 이름(예: example.com)을 지정하려면 트리 상단으로 이동할 때까지 기다립니다.
+ 사용자에 대해 가장 낮은 지연 시간을 제공하는 리전으로 트래픽을 라우팅하고자 하는 경우 트리 상단에서 레코드에 대한 지연 시간 [라우팅 정책](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)을 선택합니다.
직접 각 리전의 *리소스*가 아니라 각 리전의 *레코드*로 트래픽을 라우팅하고자 합니다(이미 가중치 기반 레코드가 이를 수행하고 있음). 그 결과 지연 시간 [별칭 레코드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)를 생성합니다.
별칭 레코드를 생성할 때 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 이름(예: example.com)을 지정합니다. 별칭 레코드는 example.com에 대한 트래픽을 us-east-1-www.example.com 및 ap-southeast-2-www.example.com 레코드로 라우팅합니다.
지연 시간 별칭 레코드 모두에 대해 [**Evaluate Target Health**]의 값을 [**Yes**]로 설정합니다. 이렇게 하면 Route 53는 트래픽 라우팅을 시도하기 전에 리전에 정상 리소스가 있는지 여부를 확인합니다. 정상 리소스가 없는 경우 Route 53는 다른 리전의 정상 리소스를 선택합니다.
![\[지연 시간 별칭 레코드와 가중치 기반 별칭 레코드를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-both-failed.png)
앞의 다이어그램에서는 이벤트들의 순서를 다음과 같이 보여줍니다.
1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다.
1. Route 53는 가중치를 기반으로 가중치 기반 레코드를 선택합니다. **대상 상태 평가(Evaluate Target Health)**는 지연 시간 별칭 레코드에 대해 **예(Yes)**이므로 Route 53는 선택한 가중치 기반 레코드의 상태를 확인합니다.
1. 상태 확인이 실패했으므로 Route 53는 가중치를 기반으로 다른 가중치 기반 레코드를 선택하여 그 상태를 확인합니다. 해당 레코드 역시 비정상입니다.
1. Route 53는 트리의 가지를 포기하고 차선의 지연 시간을 지닌 지연 시간 별칭 레코드를 찾아 ap-southeast-2에 대한 레코드를 선택합니다.
1. Route 53는 다시 가중치를 기반으로 레코드를 선택한 다음 선택한 리소스의 상태를 확인합니다. 리소스가 정상이므로 Route 53는 쿼리에 응답해 해당하는 값을 반환합니다.
**Topics**
+ [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](#dns-failover-complex-configs-hc-alias)
+ [상태 확인을 생략하면 어떻게 됩니까?](#dns-failover-complex-configs-hc-omitting)
+ [[Evaluate Target Health]를 [No]로 설정하면 어떻게 됩니까?](#dns-failover-complex-configs-eth-no)
## 상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?
[**Evaluate Target Health**]의 값을 [**Yes**]로 설정하는 작업 대신 또는 이 작업 외에 상태 확인을 별칭 레코드와 연결할 수 있습니다. 그러나 Route 53가 기본 리소스(별칭 레코드가 참조하는 HTTP 서버, 데이터베이스 서버, 및 기타 리소스)의 상태에 따라 쿼리에 반응한다면 대개의 경우 더 유용합니다. 예를 들어, 다음과 같은 구성을 가정해 봅시다.
+ 별칭 대상이 가중치 기반 레코드의 그룹인 지연 시간 별칭 레코드에 상태 확인을 할당합니다.
+ 지연 시간 별칭 레코드에 대해 [**Evaluate Target Health**]의 값을 [**Yes**]로 설정합니다.
이 구성에서는 Route 53가 가중치 기반 레코드에 해당하는 값을 반환하기 전에 다음 두 가지가 모두 참이어야 합니다.
+ 지연 시간 별칭 레코드와 연결된 상태 확인이 통과되어야 합니다.
+ 통과하는 상태 확인과 연결되어 있거나 상태 확인과 연결되어 있지 않기 때문에 한 개 이상의 가중치 기반 레코드가 정상 상태로 간주되어야 합니다. 후자의 경우 Route 53는 항상 가중치 기반 레코드를 정상 상태로 간주합니다.
다음 그림에서 왼쪽 상단에 있는 지연 시간 별칭 레코드에 대한 상태 확인이 실패했습니다. 그 결과 Route 53는 가중치 기반 레코드가 모두 정상인 경우에도 지연 시간 별칭 레코드가 참조하는 가중치 기반 레코드를 사용하여 쿼리에 응답하는 것을 중단합니다. Route 53는 지연 시간 별칭 레코드에 대한 상태 확인이 다시 정상인 경우에만 이러한 가중치 기반 레코드를 다시 고려하기 시작합니다. (예외 사항은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 단원을 참조하십시오.)
![\[두 Evaluate Target Health(대상 상태 평가)가 모두 예로 설정되어 있는 별칭 레코드와 별칭 레코드에 대한 상태 확인을 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-alias-hc-failed.png)
## 상태 확인을 생략하면 어떻게 됩니까?
복잡한 구성에서는 상태 확인을 비 별칭 레코드 전체에 연결하는 것이 중요합니다. 다음 예제에서 us-east-1 리전에서 가중치 기반 레코드 중 하나에 대한 상태 확인이 누락되었습니다.
![\[실패한 상태 확인 1개와 상태 확인이 없는 레코드 1개를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-missing-health-check.png)
이 구성에서 비 별칭 레코드에 대한 상태 확인을 생략할 때 발생하는 일은 다음과 같습니다.
1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다.
1. Route 53는 지연 시간 별칭 레코드에 대한 별칭 대상을 찾아서 해당 상태 확인의 상태를 확인합니다. 한 개의 가중치 기반 레코드에 대한 상태 확인이 실패했으므로 레코드는 고려 대상에서 생략됩니다.
1. us-east-1 리전에 대한 별칭 대상에서 기타 가중치 기반 레코드에는 상태 확인이 없습니다. 해당 리소스는 정상이거나 비정상이겠지만, 상태 확인이 없으면 Route 53는 알 방법이 없습니다. 리소스가 정상으로 가정하여 Route 53는 쿼리에 응답해 해당하는 값을 반환합니다.
## [Evaluate Target Health]를 [No]로 설정하면 어떻게 됩니까?
일반적으로 트리의 모든 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**Yes**]로 설정해야 합니다. **대상 상태 평가(Evaluate Target Health)**를 **아니요(No)**로 설정한 경우 레코드에 대한 상태 확인이 실패하는 경우에도 Route 53는 계속해서 별칭 레코드가 참조하는 레코드로 트래픽을 라우팅합니다.
다음 예제에서는 가중치 기반 레코드 전체가 상태 확인과 연결되었지만 us-east-1 리전의 지연 시간 별칭 레코드에 대해 [**Evaluate Target Health**]가 [**No**]로 설정되어 있습니다.
![\[Evaluate Target Health(대상 상태 평가)가 아니요로 설정된 별칭 레코드를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-eth-is-no.png)
이 구성에서 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**No**]로 설정할 때 발생하는 일은 다음과 같습니다.
1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다.
1. Route 53는 지연 시간 별칭 레코드에 대한 별칭 대상이 무엇인지 판단하여 해당 상태 확인을 확인합니다. 둘 다 실패합니다.
1. us-east-1 리전의 지연 시간 별칭 레코드에 대해 **대상 상태 평가(Evaluate Target Health)**의 값이 **아니요(No)**로 설정되어 있으므로 Route 53는 가지를 포기하고 ap-southeast-2 리전의 정상적인 레코드를 찾는 대신 이 가지에서 하나의 레코드를 선택해야 합니다.
# 상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식
동일한 이름, 동일한 유형(예: A 또는 AAAA) 및 동일한 라우팅 정책(예: 가중치 또는 장애 조치)을 보유한 레코드 그룹의 모든 레코드에 대한 상태 확인을 구성한 경우 Route 53는 정상 레코드를 선택하고 해당 레코드로부터 해당되는 값을 반환함으로써 DNS 쿼리에 응답합니다.
예를 들어, 3개의 가중치 A 레코드를 생성하고 세 레코드 모두에 상태 확인을 할당한다고 가정합니다. 한 레코드의 상태 확인이 비정상인 경우 Route 53는 다른 2개 레코드의 IP 주소를 통해 DNS 쿼리에 응답합니다.
다음은 Route 53가 정상적인 레코드를 선택하는 방식입니다.
1. Route 53는 처음에 라우팅 정책과 각 레코드에 대해 지정한 값을 기반으로 레코드를 선택합니다. 예를 들어, 가중치 레코드의 경우 Route 53는 각 레코드에 대해 지정한 가중치를 기반으로 레코드를 선택합니다.
1. Route 53가 레코드가 정상이라 확인한 경우:
+ **상태 확인이 연결된 비 별칭 레코드** - 상태 확인과 비 별칭 레코드를 연결한 경우 Route 53는 상태 확인의 현재 상태를 확인합니다.
Route 53는 상태 확인에 지정된 엔드포인트의 상태를 주기적으로 점검하는데, DNS 쿼리가 도착할 때는 상태 확인을 수행하지 않습니다.
상태 확인과 별칭 레코드를 연결할 수 있지만 상태 확인과 비 별칭 레코드만을 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 섹션을 참조하세요.
+ **대상 상태 평가가 예로 설정된 별칭 레코드** - Route 53는 ELB 로드 밸런서 또는 동일한 호스팅 영역의 또 다른 레코드와 같이 별칭 레코드가 참조하는 리소스의 상태를 확인합니다.
1. 레코드가 정상인 경우 Route 53는 IP 주소와 같이 해당되는 값으로 쿼리에 응답합니다.
레코드가 비정상인 경우 Route 53는 동일한 기준을 사용하여 또 다른 레코드를 선택하고 정상 레코드를 찾을 때까지 프로세스를 반복합니다.
Route 53는 레코드 선택 시 다음 기준을 사용합니다.
**항상 정상인 상태 확인이 없는 레코드**
동일한 이름과 유형을 보유한 레코드 그룹의 레코드에 연결된 상태 확인이 없는 경우 Route 53는 항상 이를 정상으로 여기고 쿼리에 대한 가능한 응답에 항상 이를 포함시킵니다.
**정상인 레코드가 없는 경우 모두 레코드가 정상임**
레코드 그룹의 레코드가 정상이 아닌 경우 Route 53는 DNS 쿼리에 대한 응답으로 무언가를 반환해야 하지만 한 레코드에 견주어 다른 레코드를 선택할 근거가 없습니다. 이런 상황에서 Route 53는 그룹의 레코드 전체를 정상으로 간주하고 라우팅 정책과 각 레코드에 지정한 값을 기반으로 하나의 레코드를 선택합니다.
**가중치가 0인 가중치 기반 레코드**
가중치 기반 레코드의 그룹에서 레코드 전체에 상태 확인을 추가하지만 어떤 레코드에는 0이 아닌 가중치를 부여하고 또 다른 레코드에는 0인 가중치를 부여하는 경우 상태 확인은 모든 레코드의 가중치가 0일 때와 동일하게 작업합니다. 단, 다음 경우는 예외입니다.
+ Route 53는 처음에 0이 아닌 가중치 기반 레코드만을 고려합니다(해당되는 경우).
+ 0보다 큰 가중치를 지닌 레코드 전체가 비정상인 경우 Route 53는 0인 가중치 기반 레코드를 고려합니다.
Route 53은 상황에 따라 가중치가 0인 레코드를 고려하므로 가중치가 0인 대상에도 DNS 쿼리에 대한 실행 가능한 응답이 있는지 확인하는 것이 중요합니다.
가중치 기반 레코드에 대한 자세한 내용은 [상태 확인 및 가중치 기반 라우팅](routing-policy-weighted.md#routing-policy-weighted-healthchecks)을 참조하십시오.
**별칭 레코드**
각 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**Yes**]로 설정함으로써 별칭 레코드에 대한 상태 확인을 구성할 수도 있습니다. 이로 인해 Route 53는 ELB 로드 밸런서 또는 동일한 호스팅 영역의 또 다른 레코드와 같이 레코드가 트래픽을 라우팅하는 리소스의 상태를 확인합니다.
예를 들어, 별칭 레코드에 대한 별칭 대상이 0이 아닌 가중치를 모두 지닌 가중치 기반 레코드의 그룹인 경우를 가정해 봅시다.
+ 하나 이상의 가중치 기반 레코드가 정상인 경우 Route 53는 별칭 레코드를 정상 상태로 간주합니다.
+ 가중치 기반 레코드가 정상이 아닌 경우 Route 53는 별칭 레코드를 비정상 상태로 간주합니다.
+ Route 53는 하나 이상의 가중치 기반 레코드가 다시 정상이 될 때까지 트리의 가지에 있는 레코드에 대한 판단을 중지합니다.
자세한 내용은 [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식상태 확인이 복잡한 구성에서 작동하는 방식](dns-failover-complex-configs.md) 섹션을 참조하세요.
**장애 조치 레코드**
장애 조치 레코드는 일반적으로 다른 라우팅 유형과 동일한 방식으로 작동합니다. 상태 확인을 생성하고 이를 비 별칭 레코드와 연결한 다음 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**Yes**]로 설정합니다. 다음 사항에 유의하세요.
+ 기본 및 보조 레코드는 모두 비 별칭 레코드 또는 별칭 레코드일 수 있습니다.
+ 기본 및 보조 장애 조치 레코드와 상태 확인을 연결하는 경우 Route 53가 요청에 응답하는 방식은 다음과 같습니다.
+ Route 53가 기본 레코드를 정상 상태로 간주하는 경우(상태 확인 엔드포인트가 정상인 경우) Route 53는 DNS 쿼리에 대한 응답으로 기본 레코드만 반환합니다.
+ Route 53가 기본 레코드를 비정상 상태로 간주하고 보조 레코드를 정상 상태로 간주하는 경우 Route 53는 그 대신에 보조 레코드를 반환합니다.
+ Route 53가 기본 및 보조 레코드를 모두 비정상 상태로 간주하는 경우 Route 53는 기본 레코드를 반환합니다.
+ 보조 레코드를 구성할 때 상태 확인 추가는 선택 사항입니다. 보조 레코드에 대한 상태 확인을 생략하고 기본 레코드에 대한 상태 확인 엔드포인트가 비정상인 경우 Route 53는 항상 보조 레코드를 사용하여 DNS 쿼리에 응답합니다. 이는 보조 레코드가 비정상인 경우라 할지라도 그대로 적용됩니다.
자세한 내용은 다음 항목을 참조하세요.
+ [하나의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](dns-failover-types.md#dns-failover-types-active-passive-one-resource)
+ [여러 개의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](dns-failover-types.md#dns-failover-types-active-passive-multiple-resources)
# 액티브-액티브 및 액티브-패시브 장애 조치
Route 53 상태 확인을 사용하여 액티브-액티브 및 액티브-패시브 장애 조치 구성을 구성할 수 있습니다. 장애 조치를 제외한 모든 [라우팅 정책](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)(또는 라우팅 정책의 조합)을 사용하여 액티브-액티브 장애 조치를 구성하고, 장애 조치 라우팅 정책을 사용하여 액티브-패시브 장애 조치를 구성합니다.
**Topics**
+ [액티브-액티브 장애 조치](#dns-failover-types-active-active)
+ [액티브-패시브 장애 조치](#dns-failover-types-active-passive)
## 액티브-액티브 장애 조치
모든 리소스를 대부분의 시간 동안 사용 가능하도록 하려면 이 장애 조치 구성을 사용하십시오. 리소스를 사용할 수 없는 경우 Route 53가 비정상 상태임을 판별하여 쿼리에 응답할 때 해당 리소스를 포함하지 않습니다.
액티브-액티브 장애 조치에서 동일한 이름, 동일한 유형(예: A 또는 AAAA) 및 동일한 라우팅 정책(예: 가중치 또는 지연 시간)을 보유한 모든 레코드는 Route 53가 이를 비정상으로 간주하지 않는 이상 활성 상태입니다. Route 53는 정상 레코드를 사용하여 DNS 쿼리에 응답할 수 있습니다.
## 액티브-패시브 장애 조치
기본 리소스 또는 리소스 그룹이 대부분의 시간 동안 사용 가능하도록 하고 보조 리소스 또는 리소스 그룹은 기본 리소스가 사용 불가능할 경우를 대비해 대기 중에 있도록 하고 싶다면 이 장애 조치 구성을 사용하십시오. 쿼리에 응답할 때 Route 53는 정상적인 기본 리소스만을 포함합니다. 모든 기본 리소스가 비정상인 경우 Route 53는 DNS 쿼리에 응답할 때 정상적인 보조 리소스만을 포함시키기 시작합니다.
**Topics**
+ [하나의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](#dns-failover-types-active-passive-one-resource)
+ [여러 개의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](#dns-failover-types-active-passive-multiple-resources)
+ [가중치 레코드를 사용하여 액티브-패시브 장애 조치 구성](#dns-failover-types-active-passive-weighted)
### 하나의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성
하나의 기본 레코드 및 보조 레코드를 사용하여 액티브-패시브 장애 조치를 생성하려면 레코드를 생성하고 라우팅 정책을 **장애 조치**로 지정합니다. 기본 리소스가 정상일 때 Route 53는 기본 레코드를 사용하여 DNS 쿼리에 응답합니다. 기본 리소스가 비정상일 때 Route 53는 보조 레코드를 사용하여 DNS 쿼리에 응답합니다.
### 여러 개의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성
여러 개의 리소스를 기본 레코드, 보조 레코드 또는 둘 모두에 연결할 수 있습니다. 이 구성에서 Route 53는 연결된 리소스 중 최소 하나가 정상인 한 기본 장애 조치 레코드를 정상으로 간주합니다. 자세한 내용은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 섹션을 참조하세요.
기본 또는 보조 레코드에 대해 여러 리소스를 사용하여 액티브-패시브 장애 조치를 구성하려면 다음 작업을 수행합니다.
1. 데이터 센터의 EC2 인스턴스 또는 웹 서버와 같이 트래픽을 라우팅하고자 하는 각 리소스에 대한 상태 확인을 생성합니다.
**참고**
[별칭 레코드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)를 생성할 수 있는 AWS 리소스로 트래픽을 라우팅하는 경우 해당 리소스에 대한 상태 확인을 생성하지 마십시오. 별칭 레코드를 생성할 때 대신 [**Evaluate Target Health**]의 값을 [**Yes**]로 설정합니다.
자세한 내용은 [상태 확인의 생성 및 업데이트](health-checks-creating.md) 섹션을 참조하세요.
1. 기본 리소스에 대한 레코드를 생성하고 다음 값을 지정합니다.
+ 각 레코드에 동일한 이름, 유형 및 라우팅 정책을 제공합니다. 예를 들어, 이름이 모두 failover-primary.example.com인 3개의 가중치 A 레코드를 생성할 수 있습니다.
+ 별칭 레코드를 생성할 수 있는 AWS 리소스를 사용하는 경우 대상 상태 평가에 **예를** 지정합니다. ****
별칭 레코드를 생성할 수 없는 리소스를 사용하는 경우 1단계의 해당 상태 확인을 각 레코드와 연결합니다.
자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 섹션을 참조하세요.
1. 보조 리소스에 대한 레코드를 생성하고 해당되는 경우 다음 값을 지정합니다.
+ 각 레코드에 동일한 이름, 유형 및 라우팅 정책을 제공합니다. 예를 들어, 이름이 모두 failover-secondary.example.com인 3개의 가중치 A 레코드를 생성할 수 있습니다.
+ 별칭 레코드를 생성할 수 있는 AWS 리소스를 사용하는 경우 대상 상태 평가에 **예를** 지정합니다. ****
별칭 레코드를 생성할 수 없는 리소스를 사용하는 경우 1단계의 해당 상태 확인을 각 레코드와 연결합니다.
**참고**
일부 고객은 웹 서버를 기본 리소스로 사용하고 웹 사이트 엔드포인트로 구성된 Amazon S3 버킷을 보조 리소스로 사용합니다. S3 버킷에는 단순한 "temporarily unavailable" 메시지가 포함됩니다. 해당 구성을 사용하는 경우 이 단계를 건너뛰고 4단계의 보조 리소스에 대한 장애 조치 별칭 레코드를 생성합니다.
1. 2개의 장애 조치 별칭 레코드(하나는 기본, 다른 하나는 보조)를 생성하고 다음 값을 지정합니다.
**기본 레코드**
+ **이름(Name)** - Route 53가 트래픽을 라우팅하고자 하는 도메인 이름(example.com) 또는 하위 도메인 이름(www.example.com)을 지정합니다.
+ **별칭(Alias)** - **예(Yes)**로 지정합니다.
+ **별칭 대상(Alias Target)** - 2단계에서 생성한 레코드의 이름을 지정합니다.
+ **라우팅 정책(Routing Policy)** - **장애 조치(Failover)**를 지정합니다.
+ **장애 조치 레코드 유형(Failover Record Type)** - **기본(Primary)**을 지정합니다.
+ **대상 상태 평가(Evaluate Target Health)** - **예(Yes)**를 지정합니다.
+ **상태 확인과 연결(Associate with Health Check)** - **아니요(No)**를 지정합니다.
**보조 레코드**
+ **이름(Name)** - 기본 레코드에 대해 지정한 것과 동일한 이름을 지정합니다.
+ **별칭(Alias)** - **예(Yes)**로 지정합니다.
+ **별칭 대상(Alias Target)** - 3단계에서 보조 리소스에 대한 레코드를 생성한 경우 해당 레코드의 이름을 지정합니다. 보조 리소스에 대해 Amazon S3 버킷을 사용하는 경우 웹 사이트 엔드포인트의 DNS 이름을 지정합니다.
+ **라우팅 정책(Routing Policy)** - **장애 조치(Failover)**를 지정합니다.
+ **장애 조치 레코드 유형(Failover Record Type)** - **보조(Secondary)**를 지정합니다.
+ **대상 상태 평가(Evaluate Target Health)** - **예(Yes)**를 지정합니다.
+ **상태 확인과 연결(Associate with Health Check)** - **아니요(No)**를 지정합니다.
### 가중치 레코드를 사용하여 액티브-패시브 장애 조치 구성
경고를 포함하여 액티브-패시브 장애 조치에 대한 가중치 기반 레코드를 사용할 수도 있습니다. 일부 레코드에 대해 0이 아닌 가중치를 지정하고, 나머지 레코드에 대해 0의 가중치를 지정한 경우 Route 53는 0이 아닌 가중치를 가진 정상 레코드만을 사용하여 DNS 쿼리에 응답합니다. 0보다 큰 가중치를 지닌 레코드 전체가 비정상인 경우 Route 53는 가중치가 0인 레코드를 사용하여 쿼리에 응답합니다.
**참고**
Route 53가 가중치가 0인 레코드를 사용하여 DNS 쿼리에 응답하기 전에 가중치가 0이 아닌 모든 레코드가 비정상이어야 합니다. 다른 리소스를 사용할 수 없을 때 웹 서버와 같은 마지막 정상 리소스가 모든 트래픽을 처리할 수 없는 경우 이로 인해 웹 애플리케이션 또는 웹 사이트가 불안정하게 될 수 있습니다.
# 프라이빗 호스팅 영역에서 장애 조치 구성
프라이빗 호스팅 영역에서 장애 조치 레코드를 생성하는 경우 다음에 유의하십시오.
+ Route 53 상태 확인은 VPC 외부에 있습니다. IP 주소별로 VPC 내에 있는 엔드포인트의 상태를 확인하려면 VPC의 인스턴스에 퍼블릭 IP 주소를 할당해야 합니다.
+ CloudWatch 지표를 생성하고 경보를 지표와 연결한 다음 경보의 데이터 스트림을 기반으로 하는 상태 확인을 생성할 수 있습니다. 예를 들어, EC2 `StatusCheckFailed` 지표의 상태를 확인하는 CloudWatch 지표를 생성하고 경보를 지표에 추가한 다음 경보의 데이터 스트림을 기반으로 하는 상태 확인을 생성하여 프라이빗 IP 주소만 가지는 Virtual Private Cloud(VPC) 내의 인스턴스를 확인할 수 있습니다. CloudWatch 콘솔을 사용한 CloudWatch 지표 및 경보 생성에 대한 정보는 [Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/)를 참조하십시오.
자세한 내용은 [프라이빗 호스팅 영역 사용](hosted-zones-private.md) 및 [CloudWatch를 이용한 상태 확인 모니터링](monitoring-health-checks.md) 섹션을 참조하세요.
# Amazon Route 53가 장애 조치 문제를 방지하는 방법
Route 53가 실행하는 장애 조치 알고리즘은 트래픽을 정상적인 엔드포인트로 라우팅할 뿐만 아니라 상태 확인 및 애플리케이션의 구성 오류, 엔드포인트 오버로드, 분할 오류 등으로 인해 재난 시나리오가 악화되는 것을 방지하기 위해 설계되었습니다.
**Topics**
+ [Amazon Route 53가 Cascading 오류를 방지하는 방법](#dns-failover-cascading-failures)
+ [Amazon Route 53가 인터넷 분할을 다루는 방식](#dns-failover-internet-partitions)
## Amazon Route 53가 Cascading 오류를 방지하는 방법
Cascading 오류에 대한 1차 방어로, 각 요청 라우팅 알고리즘(가중치, 장애 조치 등)에는 최후의 수단 모드가 있습니다. 이 특수 모드에서 모든 레코드가 비정상 상태로 간주되는 경우 Route 53 알고리즘은 다시 모든 레코드를 정상 상태로 간주하기 시작합니다.
예를 들어 몇 개의 호스트 상에서 애플리케이션의 모든 인스턴스가 상태 확인 요청을 거부하면, Route 53 DNS 서버는 DNS 응답을 반환하지 않거나 NXDOMAIN(존재하지 않는 도메인) 응답을 반환하기보다는 어떻게든 하나의 응답을 선택하여 반환합니다. 애플리케이션은 사용자에게 응답할 수 있지만 여전히 상태 확인에 실패하므로, 이것은 구성 오류를 어느 정도 방지해 줍니다.
마찬가지로 애플리케이션이 오버로드되고 3개 중 1개의 엔드포인트가 상태 확인에 실패하여 Route 53 DNS 응답에서 제외되는 경우에 Route 53는 2개의 남은 엔드포인트 사이에 응답을 분산합니다. 남은 엔드포인트가 추가 로드를 다루지 못하여 실패하게 되면, Route 53는 요청을 다시 3개의 엔드포인트 전체로 분산하기 시작합니다.
## Amazon Route 53가 인터넷 분할을 다루는 방식
비록 흔하지는 않지만 때때로 심각한 인터넷 분할이 발생하는데, 이는 더 큰 지리 지역이 다른 지리 지역과 인터넷상에서 통신할 수 없는 상태를 뜻합니다. 이러한 분할 동안 Route 53 위치는 엔드포인트의 상태에 대해 서로 다른 결론에 도달하여 CloudWatch에 보고되는 상태와 다를 수 있습니다. 각 AWS 리전의 Route 53 상태 확인 프로그램은 상태 확인 상태를 모든 Route 53 위치로 지속적으로 전송합니다. 인터넷 분할이 일어나는 동안에 각 Route 53 위치는 보통 가장 가까운 리전에서 이러한 상태의 일부에만 액세스할 수 있습니다.
예를 들어 남아메리카를 오가는 연결에 영향을 미치는 인터넷 분할 동안 Route 53 남아메리카(상파울루) 위치의 Route 53 DNS 서버들은 남아메리카(상파울루) AWS 리전의 상태 확인 엔드포인트에는 접속이 양호할 수 있지만, 그 밖의 리전에 있는 엔드포인트에 대해서는 접속이 불량일 수 있습니다. 이와 동시에 미국 동부(오하이오)의 Route 53는 남아메리카(상파울루) 리전의 상태 확인 엔드포인트에 대해 접속이 불량하여 해당 레코드가 비정상이라는 결론을 내릴 수도 있습니다.
이와 같은 분할은 엔드포인트들의 국지적 가시성을 근거로 Route 53 위치가 엔드포인트들의 상태에 대해 서로 다른 결론을 내리는 상황을 야기할 수 있습니다. 이것이 바로 연결할 수 있는 상태 확인 프로그램 중 일부만이 엔드포인트를 정상이라고 여기면 각 Route 53 위치가 엔드포인트를 정상이라고 여기는 이유입니다.