기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 퍼블릭 호스팅 영역 작업
퍼블릭 호스팅 영역이란 특정 도메인(예: example.com)과 그 하위 도메인(acme.example.com, zenith.example.com)의 트래픽을 인터넷에서 라우팅하는 방식에 대한 정보를 담고 있는 컨테이너입니다. 다음 두 가지 방법 중 하나로 퍼블릭 호스팅 영역을 얻습니다.
+ Route 53에 도메인을 등록하면 호스팅 영역이 자동으로 생성됩니다.
+ 기존 도메인에 대한 DNS 서비스를 Route 53로 전송하는 경우 도메인에 대한 호스팅 영역 생성부터 시작합니다. 자세한 내용은 [Amazon Route 53를 기존 도메인에 대한 DNS 서비스로 설정Route 53을 기존 도메인에 대한 DNS 서비스로 설정](MigratingDNS.md) 섹션을 참조하세요.
두 가지 경우 모두 호스팅 영역에 레코드를 생성하여 도메인 및 하위 도메인에 대한 트래픽의 라우팅 방법을 지정합니다. 예를 들어, 레코드를 생성하여 www.example.com에 대한 트래픽을 CloudFront 배포 또는 데이터 센터의 웹 서버로 라우팅할 수 있습니다. 레코드에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md) 단원을 참조하십시오.
이 주제에서는 Amazon Route 53 콘솔을 사용하여 퍼블릭 호스팅 영역을 생성, 나열 및 삭제하는 방법을 살펴봅니다.
**참고**
Route 53 *프라이빗* 호스팅 영역을 사용하여 Amazon VPC 서비스에서 생성한 하나 이상의 VPC 내의 트래픽을 라우팅할 수도 있습니다. 자세한 내용은 [프라이빗 호스팅 영역 사용](hosted-zones-private.md) 섹션을 참조하세요.
**Topics**
+ [퍼블릭 호스팅 영역 작업 시 고려 사항](hosted-zone-public-considerations.md)
+ [퍼블릭 호스팅 영역 생성](CreatingHostedZone.md)
+ [퍼블릭 호스팅 영역에 대한 이름 서버 가져오기](GetInfoAboutHostedZone.md)
+ [퍼블릭 호스팅 영역 나열](ListInfoOnHostedZone.md)
+ [퍼블릭 호스팅 영역에서 DNS 쿼리 지표 보기](hosted-zone-public-viewing-query-metrics.md)
+ [퍼블릭 호스팅 영역 삭제](DeleteHostedZone.md)
+ [Route 53에서 DNS 응답 확인](dns-test.md)
+ [화이트 레이블 이름 서버 구성](white-label-name-servers.md)
+ [Amazon Route 53에서 퍼블릭 호스팅 영역에 대해 생성하는 NS 및 SOA 레코드](SOA-NSrecords.md)
+ [퍼블릭 DNS 레코드 관리를 위한 가속화된 복구 활성화](accelerated-recovery.md)
# 퍼블릭 호스팅 영역 작업 시 고려 사항
퍼블릭 호스팅 영역 작업 시 다음을 고려하십시오.
**NS 및 SOA 레코드**
호스팅 영역을 생성하면 Amazon Route 53에서 해당 영역에 대한 NS(이름 서버) 레코드 및 SOA(권한 시작) 레코드를 자동으로 생성합니다. NS 레코드는 DNS 쿼리가 Route 53 이름 서버에 라우팅되도록 등록 기관 또는 DNS 서비스에 부여하는 4개의 이름 서버를 식별합니다. NS 및 SOA 레코드에 관한 자세한 내용은 [Amazon Route 53에서 퍼블릭 호스팅 영역에 대해 생성하는 NS 및 SOA 레코드](SOA-NSrecords.md) 섹션을 참조하세요.
**동일한 이름을 보유한 여러 개의 호스팅 영역**
이름이 동일한 2개 이상의 호스팅 영역을 생성하고 각 호스팅 영역에 서로 다른 레코드를 추가할 수 있습니다. Route 53는 호스팅 영역마다 4개의 이름 서버를 할당하고 해당 이름 서버는 서로 각각 다릅니다. 등록 기관의 이름 서버 레코드를 업데이트하는 경우에는 올바른 호스팅 영역, 즉 도메인에 대한 쿼리에 응답할 때 Route 53에서 사용하기를 원하는 레코드를 포함하는 호스팅 영역에 대한 Route 53 이름 서버를 주의하여 사용하세요. Route 53는 이름이 같은 다른 호스팅 영역의 레코드에 대한 값을 반환하지 않습니다.
**재사용 가능한 위임 세트**
기본적으로 Route 53는 생성하는 각 호스팅 영역에 고유한 4개의 이름 서버 세트(합쳐서 위임 세트라고 함)를 할당합니다. 다수의 호스팅 영역을 생성하려는 경우, 재사용 가능한 위임 세트를 프로그래밍 방식으로 생성할 수 있습니다. (재사용 가능한 위임 세트는 Route 53 콘솔에서 이용할 수 없습니다.) 그런 다음 프로그래밍 방식으로 호스팅 영역을 생성하고 각 호스팅 영역에 재사용 가능한 동일한 위임 세트, 즉 동일한 4개의 이름 서버를 할당할 수 있습니다.
재사용 가능한 위임 세트는 Route 53로의 DNS 서비스 마이그레이션을 간소화합니다. Route 53를 DNS 서비스로 사용하기를 원하는 모든 도메인에 대해 동일한 4개의 이름 서버를 사용하도록 도메인 이름 등록자에게 지시할 수 있기 때문입니다. 자세한 내용은 *Amazon Route 53 API 참조*의 [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)를 참조하세요.
# 퍼블릭 호스팅 영역 생성
퍼블릭 호스팅 영역이란 특정 도메인(예: example.com)과 그 하위 도메인(acme.example.com, zenith.example.com)의 트래픽을 인터넷에서 라우팅하는 방식에 대한 정보를 담고 있는 컨테이너입니다. 호스팅 영역을 생성한 이후 레코드를 생성하여 도메인 및 하위 도메인에 대한 트래픽의 라우팅 방법을 지정합니다.
**제한 사항**
Route 53를 사용하여 호스팅 영역을 생성할 때 다음 제한 사항에 유의하세요.
관리자 권한이 있는 도메인만 호스팅 영역을 생성할 수 있습니다. 일반적으로 도메인을 소유하고 있다는 뜻이지만 도메인 등록자용 애플리케이션을 개발하는 경우도 해당될 수 있습니다.
도메인 및 하위 도메인에 대해서만 호스팅 영역을 생성할 수 있습니다. Route 53는 `.com`과 같은 최상위 도메인(TLD)의 호스팅을 지원하지 않습니다.
**Route 53 콘솔을 사용하여 퍼블릭 호스팅 영역을 생성하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. Route 53를 처음 사용하는 경우 **DNS 관리(DNS management)**에서 **시작하기(Get started)**를 선택합니다.
Route 53를 이미 사용하고 있는 경우 탐색 창에서 **Hosted Zones(호스팅 영역)**를 선택합니다.
1. **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
1. **Create Hosted Zone(호스팅 영역 생성)** 창에서 트래핑을 라우팅하고자 하는 도메인의 이름을 입력합니다. 선택적으로 설명을 입력할 수도 있습니다.
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하세요.
1. [**Type**]에는 [**Public Hosted Zone**]의 기본값을 수락합니다.
1. **생성(Create)**을 선택합니다.
1. 도메인과 하위 도메인의 트래픽을 라우팅할 방법을 지정하는 레코드를 생성합니다. 자세한 내용은 [레코드 작업](rrsets-working-with.md) 섹션을 참조하세요.
1. 새로운 호스팅 영역을 레코드를 사용하여 도메인에 대한 트래픽을 라우팅하려면 해당 항목을 참조하십시오.
+ 다른 도메인 등록 기관에 등록된 도메인에 대해 Route 53를 DNS 서비스로 사용하려면 [Amazon Route 53를 기존 도메인에 대한 DNS 서비스로 설정Route 53을 기존 도메인에 대한 DNS 서비스로 설정](MigratingDNS.md) 섹션을 참조하세요.
+ 도메인이 Route 53에 등록되어 있으면 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 섹션을 참조하세요.
# 퍼블릭 호스팅 영역에 대한 이름 서버 가져오기
도메인 등록을 위한 DNS 서비스를 변경하려는 경우 퍼블릭 호스팅 영역의 이름 서버를 가져옵니다. DNS 서비스를 변경하는 방법에 대한 자세한 내용은 [Amazon Route 53를 기존 도메인에 대한 DNS 서비스로 설정Route 53을 기존 도메인에 대한 DNS 서비스로 설정](MigratingDNS.md) 단원을 참조하십시오.
**참고**
일부 등록자는 IP 주소를 사용하는 이름 서버만 지정하도록 허용하며, 정규화된 도메인 이름을 지정하는 것은 허용하지 않습니다. 등록자가 IP 주소를 사용하도록 요구하는 경우, dig 유틸리티(Mac, Unix 또는 Linux의 경우) 또는 nslookup 유틸리티(Windows의 경우)를 사용하여 이름 서버의 IP 주소를 가져올 수 있습니다. Amazon은 이름 서버의 IP 주소를 거의 변경하지 않으며, IP 주소를 변경해야 하는 경우 미리 알려 드립니다.
**Route 53 콘솔을 사용하여 호스팅 영역에 대한 이름 서버를 가져오려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted Zones)**을 클릭합니다.
1. **호스팅 영역(Hosted zones)** 페이지에서 호스팅 영역의 (이름 대신) 라디오 버튼을 선택한 다음 **세부 정보 보기(View details)**를 선택합니다.
1. 호스팅 영역에 대한 세부 정보 페이지에서 **호스팅 영역 세부 정보(Hosted zone details)**를 선택합니다.
1. **이름 서버(Name servers)**에 나열된 서버 4개의 이름을 기록합니다.
# 퍼블릭 호스팅 영역 나열
Amazon Route 53 콘솔을 사용하여 현재 AWS 계정으로 생성한 모든 호스팅 영역을 나열할 수 있습니다. Route 53 API를 사용하여 호스팅 영역을 나열하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)를 참조하세요.
**Route 53 콘솔을 사용하여 AWS 계정과 연결된 퍼블릭 호스팅 영역을 나열하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다. 페이지에는 현재 로그인한 AWS 계정과 연결된 호스팅 영역 목록이 표시됩니다.
1. 호스팅 영역을 필터링하려면 테이블 상단에 있는 검색 창을 사용합니다.
일부 동작은 호스팅 영역에 최대 2,000개 또는 2,000개 이상의 레코드를 포함하는지 여부에 따라 다릅니다.
**호스팅 영역이 최대 2,000개인 경우**
+ 특정 값을 보유한 레코드를 표시하려면 검색 창을 클릭하고 드롭다운 목록에서 속성을 선택한 다음 값을 입력합니다. 검색 창에 직접 값을 입력하고 Enter 키를 누를 수도 있습니다. 예를 들어, 이름이 **abc**로 시작하는 호스팅 영역을 표시하려면 검색 창에 해당 값을 입력하고 Enter 키를 누릅니다.
+ 호스팅 영역 유형이 동일한 호스팅 영역만 표시하려면 드롭다운 목록에서 해당 유형을 선택하고 그 유형을 입력합니다.
**호스팅 영역이 2,000개 이상인 경우**
+ 정확한 도메인 이름, 모든 속성 및 유형을 기반으로 속성을 검색할 수 있습니다.
+ 정확한 도메인 이름을 사용하여 검색하면 더 빠른 검색 결과를 얻을 수 있습니다.
# 퍼블릭 호스팅 영역에서 DNS 쿼리 지표 보기
지정된 퍼블릭 호스팅 영역이나 퍼블릭 호스팅 영역의 조합에서 Route 53가 응답하고 있는 총 DNS 쿼리의 수를 볼 수 있습니다. 지표가 CloudWatch에 표시되면 그래프를 보고 확인하고 싶은 기간을 선택한 다음, 기타 다양한 방법으로 지표를 사용자 정의할 수 있습니다. 또한 지정된 기간의 DNS 쿼리 수가 지정된 수준을 넘거나 수준에 미달될 때 사용자에게 알리기 위한 경보를 생성하고 알림을 구성할 수 있습니다.
**참고**
Route 53는 모든 퍼블릭 호스팅 영역에서 CloudWatch에 DNS 쿼리 수를 자동으로 전송하기 때문에 쿼리 지표를 보기 위해 아무것도 사전에 구성할 필요가 없습니다. DNS 쿼리 지표에 대한 요금은 없습니다.
**어떤 DNS 쿼리가 계산됩니까?**
지표에는 DNS 해석기가 Route 53로 전달하는 쿼리만 포함되어 있습니다. DNS 해석기가 쿼리(예: example.com의 로드 밸런서에 대한 IP 주소)에 대한 응답을 이미 캐시한 경우 해석기는 해당 레코드에 대한 TTL이 만료될 때까지 쿼리를 Route 53로 전달하지 않고 캐시된 응답을 계속 반환합니다.
도메인 이름(example.com) 또는 하위 도메인 이름(www.example.com)에 대해 제출된 DNS 쿼리 수, 사용자가 사용하고 있는 해석기 및 레코드에 대한 TTL에 따라 DNS 쿼리 지표에는 DNS 해석기에 제출된 수 천 개의 쿼리 중 한 개의 쿼리에 대한 정보만 포함될 수 있습니다. DNS 작업 방법에 대한 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 섹션을 참조하세요.
**호스팅 영역에 대한 쿼리 지표가 언제 CloudWatch에 나타나기 시작합니까?**
호스팅 영역을 생성한 후 CloudWatch에 호스팅 영역이 나타나기까지는 최대 몇 시간이 걸립니다. 또한 표시할 데이터가 있도록 호스팅 영역의 레코드에 대한 DNS 쿼리를 제출해야 합니다.
**지표는 미국 동부(버지니아 북부)에서만 사용 가능**
콘솔의 지표를 가져오려면 해당 리전을 미국 동부(버지니아 북부)로 선택해야 합니다. AWS CLI를 사용하여 지표를 가져오려면 AWS 리전을 지정하지 않은 상태로 두거나를 리전`us-east-1`으로 지정해야 합니다. 다른 리전을 선택한 경우에는 Route 53 지표를 사용할 수 없습니다.
**DNS 쿼리의 CloudWatch 지표 및 측정기준**
DNS 쿼리의 CloudWatch 지표 및 측정기준에 대한 자세한 내용은 [Amazon CloudWatch를 사용하여 호스팅 영역 모니터링](monitoring-hosted-zones-with-cloudwatch.md) 섹션을 참조하세요. CloudWatch 지표에 대한 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)을 참조하세요.
**DNS 쿼리에 대한 세부 데이터 얻기**
다음 값을 포함하여 Route 53가 응답하는 각 DNS 쿼리에 대한 세부 정보를 가져오려면 다음과 같이 쿼리 로깅을 구성할 수 있습니다.
+ 요청된 도메인 또는 하위 도메인
+ 요청의 날짜 및 시간
+ DNS 레코드 유형(예: A 또는 AAAA)
+ DNS 쿼리에 응답한 Route 53 엣지 로케이션
+ DNS 응답 코드(예: `NoError` 또는 `ServFail`)
자세한 내용은 [퍼블릭 DNS 쿼리 로깅](query-logs.md) 섹션을 참조하세요.
**DNS 쿼리 지표를 가져오는 방법**
사용자가 호스팅 영역을 생성하는 즉시 Amazon Route 53는 지표 및 측정기준을 1분마다 CloudWatch에 전송하기 시작합니다. 다음 절차를 사용하여 CloudWatch 콘솔에서 지표를 보거나 AWS Command Line Interface ()를 사용하여 지표를 볼 수 있습니다AWS CLI.
**Topics**
+ [CloudWatch 콘솔에서 퍼블릭 호스팅 영역의 DNS 쿼리 지표 확인](#hosted-zone-public-viewing-query-metrics-console)
+ [를 사용하여 DNS 쿼리 지표 가져오기 AWS CLI](#hosted-zone-public-viewing-query-metrics-cli)
## CloudWatch 콘솔에서 퍼블릭 호스팅 영역의 DNS 쿼리 지표 확인
CloudWatch 콘솔에서 퍼블릭 호스팅 영역의 DNS 쿼리 지표를 확인하려면 다음 절차를 수행합니다.
**CloudWatch 콘솔에서 퍼블릭 호스팅 영역의 DNS 쿼리 지표를 확인하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **지표(Metrics)**를 선택합니다.
1. 콘솔의 오른쪽 상단에 있는 AWS 리전 목록에서 **미국 동부(버지니아 북부)**를 선택합니다. 다른 AWS 리전을 선택하면 Route 53 지표를 사용할 수 없습니다.
1. **모든 지표**(All metrics) 탭에서 [**Route 53**]을 선택합니다.
1. **Hosted Zone Metrics(호스팅 영역 지표)**를 선택합니다.
1. 지표 이름이 **DNSQueries**인 하나 이상의 호스팅 영역에 대해 확인란을 클릭합니다.
1. **그래프로 표시된 지표** 탭에서 원하는 형식으로 지표를 볼 수 있도록 해당 값을 변경합니다.
**통계**에서 **합계** 또는 **SampleCount**를 선택합니다. 두 통계 모두 동일한 값을 표시합니다.
## 를 사용하여 DNS 쿼리 지표 가져오기 AWS CLI
를 사용하여 DNS 쿼리 지표를 가져오려면 [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) 명령을 AWS CLI사용합니다. 다음 사항에 유의하세요.
+ 별도의 JSON 파일에서 명령의 대부분 값을 지정합니다. 자세한 내용은 [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)를 참조하십시오.
+ 명령은 JSON 파일에서 `Period`에 대해 지정한 시간 간격마다 하나의 값을 반환합니다. `Period`는 초 단위이므로 5분의 기간을 지정하고 `Period`에 대해 `60`을 지정하면 5개의 값을 얻게 됩니다. 5분의 기간을 지정하고 `Period`에 대해 `300`를 지정하면 한 개의 값을 얻게 됩니다.
+ JSON 파일에서 `Id`에 대해 어떤 값이든 지정할 수 있습니다.
+ AWS 리전을 지정하지 않은 상태로 두거나를 리전`us-east-1`으로 지정합니다. 다른 리전을 선택한 경우에는 Route 53 지표를 사용할 수 없습니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*[의 AWS CLI 구성을](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) 참조하세요.
다음은 2019년 5월 1일 4:01에서 4:07 사이의 5분 동안 DNS 쿼리 지표를 가져오는 데 사용하는 AWS CLI 명령입니다. `metric-data-queries` 파라미터는 이러한 명령을 따르는 샘플 JSON 파일을 참조합니다.
```
aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z
```
아래에 JSON 파일 샘플이 나와 있습니다.
```
[
{
"Id": "my_dns_queries_id",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Route53",
"MetricName": "DNSQueries",
"Dimensions": [
{
"Name": "HostedZoneId",
"Value": "Z1D633PJN98FT9"
}
]
},
"Period": 60,
"Stat": "Sum"
},
"ReturnData": true
}
]
```
아래는 이 명령에서 나온 출력값입니다. 다음 사항에 유의하세요.
+ 명령의 시작 시간과 종료 시간은 `2019-05-01T04:01:00Z`에서 `2019-05-01T04:07:00Z`까지 7분의 기간에 적용됩니다.
+ 반환 값은 단 6개입니다. 이 기간 동안에는 DNS 쿼리가 없었기 때문에 `2019-05-01T04:05:00Z`에 대한 값은 없습니다.
+ JSON 파일에서 지정된 `Period`의 값은 `60`(초)이므로 1분의 간격을 두고 값들이 보고됩니다.
```
{
"MetricDataResults": [
{
"Id": "my_dns_queries_id",
"StatusCode": "Complete",
"Label": "DNSQueries",
"Values": [
101.0,
115.0,
103.0,
127.0,
111.0,
120.0
],
"Timestamps": [
"2019-05-01T04:07:00Z",
"2019-05-01T04:06:00Z",
"2019-05-01T04:04:00Z",
"2019-05-01T04:03:00Z",
"2019-05-01T04:02:00Z",
"2019-05-01T04:01:00Z"
]
}
]
}
```
# 퍼블릭 호스팅 영역 삭제
이 섹션에서는 Amazon Route 53 콘솔을 사용하여 퍼블릭 호스팅 영역을 삭제하는 방법을 설명합니다.
기본 SOA 및 NS 레코드 이외의 레코드가 없는 경우에만 호스팅 영역을 삭제할 수 있습니다. 호스팅 영역에 다른 레코드가 포함되어 있는 경우, 호스팅 영역을 삭제하기 전에 이를 삭제해야 합니다. 이를 통해 레코드를 포함하고 있는 호스팅 영역을 실수로 삭제하는 일을 방지할 수 있습니다.
**Topics**
+ [사용 중인 도메인으로의 트래픽 라우팅 방지](#delete-public-hosted-zone-stop-routing)
+ [다른 서비스에서 생성한 퍼블릭 호스팅 영역 삭제](#delete-public-hosted-zone-created-by-another-service)
+ [Route 53 콘솔을 사용하여 퍼블릭 호스팅 영역 삭제](#delete-public-hosted-zone-procedure)
## 사용 중인 도메인으로의 트래픽 라우팅 방지
도메인 등록을 유지하는 동시에 웹 사이트 또는 웹 애플리케이션으로 인터넷 트래픽이 라우팅되는 것을 중지하고자 한다면 호스팅 영역을 삭제하는 대신 호스팅된 영역에서 *레코드*를 삭제하는 것이 좋습니다.
**중요**
호스팅 영역을 삭제하면 호스팅 영역의 삭제를 취소할 수 없습니다. 새 호스팅 영역을 만들고 도메인 등록을 위한 이름 서버를 업데이트해야 합니다. 도메인 등록은 효력이 발생하려면 최대 48 시간이 걸립니다. 또한, 호스팅 영역을 삭제하면 귀하의 도메인을 사용하여 다른 사람이 도메인과 라우팅 트래픽을 이들 리소스로 가로챌 수 있습니다.
하위 도메인에 대한 책임을 호스팅 영역으로 위임하고 하위 호스팅 영역을 삭제하려면 하위 호스팅 영역과 이름이 같은 NS 레코드를 삭제하여 상위 호스팅 영역도 업데이트해야 합니다. 예를 들어 호스팅 영역 acme.example.com을 삭제하려면 example.com 호스팅 영역에서 NS 레코드 acme.example.com도 삭제해야 합니다. 먼저 NS 레코드를 삭제하고 NS 레코드의 TTL이 지속될 때까지 기다린 후 하위 호스팅 영역을 삭제하는 것이 좋습니다. 이렇게 하면 DNS 해석기가 하위 호스팅 영역의 이름 서버를 계속 캐시하는 기간 동안 다른 누군가가 하위 호스팅 영역을 가로챌 수 없습니다.
호스팅 영역의 요금을 매달 부담하지 않으려면 무료 DNS 서비스로 도메인의 DNS 서비스를 이전할 수 있습니다. DNS 서비스를 이전할 경우, 도메인 등록을 위해 이름 서버를 업데이트해야 합니다. 도메인이 Route 53에 등록된 경우 Route 53 이름 서버를 새로운 DNS 서비스의 이름 서버로 바꾸는 방법에 대한 자세한 내용은 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 섹션을 참조하세요. 도메인이 다른 등록 대행자에 등록되어 있는 경우 등록 대행자가 제공한 방법을 사용하여 도메인 등록에 대한 이름 서버를 업데이트하십시오. 자세한 내용은 인터넷에서 "무료 DNS 서비스"를 검색하여 참조하십시오.
## 다른 서비스에서 생성한 퍼블릭 호스팅 영역 삭제
호스팅 영역이 다른 서비스에서 생성된 경우 Route 53 콘솔을 사용하여 삭제할 수 없습니다. 대신 다른 서비스에 대한 해당 프로세스를 사용해야 합니다.
+ **AWS Cloud Map** - 퍼블릭 DNS 네임스페이스를 생성할 때가 AWS Cloud Map 생성한 호스팅 영역을 삭제하려면 namespace를 삭제합니다. 호스팅 영역을 자동으로 AWS Cloud Map 삭제합니다. 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [네임스페이스 삭제](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html)를 참조하세요.
+ **Amazon Elastic Container Service(Amazon ECS) 서비스 검색** – 서비스 검색을 사용하여 서비스를 만들 때 Amazon ECS에서 생성한 퍼블릭 호스팅 영역을 삭제하려면 네임스페이스를 사용하는 Amazon ECS 서비스를 삭제하고 해당 네임스페이스를 삭제하세요. 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [서비스 삭제](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html)를 참조하세요.
## Route 53 콘솔을 사용하여 퍼블릭 호스팅 영역 삭제
Route 53 콘솔을 사용하여 퍼블릭 호스팅 영역을 삭제하려면 다음 절차를 수행하세요.
**Route 53 콘솔을 사용하여 퍼블릭 호스팅 영역을 삭제하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택하고 삭제하려는 호스팅 영역에 강조 표시된 링크를 선택합니다.
1. 삭제할 호스팅 영역에 NS 및 SOA 레코드만 포함되어 있는지 확인합니다. 다른 레코드가 있는 경우 삭제합니다. DNSSEC 서명도 사용하지 않아야 합니다.
**참고**
이러한 요구 사항을 완료하지 않고 호스팅 영역을 삭제하려고 시도하면 Route 53가 다음과 같은 오류를 반환합니다.
DNSSEC 서명이 활성화된 경우: 지정된 호스팅 영역에 DNSSEC 키 서명 키가 포함되어 있으므로 삭제할 수 없습니다.
다른 리소스 레코드 세트가 있는 경우(기본 SOA 및 NS 레코드 제외): 지정된 호스팅 영역에 필수가 아닌 리소스 레코드 세트가 포함되어 있으므로 삭제할 수 없습니다.
1. 호스팅 영역 세부 정보 페이지의 **레코드(Records)** 목록에 **유형(Type)** 열의 값이 NS 또는 SOA 이외의 레코드가 포함되어 있는 경우, 해당 행을 선택한 다음 **삭제(Delete)**를 선택합니다.
연속된 여러 레코드를 선택하려면 첫 번째 행을 선택한 다음, [**Shift**] 키를 누른 상태에서 마지막 행을 선택합니다. 비연속적인 여러 레코드를 선택하려면 첫 번째 행을 선택한 다음, [**Ctrl**] 키를 누른 상태에서 나머지 행을 선택합니다.
**참고**
호스팅 영역의 하위 도메인에 대한 NS 레코드를 생성한 경우, 해당 레코드 역시 삭제합니다.
1. **호스팅 영역(Hosted zones)** 페이지로 돌아가서 삭제하려는 호스팅 영역의 행을 선택합니다.
1. **삭제**를 선택합니다.
1. 확인 키를 입력하고 **삭제(Delete)**를 선택합니다.
1. 도메인을 인터넷에서 사용 불가능하게 만들려면 DNS 서비스를 무료 DNS 서비스로 이전한 후 Route 53 호스팅 영역을 삭제하세요. 이렇게 하면 이후의 DNS 쿼리가 잘못 라우팅되지 않도록 할 수 있습니다.
도메인이 Route 53에 등록된 경우 Route 53 이름 서버를 새로운 DNS 서비스의 이름 서버로 바꾸는 방법에 대한 자세한 내용은 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 섹션을 참조하세요. 도메인이 다른 등록 대행자에 등록되어 있는 경우 등록 대행자가 제공한 방법을 사용하여 도메인에 대한 이름 서버를 변경하십시오.
**참고**
하위 도메인(acme.example.com)의 호스팅 영역을 삭제하는 경우에는 도메인(example.com)의 이름 서버를 변경할 필요가 없습니다.
# Route 53에서 DNS 응답 확인
도메인에 대해 Amazon Route 53 호스팅 영역을 생성한 경우 콘솔에서 DNS 확인 도구를 사용하여 DNS 서비스로 Route 53를 사용하도록 도메인을 구성하면 Route 53가 어떻게 DNS 쿼리에 응답하는지 확인할 수 있습니다. 또한 지리 위치, 지리 근접성 및 지연 시간 레코드에 대해 특정 DNS 해석기 및/또는 클라이언트 IP 주소에서 쿼리를 시뮬레이션하여 Route 53에서 반환하는 응답을 확인할 수 있습니다.
**중요**
이 도구는 Domain Name System에 쿼리를 제출하지 않으며 호스팅 영역의 레코드 설정을 기반으로 해서만 응답합니다. 이 도구는 호스팅 영역이 현재 도메인의 트래픽을 라우팅하는 데 사용되고 있는지 여부에 관계없이 동일한 정보를 반환합니다.
DNS 확인 도구는 퍼블릭 호스팅 영역에만 사용할 수 있습니다.
**참고**
DNS 검사 도구는 `dig` 명령의 응답 섹션에서 예상할 수 있는 내용과 유사한 정보를 반환합니다. 따라서 상위 이름 서버를 가리키는 하위 도메인의 이름 서버에 대해 쿼리해도 해당 이름 서버는 반환되지 않습니다.
**Topics**
+ [확인 도구를 사용해 Amazon Route 53가 DNS 쿼리에 응답하는 방식 확인](#dns-test-how-route-53-responds)
+ [확인 도구를 이용해 특정 IP 주소에서 쿼리 시뮬레이션(지리 위치 및 지연 시간 레코드만 해당)](#dns-test-simulate-requests)
## 확인 도구를 사용해 Amazon Route 53가 DNS 쿼리에 응답하는 방식 확인
도구를 사용하여 레코드의 DNS 쿼리에 대한 대응으로 Amazon Route 53가 반환하는 응답을 확인할 수 있습니다.
**확인 도구를 사용하여 Route 53가 DNS 쿼리에 응답하는 방식을 확인하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. [**Hosted Zones**] 페이지에서 호스팅 영역의 이름을 선택합니다. 콘솔에 해당 호스팅 영역의 레코드 목록이 표시됩니다.
1. **Route 53의 응답 확인(Check response from Route 53)** 페이지로 바로 이동하려면 **레코드 테스트(Test record)**를 선택합니다.
1. 다음 값을 지정하세요.
+ 호스팅 영역의 이름을 제외한 레코드의 이름입니다. 예를 들어, **www.example.com**을 확인하려면 **www**를 입력합니다. **example.com**을 확인하려면 **레코드 이름** 필드를 비워 둡니다.
+ 확인하려는 레코드의 유형(예: **A** 또는 **CNAME**)입니다.
1. [**Get Response **]를 선택합니다.
1. **Route 53에서 반환된 응답(Response returned by Route 53)** 섹션에는 다음 값이 포함됩니다.
**DNS 응답 코드**
쿼리가 유효한지 여부를 나타내는 코드입니다. 가장 일반적인 응답 코드는 [**NOERROR**]이며, 이는 쿼리가 유효한 상태임을 의미합니다. 응답이 유효하지 않은 경우에는 Route 53가 이유를 설명하는 응답 코드를 반환합니다. 가능한 응답 코드의 목록을 보려면 IANA 웹 사이트에서 [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) 단원을 참조하십시오.
**프로토콜**
Amazon Route 53이 쿼리에 응답하는 데 사용한 프로토콜은 [**UDP**] 또는 [**TCP**]입니다.
**Route 53에서 반환된 응답**
Route 53가 웹 애플리케이션에 반환하는 값입니다. 값은 다음 중 하나입니다.
+ 별칭이 아닌 레코드의 경우 응답에 레코드에 있는 값이 포함됩니다.
+ 이름과 유형이 동일한 여러 레코드의 경우(가중치, 지연 시간, 지리 위치 및 장애 조치 포함) 응답에 요청을 기반으로 적절한 레코드의 값이 포함됩니다.
+ 다른 레코드 이외의 AWS 리소스를 참조하는 별칭 레코드의 경우 응답에는 AWS 리소스 유형에 따라 리소스의 IP 주소 또는 도메인 이름이 포함됩니다.
+ 다른 레코드를 참조하는 별칭 레코드의 경우 응답에 참조된 레코드의 값이 포함됩니다.
## 확인 도구를 이용해 특정 IP 주소에서 쿼리 시뮬레이션(지리 위치 및 지연 시간 레코드만 해당)
지연 시간 또는 지리 위치 레코드를 생성한 경우 확인 도구를 사용하여 DNS 해석기 및 클라이언트의 IP 주소에서 쿼리를 시뮬레이션할 수 있습니다.
**확인 도구를 사용하여 지정된 IP 주소에서 쿼리를 시뮬레이션하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. [**Hosted Zones**] 페이지에서 호스팅 영역의 이름을 선택합니다. 콘솔에 해당 호스팅 영역의 레코드 목록이 표시됩니다.
1. [**Check response from Route 53**] 페이지로 바로 이동하려면 [**Test record set**]를 선택합니다.
특정 레코드에 대한 [**Check response from Route 53**] 페이지로 이동하려면 해당 레코드의 확인란을 선택하고 [**Test record set**]를 선택합니다.
1. 먼저 레코드를 선택하지 않고 **레코드 세트 테스트**를 선택한 경우, 다음 값을 지정합니다.
+ 호스팅 영역의 이름을 제외한 레코드의 이름입니다. 예를 들어, **www.example.com**을 확인하려면 **www**를 입력합니다. **example.com**을 확인하려면 **레코드 이름** 필드를 비워 둡니다.
+ 확인하려는 레코드의 유형(예: **A** 또는 **CNAME**)입니다.
1. 해당하는 값을 지정합니다.
**해석기 IP 주소**
클라이언트가 요청할 때 사용하는 DNS 해석기의 위치를 시뮬레이션할 IPv4 또는 IPv6 주소를 지정합니다. 이는 지연 시간 및 지리 위치 레코드를 테스트하는 데 유용합니다. 이 값을 생략하면 도구는 AWS 미국 동부(버지니아 북부) 리전(us-east-1)에 있는 DNS 해석기의 IP 주소를 사용합니다.
**EDNS0 클라이언트 서브넷 IP**
해석기가 EDNS0을 지원하는 경우 해당 지리적 위치의 IP 주소로 클라이언트 서브넷 IP 주소를 입력합니다(예: **192.0.2.0** 또는 **2001:db8:85a3::8a2e:370:7334**).
**서브넷 마스크**
[**EDNS0 client subnet IP**]의 IP 주소를 지정하는 경우 확인 도구가 DNS 쿼리에 포함하도록 원하는 IP 주소의 비트 수를 선택적으로 지정할 수 있습니다. 예를 들어, **EDNS0 클라이언트 서브넷 IP(EDNS0 client subnet IP)**로 **192.0.2.44**을 지정하고 **서브넷 마스크(Subnet mask)**로 **24**를 지정하는 경우 확인 도구는 **192.0.2.0/24**의 쿼리를 시뮬레이션합니다. 기본값은 IPv4 주소의 경우 24비트, IPv6 주소의 경우 비트입니다.
1. [**Get Response **]를 선택합니다.
1. **Route 53에서 반환된 응답(Response returned by Route 53)** 섹션에는 다음 값이 포함됩니다.
**Route 53에 전송되는 DNS 쿼리**
확인 도구가 Route 53로 전송한 [Bind 형식](https://en.wikipedia.org/wiki/Zone_file)의 쿼리입니다. 이는 웹 애플리케이션에서 쿼리를 보내는 데 사용하는 동일한 형식입니다. 일반적으로 세 가지 값은 레코드의 이름, [**IN**](인터넷용) 및 레코드의 유형입니다.
**DNS 응답 코드**
쿼리가 유효한지 여부를 나타내는 코드입니다. 가장 일반적인 응답 코드는 [**NOERROR**]이며, 이는 쿼리가 유효한 상태임을 의미합니다. 응답이 유효하지 않은 경우에는 Route 53가 이유를 설명하는 응답 코드를 반환합니다. 가능한 응답 코드의 목록을 보려면 IANA 웹 사이트에서 [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) 단원을 참조하십시오.
**프로토콜**
Amazon Route 53이 쿼리에 응답하는 데 사용한 프로토콜은 [**UDP**] 또는 [**TCP**]입니다.
**Route 53에서 반환된 응답**
Route 53가 웹 애플리케이션에 반환하는 값입니다. 값은 다음 중 하나입니다.
+ 별칭이 아닌 레코드의 경우 응답에 레코드에 있는 값이 포함됩니다.
+ 이름과 유형이 동일한 여러 레코드의 경우(가중치, 지연 시간, 지리 위치 및 장애 조치 포함) 응답에 요청을 기반으로 적절한 레코드의 값이 포함됩니다.
+ 다른 레코드 이외의 AWS 리소스를 참조하는 별칭 레코드의 경우 응답에는 AWS 리소스 유형에 따라 리소스의 IP 주소 또는 도메인 이름이 포함됩니다.
+ 다른 레코드를 참조하는 별칭 레코드의 경우 응답에 참조된 레코드의 값이 포함됩니다.
# 화이트 레이블 이름 서버 구성
각 Amazon Route 53 호스팅 영역은 4개의 이름 서버(합쳐서 위임 세트라고 함)와 연결되어 있습니다. 기본적으로 이름 서버에는 ns-2048.awsdns-64.com과 같은 이름이 있습니다. 이름 서버의 도메인 이름이 호스팅 영역의 도메인 이름과 동일하기를 원하는 경우(예: ns1.example.com), 베니티 이름 서버 또는 프라이빗 이름 서버라고도 하는 화이트 레이블 이름 서버를 구성하면 됩니다.
다음 절차에서는 여러 도메인에 재사용할 수 있는 네 개의 화이트 레이블 이름 서버 한 세트를 구성하는 방법을 설명합니다. 예를 들어, example.com, example.org, example.net 도메인을 소유하고 있다고 가정해 봅시다. 이 절차를 통해 example.com에 대한 화이트 레이블 이름 서버를 구성하고 이를 example.org 및 example.net에 재사용할 수 있습니다.
**Topics**
+ [1단계: 재사용 가능한 Route 53 위임 세트 만들기](#white-label-name-servers-create-reusable-delegation-set)
+ [2단계: Amazon Route 53 호스팅 영역을 생성 또는 재생성하고 NS 및 SOA 레코드에 대한 TTL 변경](#white-label-name-servers-create-hosted-zones)
+ [3단계: 호스팅 영역의 레코드 다시 생성](#white-label-name-servers-create-resource-record-sets)
+ [4단계: IP 주소 받기](#white-label-name-servers-get-ip-addresses)
+ [5단계: 화이트 레이블 이름 서버의 레코드 생성](#white-label-name-servers-create-white-label-resource-record-sets)
+ [6단계: NS 및 SOA 레코드 업데이트](#white-label-name-servers-update-ns-soa-records)
+ [7단계: 글루 레코드 생성 및 등록 대행자 이름 서버 변경](#white-label-name-servers-create-glue-records)
+ [8단계: 웹 사이트 또는 애플리케이션의 트래픽 모니터링](#white-label-name-servers-monitor-traffic)
+ [9단계: TTL을 원래 값으로 다시 변경](#white-label-name-servers-change-ttls-back)
+ [10단계: (선택 사항) 리커시브 DNS 서비스에 연락](#white-label-name-servers-contact-recursive-dns-services)
## 1단계: 재사용 가능한 Route 53 위임 세트 만들기
흰색 레이블 이름 서버는 Route 53 재사용 가능한 위임 세트와 연결됩니다. 호스팅 영역과 재사용 가능한 위임 세트가 동일한 AWS 계정에서 생성된 경우에만 호스팅 영역에 화이트 레이블 이름 서버를 사용할 수 있습니다.
재사용 가능한 위임 세트를 생성하려면 Route 53 API, AWS CLI 또는 AWS SDKs. 자세한 내용은 다음 설명서를 참조하세요.
+ **Route 53 API** - *Amazon Route 53 API 참조*의 [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html) 참조
+ **AWS CLI** - *AWS CLI 명령 참조*의 [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html) 참조
+ **AWS SDKs** 설명서 페이지에서 해당 SDK [AWS 설명서를](https://docs.aws.amazon.com/) 참조하세요.
## 2단계: Amazon Route 53 호스팅 영역을 생성 또는 재생성하고 NS 및 SOA 레코드에 대한 TTL 변경
Amazon Route 53 호스팅 영역 생성 또는 재생성:
+ **화이트 레이블 이름 서버를 사용할 도메인의 DNS 서비스로 현재 Route 53를 사용하고 있지 않은 경우** - 호스팅 영역을 생성하고 이전 단계에서 호스팅 영역별로 생성한 재사용 가능한 위임 세트를 지정합니다. 자세한 내용은 *Amazon Route 53 API 참조*의 [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)을 참조하세요.
+ **화이트 레이블 이름 서버를 사용할 도메인의 DNS 서비스로 Route 53를 사용하고 있는 경우** - 화이트 레이블 이름 서버를 사용할 호스팅 영역을 다시 생성한 다음, 이전 단계에서 호스팅 영역별로 생성한 재사용 가능한 위임 세트를 지정해야 합니다.
**중요**
기존 호스팅 영역과 연결된 이름 서버는 변경할 수 없습니다. 재사용 가능한 위임 세트를 호스팅 영역과 연결하려면 호스팅 영역을 생성해야 합니다.
호스팅 영역을 생성하는 경우, 해당 도메인의 리소스에 액세스를 시도하기 전에 각 호스팅 영역에서 다음 TTL 값을 변경합니다.
+ 호스팅 영역에 대한 NS 레코드의 TTL을 60초 이하로 변경합니다.
+ 호스팅 영역에 대한 SOA 레코드의 최소 TTL을 60초 이하로 변경합니다. 이는 SOA 레코드의 마지막 값입니다.
등록자에게 실수로 화이트 레이블 이름 서버에 대한 잘못된 IP 주소를 제공하면, 웹 사이트를 사용할 수 없게 되며 문제가 해결된 후에도 TTL 기간 동안은 사용할 수 없습니다. TTL을 낮게 설정하면 웹 사이트를 사용하지 못하는 기간을 단축할 수 있습니다.
호스팅 영역을 생성하고 호스팅 영역의 이름 서버에 대해 재사용 가능한 위임 세트를 지정하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)을 참조하세요.
## 3단계: 호스팅 영역의 레코드 다시 생성
2단계에서 생성한 호스팅 영역에 레코드 생성:
+ **도메인의 DNS 서비스를 Amazon Route 53로 마이그레이션하는 경우** - 기존 레코드에 대한 정보를 가져와서 레코드를 생성할 수 있습니다. 자세한 내용은 [영역 파일을 가져와 레코드 생성](resource-record-sets-creating-import.md) 섹션을 참조하세요.
+ **화이트 레이블 이름 서버를 사용할 수 있도록 기존 호스팅 영역을 대체하는 경우** - 새 호스팅 영역에서 현재 호스팅 영역에 나타나는 레코드를 다시 생성합니다. Route 53의 경우 호스팅 영역에서 레코드를 내보낼 방법이 없지만 일부 타사 공급 업체에서는 가능합니다. 그런 다음 Route 53 가져오기 기능으로 라우팅 정책이 단순하며 별칭이 아닌 레코드를 가져올 수 있습니다. 별칭 레코드 또는 라우팅 정책이 단순하지 않은 레코드는 내보냈다가 다시 가져올 수 없습니다.
Route 53 API를 사용하여 레코드를 만드는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)을 참조하세요. Route 53 콘솔을 사용하여 레코드를 생성하는 방법에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md) 섹션을 참조하세요.
## 4단계: IP 주소 받기
재사용 가능한 위임 세트에서 이름 서버의 IPv4 및 IPv6 주소를 가져온 다음, 아래 표에 입력합니다.
****
| 재사용 가능한 위임 세트의 이름 서버 이름(예: Ns-2048.awsdns-64.com) | IPv4 및 IPv6 주소 | 화이트 레이블 이름 서버에 할당할 이름(예: ns1.example.com) |
| --- | --- | --- |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
예를 들어, 재사용 가능한 위임 세트의 이름 서버 네 개가 다음과 같다고 가정해 봅시다.
+ ns-2048.awsdns-64.com
+ ns-2049.awsdns-65.net
+ ns-2050.awsdns-66.org
+ ns-2051.awsdns-67.co.uk
다음은 4개 이름 서버 중 첫 번째의 IP 주소를 가져오기 위해 실행할 Linux 및 Windows 명령입니다.
**Linux용 dig 명령**
```
% dig A ns-2048.awsdns-64.com +short
192.0.2.117
```
```
% dig AAAA ns-2048.awsdns-64.com +short
2001:db8:85a3::8a2e:370:7334
```
**Windows의 경우 nslookup 명령**
```
c:\> nslookup ns-2048.awsdns-64.com
Non-authoritative answer:
Name: ns-2048.awsdns-64.com
Addresses: 2001:db8:85a3::8a2e:370:7334
192.0.2.117
```
## 5단계: 화이트 레이블 이름 서버의 레코드 생성
화이트 레이블 이름 서버의 도메인 이름(예: ns1.example.com)과 이름이 동일한 호스팅 영역(예: example.com)에서 8개의 레코드를 생성합니다.
+ 각 화이트 레이블 이름 서버당 A 레코드 1개
+ 각 화이트 레이블 이름 서버당 AAAA 레코드 1개
**중요**
둘 이상의 호스팅 영역에 대해 동일한 화이트 레이블 이름 서버를 사용하는 경우, 다른 호스팅 영역에 대해 이 단계를 수행하지 마십시오.
각 레코드에 대해 다음 값을 지정합니다. 이전 단계에서 입력한 표를 참조하십시오.
**라우팅 정책**
**단순 라우팅(Simple routing)**을 지정합니다.
**레코드 이름**
화이트 레이블 이름 서버 중 하나에 할당할 이름입니다(예: ns1.example.com). 접두사(이 예에서는 ns1)의 경우, 도메인 이름에 유효한 모든 값을 사용할 수 있습니다.
**값/트래픽 라우팅 대상**
재사용 가능한 위임 세트의 Route 53 이름 서버 중 하나의 IPv4 또는 IPv6 주소입니다.
화이트 레이블 이름 서버에 대한 레코드를 생성할 때 잘못된 IP 주소를 지정하면, 다음 단계를 수행할 때 인터넷에서 웹 사이트 또는 웹 애플리케이션을 사용할 수 없게 됩니다. IP 주소를 즉시 수정하더라도 TTL 기간 동안에는 웹 사이트 또는 웹 애플리케이션을 사용할 수 없습니다.
**레코드 유형**
IPv4 주소에 대해 레코드를 생성하는 경우 [**A**]를 지정합니다.
IPv6 주소에 대해 레코드를 생성하는 경우 [**AAAA**]를 지정합니다.
**TTL(초)**
이 값은 DNS 해석기에서 Route 53로 또 다른 DNS 쿼리를 전달하기 전에 이 레코드의 정보를 캐싱하는 시간입니다. 이러한 레코드에 실수로 잘못된 값을 지정하는 경우 신속하게 복구할 수 있도록 초기 값을 60초 이하로 지정하는 것이 좋습니다.
## 6단계: NS 및 SOA 레코드 업데이트
화이트 레이블 이름 서버를 사용할 호스팅 영역의 SOA 및 NS 레코드를 업데이트합니다. 한 번에 호스팅 영역 한 개와 해당 도메인에 대해 6-8단계를 수행한 다음, 다른 호스팅 영역과 도메인에 대해 이를 반복합니다.
**중요**
화이트 레이블 이름 서버(예: ns1.example.com)와 도메인 이름이 동일한 Amazon Route 53 호스팅 영역(예: example.com)부터 시작합니다.
1. Route 53 이름 서버의 이름을 화이트 레벨 이름 서버 중 하나의 이름으로 바꿔서 SOA 레코드를 업데이트합니다.
**예제**
Route 53 이름 서버의 이름을
`ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60`
화이트 레벨 이름 서버 중 하나의 이름으로 바꿉니다.
`ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60`
**참고**
[2단계: Amazon Route 53 호스팅 영역을 생성 또는 재생성하고 NS 및 SOA 레코드에 대한 TTL 변경](#white-label-name-servers-create-hosted-zones)에서 마지막 값인 최소 TTL(Time To Live)을 변경했습니다.
Route 53 콘솔을 사용하여 레코드를 업데이트하는 방법에 대한 자세한 내용은 [레코드 편집](resource-record-sets-editing.md) 섹션을 참조하세요.
1. NS 레코드에서 도메인에 대한 현재 이름 서버의 이름을 기록해 두고, 필요할 경우 되돌릴 수 있도록 하십시오.
1. NS 레코드를 업데이트합니다. Route 53 이름 서버의 이름을 화이트 레이블 이름 서버 4개의 이름(예: `ns1.example.com`, `ns2.example.com`, `ns3.example.com` 및 `ns4.example.com`)으로 바꿉니다.
## 7단계: 글루 레코드 생성 및 등록 대행자 이름 서버 변경
등록자가 제공한 방법을 사용하여 다음과 같이 글루 레코드를 생성하고 등록자의 이름 서버를 변경합니다.
1. 글루 레코드를 추가하는 방법:
+ **화이트 레이블 이름 서버와 도메인 이름이 동일한 도메인을 업데이트하는 경우** - 이름 및 IP 주소가 4단계에서 얻은 값과 일치하는 글루 레코드 4개를 생성합니다. 해당 글루 레코드에 화이트 레이블 이름 서버의 IPv4 및 IPv6 주소를 모두 포함시킵니다. 예를 들면 다음과 같습니다.
**ns1.example.com** – IP 주소 = 192.0.2.117 및 2001:db8:85a3::8a2e:370:7334
등록자는 글루 레코드에 대해 다양한 용어를 사용합니다. 이를 새로운 이름 서버 또는 이와 유사한 대상을 등록하는 것으로 볼 수도 있습니다.
+ **또 다른 도메인을 업데이트하는 경우** – Route 53이 DNS 서비스인 경우 먼저 항목의 단계를 완료하고 도메인 이름과 일치하는 글루 레코드를 만들어야 합니다. 그런 다음 이 절차의 2단계로 건너뜁니다.
1. 도메인의 이름 서버를 화이트 레이블 이름 서버의 이름으로 변경합니다.
Amazon Route 53를 DNS 서비스로 사용하는 경우, [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 섹션을 참조하세요.
## 8단계: 웹 사이트 또는 애플리케이션의 트래픽 모니터링
7단계에서 글루 레코드를 생성하고 이름 서버를 변경한 웹 사이트 또는 애플리케이션의 트래픽을 다음과 같이 모니터링합니다.
+ **트래픽이 중지된 경우** - 등록 기관이 제공한 방법을 사용하여 도메인의 이름 서버를 이전 Route 53 이름 서버로 다시 변경합니다. 이는 6b단계에서 기록해 둔 이름 서버입니다. 그런 다음 문제를 알아냅니다.
+ **트래픽에 영향이 없는 경우** - 동일한 화이트 레이블 이름 서버를 사용할 나머지 호스팅 영역에 대해 6\$18단계를 반복합니다.
## 9단계: TTL을 원래 값으로 다시 변경
현재 화이트 레이블 이름 서버를 사용 중인 모든 호스팅 영역에 대해 다음 값을 변경합니다.
+ 호스팅 영역에 대한 NS 레코드의 TTL을 더 일반적인 NS 레코드 값으로 변경합니다(예: 172800초(2일)).
+ 호스팅 영역에 대한 SOA 레코드의 최소 TTL을 더 일반적인 SOA 레코드 값으로 변경합니다(예: 900초). 이는 SOA 레코드의 마지막 값입니다.
## 10단계: (선택 사항) 리커시브 DNS 서비스에 연락
*선택 사항* - Amazon Route 53 지리적 위치 라우팅을 사용하는 경우, EDNS0의 edns-client-subnet 확장을 지원하는 리커시브 DNS 서비스에 연락하여 화이트 레이블 이름 서버의 이름을 알려 주세요. 이를 통해 이러한 DNS 서비스에서 쿼리가 시작된 대략적인 지리적 위치에 기반한 최적의 Route 53 위치로 DNS 쿼리를 계속 라우팅할 수 있습니다.
# Amazon Route 53에서 퍼블릭 호스팅 영역에 대해 생성하는 NS 및 SOA 레코드
Amazon Route 53는 생성하는 각 퍼블릭 호스팅 영역에 대해 NS(이름 서버) 레코드 및 SOA(권한 시작) 레코드를 자동으로 생성합니다. 이러한 레코드는 거의 변경할 필요가 없습니다.
**Topics**
+ [NS(이름 서버) 레코드](#NSrecords)
+ [SOA(권한 시작) 레코드](#SOArecords)
## NS(이름 서버) 레코드
Amazon Route 53는 호스팅 영역과 이름이 동일한 NS(이름 서버) 레코드를 자동으로 생성하고, 호스팅 영역에 대한 신뢰할 수 있는 이름 서버 네 개를 나열합니다. 드문 경우를 제외하고 이 레코드에서 이름 서버를 추가, 변경 또는 삭제하지 않는 것이 좋습니다.
다음 예는 Route 53 이름 서버의 이름 형식을 보여줍니다(이것은 예시일 뿐이므로 등록자의 이름 서버 레코드를 업데이트할 때 사용하면 안 됩니다).
+ *ns-2048.awsdns-64.com*
+ *ns-2049.awsdns-65.net*
+ *ns-2050.awsdns-66.org*
+ *ns-2051.awsdns-67.co.uk*
호스팅 영역의 이름 서버 목록을 가져오려면:
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted Zones)**을 클릭합니다.
1. **호스팅 영역(Hosted zones)** 페이지에서 호스팅 영역의 (이름 대신) 라디오 버튼을 선택한 다음 **세부 정보 보기(View details)**를 선택합니다.
1. 호스팅 영역에 대한 세부 정보 페이지에서 **호스팅 영역 세부 정보(Hosted zone details)**를 선택합니다.
1. **이름 서버(Name servers)**에 나열된 서버 4개의 이름을 기록합니다.
다른 DNS 서비스 공급자에서 Route 53로의 DNS 서비스 마이그레이션에 대한 자세한 내용은 [Amazon Route 53를 기존 도메인에 대한 DNS 서비스로 설정Route 53을 기존 도메인에 대한 DNS 서비스로 설정](MigratingDNS.md) 섹션을 참조하세요.
## SOA(권한 시작) 레코드
SOA(권한 시작) 레코드는 도메인에 대한 기본 DNS 정보를 식별합니다. 예:
```
1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400
```
SOA 레코드에는 다음 요소가 포함되어 있습니다.
+ SOA 레코드를 생성한 Route 53 이름 서버(예: `ns-2048.awsdns-64.net`)입니다.
+ 관리자의 이메일 주소입니다. `@` 기호는 마침표로 대체됩니다(예: `hostmaster.example.com`). 기본 값은 모니터링되지 않는 amazon.com 이메일 주소입니다.
+ 호스팅 영역에서 레코드를 업데이트할 때마다 선택적으로 증가시킬 수 있는 일련번호입니다. Route 53는 자동으로 숫자를 증가시키지 않습니다. (일련 번호는 부 DNS를 지원하는 DNS 서비스에 사용됩니다.) 이 예시에서 이 값은 `1`입니다.
+ 부 DNS 서버에서 주 DNS 서버의 SOA 레코드를 쿼리하여 변경 내용을 확인하기 전에 기다리는 새로 고침 시간(초). 이 예시에서 이 값은 `7200`입니다.
+ 부 서버에서 실패한 영역 전송을 재시도하기 전에 기다리는 재시도 간격(초). 일반적으로 재시도 시간은 새로 고침 시간보다 짧습니다. 이 예시에서 이 값은 `900`(15분)입니다.
+ 부 서버에서 영역 전송을 완료하기 위해 시도할 수 있는 시간(초). 영역이 성공적으로 전송되기 전에 이 시간이 경과하면 부 서버에서 데이터가 오래되어 신뢰할 수 없다고 간주하여 쿼리에 응답하는 것을 중지합니다. 이 예시에서 이 값은 `1209600`(2주)입니다.
+ 최소 TTL(Time To Live). 이 값은 재귀 해석기에서 다음 응답을 Route 53에서 캐싱해야 하는 시간을 정의하는 데 도움이 됩니다.
**NXDOMAIN**
example.com과 같이 DNS 쿼리에 지정된 이름을 가진 유형의 레코드가 없습니다. zenith.example.com과 같이 DNS 쿼리에 지정된 이름의 하위 레코드도 없습니다.
**NODATA**
DNS 쿼리에 지정된 이름을 가진 레코드가 하나 이상 있지만 이러한 레코드 중 DNS 쿼리에 지정된 유형(예: A)은 없습니다.
DNS 해석기에서 NXDOMAIN 또는 NODATA 응답을 캐싱하면 이를 *음성 캐싱*이라고 합니다.
음성 캐싱의 기간은 다음 값보다 짧습니다.
+ 이 값은 SOA 레코드의 최소 TTL입니다. 이 예에서 이 값은 `86400`(하루)입니다.
+ SOA 레코드에 대한 TTL의 값입니다. 기본 값은 900초입니다. 이 값의 변경에 대한 자세한 내용은 다음([레코드 편집](resource-record-sets-editing.md))을 참조하십시오.
Route 53에서 NXDOMAIN 또는 NODATA 응답(부정 응답)을 사용하여 DNS 쿼리에 응답하면 표준 쿼리의 요율로 비용이 청구됩니다. ([Amazon Route 53 가격](https://aws.amazon.com/route53/pricing/)에서 “쿼리”를 참조하세요. 부정 응답 비용이 염려되는 경우 한 가지 옵션은 SOA 레코드의 TTL, SOA 레코드의 최소 TTL(이 값) 또는 둘 다 변경하는 것입니다. 전체 호스팅 영역에 대한 부정 응답에 적용되는 이러한 TTL을 늘리면 긍정적인 효과와 부정적인 효과를 모두 가질 수 있습니다.
+ 인터넷의 DNS 해석기에 더 오랜 기간 동안 존재하지 않는 레코드를 캐싱하므로 Route 53에 전달되는 쿼리 수가 감소합니다. 이렇게 하면 DNS 쿼리에 대한 Route 53 요금이 감소합니다.
+ 그러나 유효한 레코드를 잘못 삭제한 후 나중에 다시 생성하면 DNS 해석기에서 더 오랜 기간 동안 부정 응답(이 레코드는 존재하지 않음)을 캐싱합니다. 이렇게 하면 고객 또는 사용자가 acme.example.com의 웹 서버와 같은 해당 리소스에 도달할 수 없는 시간이 길어집니다.
**루트 53에서 SOA 레코드를 찾으려면 다음을 수행합니다.**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. 레코드를 보려는 도메인의 링크된 이름을 선택합니다.
1. **레코드(Records)** 섹션에서 나열된 모든 레코드를 볼 수 있으며 레코드를 필터링하여 SOA 값을 찾을 수 있습니다.
# 퍼블릭 DNS 레코드 관리를 위한 가속화된 복구 활성화
퍼블릭 DNS 레코드 관리를 위한 Route 53 가속화 복구는 미국 동부(버지니아 북부) 리전에서 서비스를 사용할 수 없는 경우 60분 Recovery Time Objective(RTO)를 달성하도록 설계되었습니다. Route 53 퍼블릭 호스팅 영역에서 활성화하면가 미국 동부(버지니아 북부) 리전의 작업이 손상된 것을 AWS 감지한 후 약 60분 이내에 퍼블릭 호스팅 영역의 DNS 레코드 변경을 재개할 수 있습니다.
**중요**
가속화된 복구는 퍼블릭 호스팅 영역에서만 사용할 수 있습니다. 프라이빗 호스팅 영역은 지원되지 않습니다.
**참고**
Route 53 데이터 영역의 DNS 쿼리 확인은 리전 서비스 장애 발생 시에도 정상적으로 작동합니다. 데이터 영역과 컨트롤 플레인 작업에 대한 이해는 [Route 53의 복원력을](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) 참조하세요.
**Topics**
+ [퍼블릭 DNS 레코드의 빠른 복구 작동 방식](#accelerated-recovery-how-it-works)
+ [장애 조치 후 DNS 변경 사항 다시 제출](#accelerated-recovery-resubmit)
+ [미국 동부(버지니아 북부) 리전으로 장애 복구](#accelerated-recovery-failback)
+ [추가 고려 사항](#accelerated-recovery-considerations)
+ [퍼블릭 DNS 레코드 관리를 위해 가속화된 복구를 활성화하는 방법](#accelerated-recovery-enable)
## 퍼블릭 DNS 레코드의 빠른 복구 작동 방식
가속화된 복구가 활성화되면 Route 53는 미국 서부(오레곤) 리전에 퍼블릭 호스팅 영역의 사본을 유지합니다. 미국 동부(버지니아 북부) 리전의 서비스를 장기간 사용할 수 없게 되면 Route 53는 60분 이내에 장애 조치를 실행하여 가속화된 복구가 활성화된 퍼블릭 호스팅 영역에 대한 컨트롤 플레인 작업을 미국 서부(오레곤) 리전으로 자동 리디렉션합니다. 그런 다음 CLI, SDK 및 API를 통해 프로그래밍 방식으로 DNS를 계속 변경할 수 있습니다. 장애 조치 중에는 제한된 API 메서드 세트를 사용할 수 있습니다. 자세한 내용은 "추가 고려 사항" 섹션을 참조하세요. 리전이 복구되면 Route 53는 페일백 절차를 실행하여 컨트롤 플레인 작업을 자동으로 미국 동부(버지니아 북부) 리전으로 다시 전달합니다.
**참고**
미국 동부(버지니아 북부) 리전에 장애가 발생하기 전에 먼저 퍼블릭 호스팅 영역에서 퍼블릭 DNS 레코드를 관리하기 위한 가속화된 복구를 활성화해야 합니다. 이 작업은 콘솔, CLI, SDK 또는 API를 통해 수행할 수 있습니다(아래 페이지에서 *퍼블릭 DNS 레코드 관리를 위해 가속화된 복구를 활성화하는 방법* 섹션 참조). 장애 조치가 발생한 후에는 퍼블릭 DNS 레코드 관리에 대해 가속화된 복구를 활성화할 수 없습니다.
## 장애 조치 후 DNS 변경 사항 다시 제출
정상적인 조건에서는 복구 가속화가 활성화된 퍼블릭 호스팅 영역의 변경 사항이 미국 동부(버지니아 북부) 리전에서 수락된 다음 미국 서부(오레곤) 리전에 성공적으로 복제됩니다. 그러나 미국 동부(버지니아 북부) 리전에서 서비스 중단이 발생하는 경우 일부 변경 사항은 미국 동부(버지니아 북부) 리전에서 수락될 수 있지만 미국 서부(오레곤) 리전에는 복제되지 않을 수 있습니다. 이러한 진행 중인 변경 사항을 "연속 변경"이라고 합니다. 장애 조치가 완료되면 Route 53는 DNS 워크플로를 재개하기 전에 복잡한 변경 사항을 다시 제출할 것을 권장합니다. API를 사용하거나 아래에 설명된 AWS CloudFormation을 사용하여이 작업을 수행할 수 있습니다.
### API를 사용하여 DNS 변경 사항 추적 및 제출
Route 53 API, AWS CLI 또는 AWS SDKs 사용하여 DNS 레코드를 관리하는 경우 각각 [ChangeResourceRecordSets API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) 및 [GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)를 사용하여 DNS 변경 사항을 제출하고 추적해야 합니다.
ChangeResourceRecordSets API를 사용하여 DNS를 변경하면 Route 53는 변경 사항에 대한 식별자(ID)를 반환합니다(변경 응답 객체 세부 정보는 [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html) 참조). GetChange API에 대한 후속 요청에서이 ID를 제공하고 변경 상태를 관찰할 수 있습니다. INSYNC 상태의 DNS 변경 사항은 미국 서부(오레곤) 리전에 복제되어 모든 Route 53 DNS 서버에 전파되었습니다. 장애 조치 전후에 이러한 변경 사항에 대해 수행해야 하는 추가 작업은 없습니다. 그러나 미국 동부(버지니아 북부) 리전에 장애가 있는 경우 GetChange는 PENDING을 반환할 수 있으며, 이는 변경 사항이 미국 서부(오레곤) 리전에 복제되지 않았을 수 있음을 나타냅니다. 이 경우 장애 조치가 완료되면 GetChange는 NoSuchChange를 반환하여 Route 53가이 DNS 변경을 복제할 수 없음을 나타냅니다. 따라서 장애 조치 후 이러한 중단된 DNS 변경 사항을 안전하게 무시하고 새 DNS 변경 사항으로 다시 제출할 수 있습니다. Route 53가 AWS 상태 대시보드에 메시지를 게시할 때 장애 조치 프로세스가 완료되었음을 알 수 있습니다.
### AWS CloudFormation을 사용하여 변경 사항 추적 및 제출
AWS CloudFormation은 GetChange API를 사용하여 DNS 변경에 대한 복제 상태를 자동으로 추적하고 DNS 변경 사항이 INSYNC로 확인된 후에만 업데이트를 완료합니다. CloudFormation을 사용하여 DNS 레코드를 관리하고 미국 동부(버지니아 북부) 리전을 사용할 수 없게 되면 CloudFormation을 사용하여 수행하는 작업이 사용할 수 없는 기간 동안 성공적으로 완료되지 않습니다. 그러나 Route 53 장애 조치 프로세스가 완료되면 동일한 작업을 다시 시도하여 CloudFormation에서 DNS 변경 사항을 다시 제출할 수 있습니다.
## 미국 동부(버지니아 북부) 리전으로 장애 복구
Route 53는 리전이 복구되면 퍼블릭 호스팅 영역에 대한 컨트롤 플레인 작업을 미국 동부(버지니아 북부) 리전으로 페일백합니다. 이 프로세스 중에는 복잡한 변경 사항이 발생하지 않으므로 장애 복구 중에는 DNS 변경 사항을 다시 제출할 필요가 없습니다.
## 추가 고려 사항
가속화된 복구 기능과 관련하여 알아야 할 몇 가지 추가 고려 사항이 있습니다.
1. 장애 조치 중에는 새 호스팅 영역을 생성하거나, 기존 호스팅 영역을 삭제하거나, DNSSEC 서명을 활성화하거나, DNSSEC 서명을 비활성화할 수 없습니다.
1. AWS PrivateLink 연결은 장애 조치 후에는 작동하지 않지만 미국 동부(버지니아 북부) 리전으로 장애 복구한 후에는 다시 작동합니다.
1. [CloudFront 고정 요금제는](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html) 현재 지원되지 않습니다.
1. 가속화된 복구가 활성화된 호스팅 영역은 삭제할 수 없습니다. 호스팅 영역을 삭제하기 전에 가속화된 복구를 비활성화해야 합니다.
1. 장애 조치 중에는 가속화된 복구가 활성화된 퍼블릭 호스팅 영역에 대해 다음 API 메서드가 계속 지원됩니다. 그러나 다른 모든 Route 53 API 메서드는 장애 복구가 발생할 때까지 작동하지 않습니다.
+ `ChangeResourceRecordSets`
+ `GetChange`
+ `GetGeoLocation`
+ `GetHostedZone`
+ `GetHostedZoneCount`
+ `GetHostedZoneLimit`
+ `GetReusableDelegationSet`
+ `GetReusableDelegationSetLimit`
+ `ListGeoLocations`
+ `ListHostedZones`
+ `ListHostedZonesByName`
+ `ListResourceRecordSets`
+ `ListReusableDelegationSets`
## 퍼블릭 DNS 레코드 관리를 위해 가속화된 복구를 활성화하는 방법
Route 53 콘솔, API, CLI 또는 SDK를 사용하여 퍼블릭 DNS 레코드 관리를 위한 빠른 복구를 활성화할 수 있습니다. 빠른 복구를 활성화하는 데 걸리는 시간은 퍼블릭 호스팅 영역의 크기 및 기타 요인에 따라 달라집니다. 최대 몇 시간이 걸릴 수 있도록 가속화된 복구를 활성화하는 프로세스를 계획해야 합니다. 퍼블릭 호스팅 영역의 가속화된 복구 탭에서 또는 `GetHostedZone` API를 통해 활성화 프로세스의 상태를 확인할 수 있습니다. 프로세스가 완료되면 DNS 변경 사항이 수락되지 않는 짧은 기간이 최대 몇 분 동안 지속됩니다. 완료되면 DNS 변경이 정상적으로 진행될 수 있습니다.
**Route 53 콘솔을 사용하여 가속화된 복구를 활성화 및 비활성화하려면**
1. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. 가속화된 복구를 활성화할 퍼블릭 호스팅 영역을 선택합니다.
1. **가속화된 복구** 탭에서 **활성화**를 선택합니다.
1. **변경 사항 저장**을 선택합니다.
1. 호스팅 영역 상태를 모니터링합니다. 상태는 설정 중 **가속화된 복구 활성화**를 표시하고 완료되면 **활성화됨**으로 변경됩니다.
위의 동일한 단계를 사용하여 가속화된 복구를 비활성화할 수 있지만 대신 **비활성화**를 선택할 수 있습니다.
활성화하는 CLI 예제
```
aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789
```
비활성화하는 CLI 예제
```
aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789
```