기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Route 53을 DNS 서비스로 구성
Amazon Route 53를 도메인의 DNS 서비스(예: example.com)로 사용할 수 있습니다. Route 53를 DNS 서비스로 사용할 경우, www.example.com과 같은 친숙한 도메인 이름을 컴퓨터 간 연결에 사용되는 192.0.2.1 등 숫자 IP 주소로 변환하여 인터넷 트래픽을 웹 사이트로 라우팅합니다. 사용자가 브라우저에 도메인 이름을 입력하거나 이메일을 보내면 DNS 쿼리가 Route 53로 전달되며 이에 따라 적절한 값으로 응답합니다. 예를 들어, Route 53가 example.com 웹 서버의 IP 주소를 사용하여 응답할 수 있습니다.
**DNS 호스팅과 도메인 등록 비교**
이 장에서는 *DNS 호스팅 전용*으로 Route 53를 사용하는 방법을 다룹니다. 즉, 도메인 등록은 현재 등록 기관에 유지되며 도메인 갱신에 대한 비용을 계속 지불하게 됩니다. Route 53는 DNS 설정을 관리하고 도메인에 대한 DNS 쿼리를 처리하는 작업만 수행합니다.
도메인 등록도 Route 53로 이전하려면(Route 53를 등록 기관 및 DNS 서비스로 설정) [도메인 이전을 위한 이전 전 체크리스트](domain-transfer-checklist.md) 및 [도메인 등록을 Amazon Route 53으로 이전하기](domain-transfer-to-route-53.md) 섹션을 참조하세요.
이 장에서는 인터넷 트래픽을 적절한 곳으로 라우팅하기 위해 Route 53를 구성하는 방법에 대해 설명합니다. 또한 현재 다른 DNS 서비스를 사용 중인 경우 DNS 서비스를 Route 53로 마이그레이션하는 방법, 그리고 새 도메인에 대한 DNS 서비스로 Route 53를 사용하는 방법을 설명합니다.
**Topics**
+ [Amazon Route 53를 기존 도메인에 대한 DNS 서비스로 설정](MigratingDNS.md)
+ [새 도메인에 대한 DNS 라우팅 구성](dns-configuring-new-domain.md)
+ [해당 리소스로 트래픽 라우팅](dns-routing-traffic-to-resources.md)
+ [호스팅 영역 작업](hosted-zones-working-with.md)
+ [레코드 작업](rrsets-working-with.md)
+ [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md)
+ [AWS Cloud Map을 사용하여 레코드 및 상태 확인 생성](autonaming.md)
+ [DNS 제한 및 동작](DNSBehavior.md)
+ [관련 주제](dns-configuring-related-topics.md)
# Amazon Route 53를 기존 도메인에 대한 DNS 서비스로 설정
Route 53로 하나 이상의 도메인 등록을 전송하는 경우, 그리고 현재 유료 DNS 서비스를 제공하지 않는 도메인 등록 기관을 사용하는 경우 도메인을 마이그레이션하기 전에 DNS 서비스를 마이그레이션해야 합니다. 그렇지 않은 경우 도메인을 전송할 때 등록 대행자가 DNS 서비스 제공을 중단하고, 연결된 웹 사이트 및 웹 애플리케이션을 인터넷에서 사용할 수 없게 됩니다. (또한, 현재 등록 기관에서 다른 DNS 서비스 공급자로 DNS 서비스를 마이그레이션할 수 있습니다. Route 53에 등록된 도메인에 대한 DNS 서비스 공급자로서 Route 53를 사용할 필요는 없습니다.)
이 프로세스는 현재 도메인을 사용 중인지에 따라 좌우됩니다.
+ 도메인에 현재 트래픽이 발생 중인 경우(예: 사용자가 도메인 이름을 사용하여 웹 사이트를 검색하거나 웹 애플리케이션에 액세스하는 경우) [Route 53를 사용 중인 도메인에 대한 DNS 서비스로 설정](migrate-dns-domain-in-use.md) 섹션을 참조하세요.
+ 도메인에 트래픽이 전혀 또는 거의 발생하지 않는 경우 [Route 53를 비활성 도메인에 대한 DNS 서비스로 설정](migrate-dns-domain-inactive.md) 섹션을 참조하십시오.
두 옵션 모두에 대해, 전체 마이그레이션 프로세스 중에 도메인이 사용 가능 상태로 남아야 합니다. 하지만 가능성은 낮더라도 문제가 있는 경우, 첫 번째 옵션을 통해 마이그레이션을 빠르게 롤백할 수 있습니다. 두 번째 옵션을 사용하면 도메인이 이틀 정도 사용 불가능한 상태가 될 수 있습니다.
의 전문가와 연결하려면 [영업 지원을](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs) AWS방문하세요.
# Route 53를 사용 중인 도메인에 대한 DNS 서비스로 설정
현재 트래픽이 발생 중인 도메인에 대해 DNS 서비스를 Amazon Route 53로 마이그레이션하려는 경우(예: 사용자가 도메인 이름을 사용하여 웹 사이트를 검색하거나 웹 애플리케이션에 액세스하는 경우) 이 섹션의 절차를 따르세요.
**Topics**
+ [1단계: 현재 DNS 서비스 공급자로부터 현재 DNS 구성 가져오기(선택 사항이지만 권장함)](#migrate-dns-get-zone-file)
+ [2단계: 호스팅 영역 생성](#migrate-dns-create-hosted-zone)
+ [3단계: 레코드 만들기](#migrate-dns-create-records)
+ [4단계: TTL 설정 낮춤](#migrate-dns-lower-ttl)
+ [5단계: (DNSSEC를 구성한 경우) 상위 영역에서 DS 레코드 제거](#migrate-remove-ds)
+ [6단계: 이전 TTL의 만료 대기](#migrate-dns-wait-for-ttl)
+ [7단계: Route 53 이름 서버를 사용하도록 NS 레코드 업데이트](#migrate-dns-change-name-servers-with-provider)
+ [8단계: 도메인의 트래픽 모니터링](#migrate-dns-monitor-traffic)
+ [9단계: NS 레코드의 TTL을 더 높은 값으로 다시 변경](#migrate-dns-change-ttl-back)
+ [10단계: 도메인 등록을 Amazon Route 53로 이전](#migrate-dns-transfer-domain-registration)
+ [11단계: DNSSEC 서명 다시 사용(필요한 경우)](#migrate-dns-re-enable-dnssec)
## 1단계: 현재 DNS 서비스 공급자로부터 현재 DNS 구성 가져오기(선택 사항이지만 권장함)
다른 공급자로부터 Route 53로 DNS 서비스를 마이그레이션할 때 Route 53에서 현재 DNS 구성을 재현합니다. Route 53에서 도메인과 이름이 같은 호스팅 영역을 생성하고 호스팅 영역에 레코드를 생성합니다. 각각의 레코드는 지정된 도메인 또는 하위 도메인 이름에 대해 트래픽을 라우팅할 방법을 나타냅니다. 예를 들어, 웹 브라우저에 도메인 이름을 입력하는 경우 그 트래픽이 데이터 센터의 웹 서버, Amazon EC2 인스턴스, CloudFront 배포 또는 다른 위치로 라우팅되도록 하고 싶습니까?
사용하는 프로세스는 현재 DNS 구성의 복잡성에 따라 다릅니다.
+ **현재 DNS 구성이 간단한 경우** - 단지 몇몇 하위 도메인에 대해서만 인터넷 트래픽을 소수의 리소스(예: 웹 서버 또는 Amazon S3 버킷)로 라우팅하는 경우에는 Route 53 콘솔에서 몇 개의 레코드를 수동으로 생성할 수 있습니다.
+ **현재 DNS 구성이 더 복잡하고 현재 구성을 재현하기만 하려는 경우** - 현재 DNS 서비스 공급자로부터 영역 파일을 받아 Route 53로 가져올 수 있는 경우 마이그레이션을 단순화할 수 있습니다. (모든 DNS 서비스 공급자가 영역 파일을 제공하는 것은 아닙니다.) 영역 파일을 가져올 때 Route 53는 호스팅 영역에 해당 레코드를 생성하여 기존 구성을 자동으로 재현합니다.
현재 DNS 서비스 공급자에게 *영역 파일* 또는 *레코드 목록*을 얻는 방법에 대해 고객 지원을 요청해 보십시오. 필요한 영역 파일 형식에 대한 자세한 내용은 [영역 파일을 가져와 레코드 생성](resource-record-sets-creating-import.md) 단원을 참조하십시오.
+ **현재 DNS 구성이 더 복잡하고 Route 53 라우팅 기능에 관심이 있는 경우** - 다음 문서를 검토하여 다른 DNS 서비스 공급자는 제공하지 않는 Route 53 기능이 필요한지 확인하세요. 그러한 기능을 사용하고 싶으면 레코드를 수동으로 생성하거나 영역 파일을 가져온 다음에 레코드를 생성하거나 업데이트할 수 있습니다.
+ [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 에서는 CloudFront 배포 및 Amazon S3 버킷과 같은 일부 AWS 리소스로 트래픽을 무료로 라우팅하는 Route 53 별칭 레코드의 이점을 설명합니다. Amazon S3
+ [라우팅 정책 선택](routing-policy.md) 섹션에서는 예를 들어 사용자의 위치를 기반으로 하는 라우팅, 사용자와 리소스 사이의 지연 시간을 기반으로 하는 라우팅, 리소스 상태가 양호한지 여부를 기반으로 하는 라우팅, 개발자 자신이 지정하는 가중치를 기반으로 하는 리소스에 대한 라우팅과 같은 Route 53 라우팅 옵션에 대해 설명합니다.
**참고**
별칭 레코드와 복잡한 라우팅 정책을 이용하기 위해 영역 파일을 가져온 후 구성을 변경할 수도 있습니다.
영역 파일을 가져올 수 없거나 Route 53에 레코드를 수동으로 생성하려는 경우, 마이그레이션할 수 있는 레코드는 다음과 같은 레코드를 포함합니다.
+ **A(주소) 레코드** - 도메인 이름 또는 하위 도메인 이름을 해당 리소스의 IPv4 주소(예: 192.0.2.3)와 연결
+ **AAAA(주소) 레코드** - 도메인 이름 또는 하위 도메인 이름을 해당 리소스의 IPv6 주소(예: 2001:0db8:85a3:0000:0000:abcd:0001:2345)와 연결
+ **메일 서버(MX) 레코드** - 트래픽을 메일 서버로 라우팅
+ **CNAME 레코드** - 한 도메인 이름(example.net)의 트래픽을 다른 도메인 이름(example.com)으로 다시 라우팅
+ **기타 지원되는 DNS 레코드 유형에 대한 레코드** - 지원되는 레코드 유형의 목록은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 섹션을 참조하세요.
## 2단계: 호스팅 영역 생성
도메인에 대한 트래픽을 라우팅할 방법을 Amazon Route 53에 알려주려면 도메인과 이름이 같은 호스팅 영역을 생성한 다음 호스팅 영역에 레코드를 생성합니다.
**중요**
관리자 권한이 있는 도메인만 호스팅 영역을 생성할 수 있습니다. 일반적으로 도메인을 소유하고 있다는 뜻이지만 도메인 등록자용 애플리케이션을 개발하는 경우도 해당될 수 있습니다.
호스팅 영역을 생성하면 Route 53에서 해당 영역에 대한 NS(이름 서버) 레코드 및 SOA(권한 시작) 레코드를 자동으로 생성합니다. NS 레코드는 Route 53가 호스팅 영역과 연결된 4개의 이름 서버를 식별합니다. Route 53를 도메인을 위한 DNS 서비스로 설정하려면 도메인에서 이 4개의 이름 서버를 사용하도록 등록을 업데이트합니다.
**중요**
NS(이름 서버) 또는 SOA(권한 시작) 레코드를 추가로 생성하지 말고, 기존 NS 및 SOA 레코드를 삭제하지 마십시오.
**호스팅 영역 생성**
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)**를 선택한 다음 **호스팅 영역 생성(Create hosted zones)**을 선택합니다.
Route 53를 이미 사용하고 있는 경우 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택한 다음 **호스팅 영역 생성(Create hosted zones)**을 선택합니다.
1. **호스팅 영역 생성(Create hosted zones)** 창에서 도메인 이름과 메모(선택 사항)를 입력합니다. 설정에 대한 자세한 내용을 보려면 오른쪽의 도움말 패널을 선택하여 엽니다.
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하세요.
1. **유형(Type)**의 경우 **퍼블릭 호스팅 영역(Public hosted zone)**의 기본값을 허용합니다.
1. **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
## 3단계: 레코드 만들기
호스팅 영역을 생성한 후 도메인(example.com) 또는 하위 도메인(www.example.com)에 대한 트래픽을 라우팅하려는 위치를 정의하는 레코드를 호스팅 영역에 생성합니다. 예를 들어, example.com 및 www.example.com에 대한 트래픽을 Amazon EC2 인스턴스의 웹 서버로 라우팅하려는 경우 example.com과 www.example.com으로 명명된 레코드를 하나씩 만듭니다. 각 레코드에 EC2 인스턴스에 대한 IP 주소를 지정합니다.
다양한 방법으로 레코드를 생성할 수 있습니다.
**영역 파일 가져오기**
이 방법은 [1단계: 현재 DNS 서비스 공급자로부터 현재 DNS 구성 가져오기(선택 사항이지만 권장함)](#migrate-dns-get-zone-file)에서 현재 DNS 서비스를 통해 영역 파일을 받는 경우 가장 쉬운 방법입니다. Amazon Route 53에서는 별칭 레코드를 생성하거나 가중치 기반 또는 장애 조치 같은 특별한 라우팅 유형을 사용할 시점을 예측할 수 없습니다. 따라서 영역 파일을 가져오는 경우 Route 53는 간단한 라우팅 정책을 사용하여 표준 DNS 레코드를 생성합니다.
자세한 내용은 [영역 파일을 가져와 레코드 생성](resource-record-sets-creating-import.md) 단원을 참조하십시오.
**콘솔에서 레코드 개별 생성**
영역 파일을 가져오지 않고 단지 시작하기 위해 Simple의 라우팅 정책으로 몇 개의 레코드만 생성하려는 경우 Route 53 콘솔에서 레코드를 생성할 수 있습니다. 별칭 레코드와 그 밖의 레코드를 모두 생성할 수 있습니다.
자세한 내용은 다음 항목을 참조하세요.
+ [라우팅 정책 선택](routing-policy.md)
+ [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md)
+ [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md)
**프로그래밍 방식으로 레코드 생성**
AWS SDKs, AWS CLI또는 중 하나를 사용하여 레코드를 생성할 수 있습니다 AWS Tools for Windows PowerShell. 자세한 내용은 [AWS 설명서](https://docs.aws.amazon.com/)를 참조하세요.
SDK를 제공하지 AWS 않는 프로그래밍 언어를 사용하는 경우 Route 53 API를 사용할 수도 있습니다. 자세한 내용은 [Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/)를 확인하십시오.
## 4단계: TTL 설정 낮춤
레코드에 대한 TTL(Time To Live) 설정으로 DNS 해석기가 얼마나 오랫동안 레코드를 캐시하고 캐시한 정보를 사용하도록 할지 지정합니다. TTL이 만료되면 해석기가 도메인의 DNS 서비스 공급자에게 최신 정보를 획득하라는 다른 쿼리를 전송합니다.
NS 레코드에 대한 일반적인 TTL 설정은 172,800초 또는 2일입니다. NS 레코드는 Domain Name System(DNS)이 도메인에 대한 트래픽 라우팅 방법에 대한 정보를 가져오는 데 사용할 수 있는 이름 서버를 나열합니다. 현재 DNS 서비스 공급자와 Amazon Route 53를 둘 다 사용하여 NS 레코드에 대한 TTL을 낮추면 DNS를 Route 53로 마이그레이션하는 동안 문제를 발견하는 경우 도메인의 가동 중지 시간이 감소합니다. TTL을 낮추지 않을 경우 뭔가 문제가 있을 때 최장 2일간 인터넷에서 도메인에 접속할 수 없을 수 있습니다.
**참고**
일부 전체 해석기는 상위 권한 서버에 있는 NS 레코드의 TTL을 캐시할 수 있으므로 상위 권한 DNS 서버에 등록된 NS 레코드의 TTL도 줄여야 합니다.
다음 NS 레코드에 대한 TTL을 변경하는 것이 좋습니다.
+ 현재 DNS 서비스 공급자에 대해 호스팅 영역에 있는 NS 레코드. (현재 공급자는 다른 용어를 사용할 수 있습니다.)
+ [2단계: 호스팅 영역 생성](#migrate-dns-create-hosted-zone)에서 생성한 호스팅 영역에 있는 NS 레코드.
**현재 DNS 서비스 공급자와 함께 NS 레코드에 대한 TTL 설정을 낮추는 방법**
+ 도메인에 대해 제공되는 현재 DNS 서비스 공급자가 제공하는 방법을 사용하여 도메인에 대한 호스팅 영역에 있는 NS 레코드의 TTL을 변경합니다.
**Route 53 호스팅 영역에 있는 NS 레코드에 대한 TTL 설정을 낮추려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 [**Hosted Zones**]를 선택합니다.
1. 호스팅 영역의 이름을 선택합니다.
1. NS 레코드를 선택한 다음 **편집(Edit)**을 선택합니다.
1. [**TTL (Seconds)**]의 값을 변경합니다. 60초에서 900초(15분) 사이의 값을 지정하는 것이 좋습니다.
1. **변경 사항 저장**을 선택합니다.
## 5단계: (DNSSEC를 구성한 경우) 상위 영역에서 DS 레코드 제거
도메인에 대해 DNSSEC를 구성한 경우 도메인을 Route 53로 마이그레이션하기 전에 상위 영역에서 DS(Delegation Signer) 레코드를 제거합니다.
상위 영역이 Route 53 또는 다른 등록 기관을 통해 호스팅되는 경우, 해당되는 등록 기관에 연락해 DS 레코드를 제거합니다.
현재 두 공급자에서 DNSSEC 서명을 사용할 수 없으므로 DS 또는 DNSSEC 서명을 제거하여 DNSSEC를 비활성화해야 합니다. 이는 일시적으로 DNS Resolver에 DNSSEC 검증을 사용하지 않도록 신호를 보냅니다. [11단계](#migrate-dns-re-enable-dnssec)에서 Route 53로의 전환이 완료된 후에도 원하는 경우 DNSSEC 검증을 다시 사용할 수 있습니다.
자세한 내용은 [도메인의 퍼블릭 키 삭제](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) 단원을 참조하십시오.
## 6단계: 이전 TTL의 만료 대기
도메인이 사용 중인 경우(예: 사용자가 도메인 이름을 사용하여 웹 사이트를 검색하거나 웹 애플리케이션에 액세스하는 경우) DNS Resolver가 현재 DNS 서비스 공급자에 의해 제공된 이름 서버의 이름을 캐시했습니다. 몇 분 전에 그 정보를 캐시한 DNS 해석기는 거의 이틀 더 해당 정보를 저장할 것입니다.
Route 53로의 DNS 서비스 마이그레이션을 모두 한 번에 수행하려면 TTL을 낮춘 후 이틀간 기다리세요. 이틀 후에 TTL이 만료되고 해석기가 도메인에 대한 이름 서버를 요청한 후, 해석기는 현재 이름 서버를 얻고 [4단계: TTL 설정 낮춤](#migrate-dns-lower-ttl)에서 지정한 새 TTL도 얻게 됩니다.
## 7단계: Route 53 이름 서버를 사용하도록 NS 레코드 업데이트
도메인의 DNS 서비스로 Amazon Route 53 사용을 시작하려면 상위 영역인 등록 기관에서 제공한 방법을 사용하여 NS 레코드의 현재 이름 서버를 Route 53 이름 서버로 바꿉니다.
**참고**
Route 53 이름 서버를 사용하도록 현재 DNS 서비스 공급자로 NS 레코드를 업데이트하면 도메인의 DNS 구성이 업데이트됩니다. (이런 업데이트는 마이그레이션하는 DNS 서비스로 설정을 업데이트한다는 점을 제외하면 도메인의 Route 53 호스팅 영역에 있는 NS 레코드를 업데이트하는 것과 비슷합니다.)
**상위 영역인 등록 기관에서 NS 레코드를 업데이트하여 Route 53 이름 서버를 사용하려면**
1. Route 53 콘솔에서 호스팅 영역에 대한 이름 서버를 가져옵니다.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. **호스팅 영역** 페이지에서 해당 호스팅 영역의 이름을 선택합니다.
1. **호스팅 영역 세부 정보** 섹션에 있는 **이름 서버**에 대해 나열된 4개의 이름을 기록합니다.
1. 도메인에 대해 현재 DNS 서비스에서 제공되는 방법을 사용하여 호스팅 영역에 대한 NS 레코드를 업데이트하십시오. 도메인이 Route 53에 등록된 경우 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 섹션을 참조하세요. 이 프로세스는 현재 DNS 서비스를 통해 이름 서버를 삭제할 수 있는지에 따라 달라집니다.
**이름 서버를 삭제할 수 있는 경우**
+ 호스팅 영역에 대한 NS 레코드에 현재 이름 서버의 이름을 기록해 두십시오. 현재 DNS 구성으로 되돌릴 필요가 있는 경우 이들 서버는 개발자가 지정하는 서버입니다.
+ NS 레코드에서 현재 이름 서버를 삭제하십시오.
+ NS 레코드를 이 절차의 1단계에서 확인한 Route 53 이름 서버 4개 모두의 이름으로 업데이트하세요.
**참고**
마치면 NS 레코드에 있는 이름 서버만 4개의 Route 53 이름 서버가 됩니다.
**이름 서버를 삭제할 수 없는 경우**
+ 사용자 지정 이름 서버를 사용하려면 이 옵션을 선택하십시오.
+ 이 절차의 1단계에서 확인한 4개의 Route 53 이름 서버를 모두 추가하세요.
## 8단계: 도메인의 트래픽 모니터링
웹 사이트 또는 애플리케이션 트래픽과 이메일을 포함하여, 도메인의 트래픽을 모니터링합니다.
+ **트래픽이 느리거나 중지된 경우** - 이전 DNS 서비스에서 제공하는 방법을 사용하여 도메인의 이름 서버를 이전 이름 서버로 다시 변경합니다. 이는 [상위 영역인 등록 기관에서 NS 레코드를 업데이트하여 Route 53 이름 서버를 사용하려면](#migrate-dns-change-name-servers-with-provider-procedure)의 2단계에서 기록해 둔 이름 서버입니다. 그런 다음 문제를 알아냅니다.
+ **트래픽이 영향을 받지 않는 경우** - [9단계: NS 레코드의 TTL을 더 높은 값으로 다시 변경](#migrate-dns-change-ttl-back)으로 계속 진행합니다.
## 9단계: NS 레코드의 TTL을 더 높은 값으로 다시 변경
도메인의 Amazon Route 53 호스팅 영역에서 NS 레코드의 TTL을 더 일반적인 값으로 변경합니다(예: 172,800초(2일)). 그러면 종종 그랬듯이 DNS 해석기가 도메인의 이름 서버에 대한 쿼리를 보내기를 기다릴 필요가 없으므로 사용자 입장에서는 지연 시간이 짧아지는 효과가 있습니다.
**Route 53 호스팅 영역에 있는 NS 레코드의 TTL을 변경하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 [**Hosted Zones**]를 선택합니다.
1. 호스팅 영역의 이름을 선택합니다.
1. 호스팅 영역에 대한 레코드 목록에서 NS 레코드를 선택합니다.
1. **편집**을 선택합니다.
1. [**TTL (Seconds)**]을 DNS 해석기가 도메인의 이름 서버의 이름을 캐시하도록 할 시간(초)으로 변경합니다. 172,800초의 값을 권장합니다.
1. **변경 사항 저장**을 선택합니다.
## 10단계: 도메인 등록을 Amazon Route 53로 이전
도메인의 DNS 서비스를 Amazon Route 53로 이전했으므로, 도메인의 등록을 Route 53에 선택 사항으로 이전할 수 있습니다. 자세한 내용은 [도메인 등록을 Amazon Route 53으로 이전하기](domain-transfer-to-route-53.md) 단원을 참조하십시오.
## 11단계: DNSSEC 서명 다시 사용(필요한 경우)
도메인의 DNS 서비스를 Amazon Route 53로 이전했으므로 DNSSEC 서명을 다시 사용할 수 있습니다.
DNSSEC 서명 활성화 절차는 다음 두 단계로 구성됩니다.
+ 1단계: Route 53에 DNSSEC 서명을 활성화하고 Route 53이 AWS Key Management Service ()의 고객 관리형 키를 기반으로 키 서명 키(KSK)를 생성하도록 요청합니다AWS KMS.
+ 2단계: DNS 응답이 신뢰할 수 있는 암호화 서명으로 인증될 수 있도록 상위 영역에 DS(Delegation Signer) 레코드를 추가하여 호스팅 영역에 대한 신뢰 체인을 만듭니다.
지침은 [DNSSEC 서명 활성화 및 신뢰 체인 설정](dns-configuring-dnssec-enable-signing.md) 섹션을 참조하세요.
# Route 53를 비활성 도메인에 대한 DNS 서비스로 설정
트래픽이 전혀 발생하지 않는 도메인에 대해 DNS 서비스를 Amazon Route 53로 마이그레이션하려는 경우 이 섹션의 절차를 수행하세요.
**Topics**
+ [1단계: 현재 DNS 서비스 공급자(비활성 도메인)로부터 현재 DNS 구성 가져오기](#migrate-dns-get-zone-file-domain-inactive)
+ [2단계: 호스팅 영역 생성(비활성 도메인)](#migrate-dns-create-hosted-zone-domain-inactive)
+ [3단계: 레코드 생성(비활성 도메인)](#migrate-dns-create-records-domain-inactive)
+ [4단계: 도메인 등록을 업데이트하여 Amazon Route 53 이름 서버 사용(비활성 도메인)](#migrate-dns-update-domain-inactive)
## 1단계: 현재 DNS 서비스 공급자(비활성 도메인)로부터 현재 DNS 구성 가져오기
다른 공급자로부터 Route 53로 DNS 서비스를 마이그레이션할 때 Route 53에서 현재 DNS 구성을 재현합니다. Route 53에서 도메인과 이름이 같은 호스팅 영역을 생성하고 호스팅 영역에 레코드를 생성합니다. 각각의 레코드는 지정된 도메인 또는 하위 도메인 이름에 대해 트래픽을 라우팅할 방법을 나타냅니다. 예를 들어, 웹 브라우저에 도메인 이름을 입력하는 경우 그 트래픽이 데이터 센터의 웹 서버, Amazon EC2 인스턴스, CloudFront 배포 또는 다른 위치로 라우팅되도록 하고 싶습니까?
사용하는 프로세스는 현재 DNS 구성의 복잡성에 따라 다릅니다.
+ **현재 DNS 구성이 간단한 경우** - 단지 몇몇 하위 도메인에 대해서만 인터넷 트래픽을 소수의 리소스(예: 웹 서버 또는 Amazon S3 버킷)로 라우팅하는 경우에는 Route 53 콘솔에서 몇 개의 레코드를 수동으로 생성할 수 있습니다.
+ **현재 DNS 구성이 더 복잡하고 현재 구성을 재현하기만 하려는 경우** - 현재 DNS 서비스 공급자로부터 영역 파일을 받아 Route 53로 가져올 수 있는 경우 마이그레이션을 단순화할 수 있습니다. (모든 DNS 서비스 공급자가 영역 파일을 제공하는 것은 아닙니다.) 영역 파일을 가져올 때 Route 53는 호스팅 영역에 해당 레코드를 생성하여 기존 구성을 자동으로 재현합니다.
현재 DNS 서비스 공급자에게 *영역 파일* 또는 *레코드 목록*을 얻는 방법에 대해 고객 지원을 요청해 보십시오. 필요한 영역 파일 형식에 대한 자세한 내용은 [영역 파일을 가져와 레코드 생성](resource-record-sets-creating-import.md) 단원을 참조하십시오.
+ **현재 DNS 구성이 더 복잡하고 Route 53 라우팅 기능에 관심이 있는 경우** - 다음 문서를 검토하여 다른 DNS 서비스 공급자는 제공하지 않는 Route 53 기능이 필요한지 확인하세요. 그러한 기능을 사용하고 싶으면 레코드를 수동으로 생성하거나 영역 파일을 가져온 다음에 레코드를 생성하거나 업데이트할 수 있습니다.
+ [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 에서는 CloudFront 배포 및 Amazon S3 버킷과 같은 일부 AWS 리소스로 트래픽을 무료로 라우팅하는 Route 53 별칭 레코드의 이점을 설명합니다. Amazon S3
+ [라우팅 정책 선택](routing-policy.md) 섹션에서는 예를 들어 사용자의 위치를 기반으로 하는 라우팅, 사용자와 리소스 사이의 지연 시간을 기반으로 하는 라우팅, 리소스 상태가 양호한지 여부를 기반으로 하는 라우팅, 개발자 자신이 지정하는 가중치를 기반으로 하는 리소스에 대한 라우팅과 같은 Route 53 라우팅 옵션에 대해 설명합니다.
**참고**
별칭 레코드와 복잡한 라우팅 정책을 이용하기 위해 영역 파일을 가져온 후 구성을 변경할 수도 있습니다.
영역 파일을 가져올 수 없거나 Route 53에 레코드를 수동으로 생성하려는 경우, 마이그레이션할 수 있는 레코드는 다음과 같은 레코드를 포함합니다.
+ **A(주소) 레코드** - 도메인 이름 또는 하위 도메인 이름을 해당 리소스의 IPv4 주소(예: 192.0.2.3)와 연결
+ **AAAA(주소) 레코드** - 도메인 이름 또는 하위 도메인 이름을 해당 리소스의 IPv6 주소(예: 2001:0db8:85a3:0000:0000:abcd:0001:2345)와 연결
+ **메일 서버(MX) 레코드** - 트래픽을 메일 서버로 라우팅
+ **CNAME 레코드** - 한 도메인 이름(example.net)의 트래픽을 다른 도메인 이름(example.com)으로 다시 라우팅
+ **기타 지원되는 DNS 레코드 유형에 대한 레코드** - 지원되는 레코드 유형의 목록은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 섹션을 참조하세요.
## 2단계: 호스팅 영역 생성(비활성 도메인)
도메인에 대한 트래픽을 라우팅할 방법을 Amazon Route 53에 알려주려면 도메인과 이름이 같은 호스팅 영역을 생성한 다음 호스팅 영역에 레코드를 생성합니다.
**중요**
관리자 권한이 있는 도메인만 호스팅 영역을 생성할 수 있습니다. 일반적으로 도메인을 소유하고 있다는 뜻이지만 도메인 등록자용 애플리케이션을 개발하는 경우도 해당될 수 있습니다.
호스팅 영역을 생성하면 Route 53에서 해당 영역에 대한 NS(이름 서버) 레코드 및 SOA(권한 시작) 레코드를 자동으로 생성합니다. NS 레코드는 Route 53가 호스팅 영역과 연결된 4개의 이름 서버를 식별합니다. Route 53를 도메인을 위한 DNS 서비스로 설정하려면 도메인에서 이 4개의 이름 서버를 사용하도록 등록을 업데이트합니다.
**중요**
NS(이름 서버) 또는 SOA(권한 시작) 레코드를 추가로 생성하지 말고, 기존 NS 및 SOA 레코드를 삭제하지 마십시오.
**호스팅 영역 생성**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. Route 53를 처음 사용하는 경우 **시작하기(Get started)**를 선택합니다.
Route 53를 이미 사용하고 있는 경우 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
1. **호스팅 영역 생성(Create hosted zones)** 창에서 도메인 이름과 메모(선택 사항)를 입력합니다. 라벨 위에 마우스 포인트를 대면 도움말이 표시되어 설정에 관한 자세한 내용을 볼 수 있습니다.
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하세요.
1. **레코드 유형(Record type)**의 경우 **퍼블릭 호스팅 영역(Public hosted zone)**의 기본값을 허용합니다.
1. **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
## 3단계: 레코드 생성(비활성 도메인)
호스팅 영역을 생성한 후 도메인(example.com) 또는 하위 도메인(www.example.com)에 대한 트래픽을 라우팅하려는 위치를 정의하는 레코드를 호스팅 영역에 생성합니다. 예를 들어, example.com 및 www.example.com에 대한 트래픽을 Amazon EC2 인스턴스의 웹 서버로 라우팅하려는 경우 example.com과 www.example.com으로 명명된 레코드를 하나씩 만듭니다. 각 레코드에 EC2 인스턴스에 대한 IP 주소를 지정합니다.
다양한 방법으로 레코드를 생성할 수 있습니다.
**영역 파일 가져오기**
이 방법은 [1단계: 현재 DNS 서비스 공급자(비활성 도메인)로부터 현재 DNS 구성 가져오기](#migrate-dns-get-zone-file-domain-inactive)에서 현재 DNS 서비스를 통해 영역 파일을 받는 경우 가장 쉬운 방법입니다. Amazon Route 53에서는 별칭 레코드를 생성하거나 가중치 기반 또는 장애 조치 같은 특별한 라우팅 유형을 사용할 시점을 예측할 수 없습니다. 따라서 영역 파일을 가져오는 경우 Route 53는 간단한 라우팅 정책을 사용하여 표준 DNS 레코드를 생성합니다.
자세한 내용은 [영역 파일을 가져와 레코드 생성](resource-record-sets-creating-import.md) 단원을 참조하십시오.
**콘솔에서 레코드 개별 생성**
영역 파일을 가져오지 않고 단지 시작하기 위해 Simple의 라우팅 정책으로 몇 개의 레코드만 생성하려는 경우 Route 53 콘솔에서 레코드를 생성할 수 있습니다. 별칭 레코드와 그 밖의 레코드를 모두 생성할 수 있습니다.
자세한 내용은 다음 항목을 참조하세요.
+ [라우팅 정책 선택](routing-policy.md)
+ [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md)
+ [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md)
**프로그래밍 방식으로 레코드 생성**
AWS SDKs, AWS CLI또는 중 하나를 사용하여 레코드를 생성할 수 있습니다 AWS Tools for Windows PowerShell. 자세한 내용은 [AWS 설명서](https://docs.aws.amazon.com/)를 참조하세요.
SDK를 제공하지 AWS 않는 프로그래밍 언어를 사용하는 경우 Route 53 API를 사용할 수도 있습니다. 자세한 내용은 [Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/)를 확인하십시오.
## 4단계: 도메인 등록을 업데이트하여 Amazon Route 53 이름 서버 사용(비활성 도메인)
도메인에 대한 레코드 생성을 완료하면 도메인에 대한 DNS 서비스를 Amazon Route 53로 변경할 수 있습니다. 도메인 등록자로 설정을 업데이트하려면 다음 절차를 수행하십시오.
**도메인의 이름 서버 업데이트 방법**
1. Route 53 콘솔에서 Route 53 호스팅 영역에 대한 이름 서버를 가져옵니다.
1. [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개의 이름을 기록합니다.
1. 도메인의 등록자가 제공한 방법을 사용하여, 이 절차의 2단계에서 받은 Route 53 이름 서버 4개를 사용하도록 도메인의 이름 서버를 변경합니다.
도메인이 Route 53에 등록되어 있으면 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 섹션을 참조하세요.
# 새 도메인에 대한 DNS 라우팅 구성
**Route 53로부터 구매한 새 도메인**
Route 53에 도메인을 등록하면 Route 53가 자동으로 해당 도메인의 DNS 서비스가 됩니다. Route 53는 도메인과 동일한 이름의 호스팅 영역을 생성하고, 호스팅 영역에 4개의 이름 서버를 할당한 다음 도메인이 이 이름 서버를 사용하도록 업데이트합니다.
**다른 등록 기관으로부터 구매한 새 도메인**
최상위 도메인(TLD)이 Route 53에서 제공되지 않는 등의 이유로 다른 등록 기관으로부터 도메인을 구매하는 경우 두 가지 옵션이 있습니다.
+ **DNS 호스팅에만 Route 53 사용:** 현재 등록 기관을 유지하고 Route 53에 DNS 관리를 위임합니다. 아래 절차에 따라 호스팅 영역을 생성하고 등록 기관의 이름 서버를 업데이트합니다.
+ **도메인 등록을 Route 53로 이전:** Route 53를 등록 기관 및 DNS 서비스로 만듭니다. 사전 조건은 [도메인 이전을 위한 이전 전 체크리스트](domain-transfer-checklist.md) 섹션을, 이전 프로세스는 [도메인 등록을 Amazon Route 53으로 이전하기](domain-transfer-to-route-53.md) 섹션을 참조하세요.
Route 53가 지원하는 TLD에 대한 자세한 내용은 [Amazon Route 53에 등록할 수 있는 도메인](registrar-tld-list.md) 섹션을 참조하세요.
다음 지침에 따라 퍼블릭 호스팅 영역을 생성한 다음 생성된 이름 서버를 등록 기관에서 사용합니다.
**Route 53 외의 도메인에 대해 호스팅 영역 생성**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택한 후 **호스팅 영역 생성**을 선택합니다.
1. **이름**에 호스팅 영역을 생성할 도메인의 이름을 입력하고 `example.com`과 같은 설명을 선택적으로 입력하고 **퍼블릭 호스팅 영역**을 선택한 다음 **호스팅 영역 생성**을 선택합니다.
1. 호스팅 영역을 생성한 후 생성된 4개의 이름 서버(NS) 레코드를 기록해 둡니다. 각 이름 서버는 "ns-"로 시작합니다.
도메인 등록 기관에서 위의 이름 서버를 입력하여 도메인 관리를 Route 53 호스팅 영역에 위임합니다.
**DNS 트래픽 라우팅**
Route 53가 도메인에 대한 인터넷 트래픽을 라우팅하는 방법을 지정하려면 호스팅 영역에 레코드를 생성합니다. 예를 들어, Amazon EC2 인스턴스에서 실행 중인 웹 서버로 example.com에 대한 요청을 라우팅하고자 하는 경우 example.com 호스팅 영역에서 레코드를 생성하고, EC2 인스턴스에 대한 탄력적 IP 주소를 지정합니다. 자세한 정보는 다음의 주제를 참조하세요.
+ 호스팅 영역에서 레코드를 생성하는 방법에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md) 섹션을 참조하세요.
+ 선택한 AWS 리소스로 트래픽을 라우팅하는 방법에 대한 자세한 내용은 [AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md) 섹션을 참조하세요.
+ DNS 작동 방식에 대한 자세한 내용은 [웹 사이트 또는 웹 애플리케이션으로 인터넷 트래픽을 라우팅하는 방식](welcome-dns-service.md) 단원을 참조하십시오.
+ DNS 응답을 확인하려면 [Route 53에서 DNS 응답 확인](dns-test.md) 섹션을 참조하세요.
# 해당 리소스로 트래픽 라우팅
예를 들어 사용자가 웹 브라우저에 해당 도메인 이름을 입력하여 웹 사이트 또는 웹 애플리케이션을 요청하면, Amazon Route 53에서 사용자를 해당 리소스(Amazon S3 버킷 또는 데이터 센터의 웹 서버 등)로 라우팅하도록 도와줍니다. 트래픽을 해당 리소스로 라우팅하도록 Route 53를 구성하려면 다음을 수행하세요.
1. 호스팅 영역 생성. 퍼블릭 호스팅 영역 또는 프라이빗 호스팅 영역을 만들 수 있습니다.
**퍼블릭 호스팅 영역**
예를 들어 인트라넷 트래픽을 해당 리소스로 라우팅하려면 퍼블릭 호스팅 영역을 만들어서, EC2 인스턴스에서 호스팅하는 회사 웹 사이트를 고객들이 볼 수 있게 합니다. 자세한 내용은 [퍼블릭 호스팅 영역 작업](AboutHZWorkingWith.md) 섹션을 참조하세요.
**프라이빗 호스팅 영역**
Amazon VPC 내에서 트래픽을 라우팅하려면 프라이빗 호스팅 영역을 만듭니다. 자세한 내용은 [프라이빗 호스팅 영역 사용](hosted-zones-private.md) 섹션을 참조하세요.
1. 호스팅 영역에 레코드를 생성합니다. 레코드는 각 도메인 또는 하위 도메인 이름에 대해 트래픽을 라우팅할 위치를 정의합니다. 예를 들어 www.example.com에 대한 트래픽을 해당 데이터 센터의 웹 서버로 라우팅하려면, 일반적으로 example.com 호스팅 영역에 www.example.com 레코드를 생성합니다.
자세한 내용은 다음 항목을 참조하세요.
+ [레코드 작업](rrsets-working-with.md)
+ [하위 도메인에 대한 트래픽 라우팅](dns-routing-traffic-for-subdomains.md)
+ [AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md)
# 하위 도메인에 대한 트래픽 라우팅
트래픽을 하위 도메인의 리소스(예: acme.example.com 또는 zenith.example.com)로 라우팅하려는 경우 두 가지 방법이 있습니다.
**도메인의 호스팅 영역에 레코드 생성**
일반적으로, 하위 도메인에 대한 트래픽을 라우팅하려면 도메인과 이름이 동일한 호스팅 영역에 레코드를 생성합니다. 예를 들어 acme.example.com에 대한 인터넷 트래픽을 해당 데이터 센터의 웹 서버로 라우팅하려면, example.com 호스팅 영역에 acme.example.com이라는 레코드를 생성합니다. 자세한 내용은 [레코드 작업](rrsets-working-with.md) 주제 및 해당 하위 주제를 참조하십시오.
**하위 도메인에 대한 호스팅 영역을 만들고, 이 새로운 호스팅 영역에 레코드 생성**
하위 도메인에 대한 호스팅 영역을 생성할 수도 있습니다. 별도의 호스팅 영역을 이용하여 하위 도메인의 인터넷 트래픽을 라우팅하는 것을 "호스팅 영역에 대한 하위 도메인의 책임 위임" 또는 "다른 이름 서버에 하위 도메인 위임"이라고 하거나 이와 비슷한 용어의 조합으로 부르기도 합니다. 여기서는 작동 방법에 대해 간략하게 살펴봅니다.
1. 트래픽을 라우팅할 하위 도메인과 이름이 같은 호스팅 영역(예: acme.example.com)을 생성합니다.
1. 이 새로운 호스팅 영역에, 해당 하위 도메인(acme.example.com) 및 그 하위 도메인(예: backend.acme.example.com)에 대한 트래픽을 라우팅하는 방법을 정의하는 레코드를 생성합니다.
1. 새 호스팅 영역을 생성할 때 Route 53가 새 호스팅 영역에 할당한 이름 서버를 가져옵니다.
1. 도메인의 호스팅 영역(example.com)에 새 NS 레코드를 생성합니다. NS 레코드 이름은 하위 도메인 이름(acme.example.com)이어야 하며, 3단계에서 얻은 4개의 이름 서버를 레코드 값으로 지정합니다.
별도 호스팅 영역을 사용하여 하위 도메인에 대한 트래픽을 라우팅할 때는 IAM 권한을 사용하여 하위 도메인의 호스팅 영역에 대한 액세스를 제한할 수 있습니다. 서로 다른 그룹에서 관리하는 하위 도메인이 여러 개 있는 경우, 각 하위 도메인에 대해 하나의 호스팅 영역을 만들면 도메인의 호스팅 영역에 있는 레코드를 액세스해야 하는 사용자의 수를 현저히 줄일 수 있습니다.
이 위임 프로세스를 구현하려면 다음 IAM 권한이 필요합니다. Route 53 IAM 정책에 대한 자세한 내용은 섹션을 참조[Amazon Route 53의 Identity and Access Management](security-iam.md)하세요.
**상위 계정(example.com 소유)**
사용자 또는 역할에는 상위 도메인의 호스팅 영역에서 레코드를 수정할 수 있는 권한이 필요합니다.
**하위 계정(acme.example.com 생성)**
사용자 또는 역할에는 하위 도메인 호스팅 영역을 생성하고 관리할 수 있는 권한이 필요합니다.
하위 도메인에 별도 호스팅 영역을 사용하면 그 도메인과 하위 도메인에 다른 DNS 서비스를 사용할 수 있습니다. 자세한 내용은 [상위 도메인을 마이그레이션하지 않고 Amazon Route 53를 하위 도메인에 대한 DNS 서비스로 사용](creating-migrating.md) 섹션을 참조하세요.
이 구성은 각 DNS 해석의 첫 DNS 쿼리에 대해 다소 성능을 높이는 효과가 있습니다. 해석기는 루트 도메인의 호스팅 영역으로부터 정보를 받은 후, 하위 도메인의 호스팅 영역으로부터 정보를 받아야 합니다. 해석기는 하위 도메인에 대한 첫 번째 DNS 쿼리 후에 이 정보를 캐시에 저장하므로 TTL이 만료되어 다른 클라이언트가 해당 해석기로부터 하위 도메인을 요청할 때까지 정보를 다시 받을 필요가 없습니다. 자세한 내용은 [Amazon Route 53 레코드를 생성 또는 편집할 때 지정하는 값](resource-record-sets-values.md) 섹션의 [TTL(초)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) 섹션을 참조하세요.
**Topics**
+ [다른 호스팅 영역을 만들어 하위 도메인에 대한 트래픽 라우팅](#dns-routing-traffic-for-subdomains-new-hosted-zone)
+ [하위 도메인의 추가 수준에 대한 트래픽 라우팅](#dns-routing-traffic-for-sub-subdomains)
## 다른 호스팅 영역을 만들어 하위 도메인에 대한 트래픽 라우팅
하위 도메인에 대한 트래픽을 라우팅하는 한 가지 방법은 하위 도메인에 대한 호스팅 영역을 만든 후, 이 새로운 호스팅 영역에 하위 도메인에 대한 레코드를 생성하는 것입니다. (가장 일반적인 방법은 해당 도메인의 호스팅 영역에 하위 도메인에 대한 레코드를 생성하는 것입니다.)
**참고**
이 절차에서는 하위 도메인을 Route 53에 위임하는 방법을 보여줍니다. 대신 해당 서비스의 이름 서버를 가리키는 NS 레코드를 생성하여 하위 도메인을 다른 DNS 서비스에 위임할 수도 있습니다.
다음은 이 프로세스를 요약한 것입니다.
1. 하위 도메인에 대한 호스팅 영역을 생성합니다. 자세한 내용은 [하위 도메인에 대한 호스팅 영역 새로 만들기](#dns-routing-traffic-for-subdomains-creating-hosted-zone) 섹션을 참조하세요.
1. 하위 도메인에 대한 호스팅 영역에 레코드를 추가합니다. 하위 도메인의 호스팅 영역에 속한 레코드가 도메인의 호스팅 영역에 하나라도 포함된 경우, 하위 도메인의 호스팅 영역에 그 레코드를 복제합니다. 자세한 내용은 [하위 도메인에 대한 호스팅 영역에 레코드 생성](#dns-routing-traffic-for-subdomains-creating-records) 섹션을 참조하세요.
1. 해당 도메인의 호스팅 영역에 하위 도메인에 대한 NS 레코드를 생성하면, 하위 도메인에 대한 책임을 새로운 호스팅 영역의 이름 서버에 위임합니다. 하위 도메인의 호스팅 영역에 속한 레코드가 도메인의 호스팅 영역에 하나라도 포함된 경우, 도메인의 호스팅 영역에서 그 레코드를 삭제합니다. (2단계에서 하위 도메인의 호스팅 영역에 사본을 생성했습니다.) 자세한 내용은 [도메인의 호스팅 영역 업데이트](#dns-routing-traffic-for-subdomains-delegating-responsibility) 섹션을 참조하세요.
### 하위 도메인에 대한 호스팅 영역 새로 만들기
Route 53 콘솔을 사용하여 하위 도메인에 대한 호스팅 영역을 만들려면 다음 절차를 수행합니다.
**하위 도메인에 대한 호스팅 영역을 만들려면(콘솔)**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. Route 53를 처음 사용하는 경우 **시작하기(Get started)**를 선택합니다.
Route 53를 이미 사용하고 있는 경우 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
1. 오른쪽 창에 하위 도메인 이름(예: acme.example.com)을 입력합니다. 선택적으로 설명을 입력할 수도 있습니다.
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하세요.
1. **유형(Type)**의 경우 **퍼블릭 호스팅 영역(Public hosted zone)**의 기본값을 허용합니다.
1. 오른쪽 창 하단에서 **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
### 하위 도메인에 대한 호스팅 영역에 레코드 생성
Route 53가 하위 도메인(acme.example.com)과 그 하위 도메인(backend.acme.example.com)에 대한 트래픽을 라우팅하는 방법을 정의하려면 하위 도메인의 호스팅 영역에 레코드를 생성합니다.
하위 도메인의 호스팅 영역에 레코드를 생성하는 내용에 대해서는 다음을 참고하십시오.
+ 하위 도메인의 호스팅 영역에 NS(이름 서버) 또는 SOA(권한 시작) 레코드를 추가로 생성하지 말고, 기존 NS 및 SOA 레코드를 삭제하지 마십시오.
+ 하위 도메인의 모든 레코드를 하위 도메인의 호스팅 영역에 생성합니다. 예를 들어, example.com과 acme.example.com 도메인의 호스팅 영역이 있다면 acme.example.com 하위 도메인의 모든 레코드를 acme.example.com 호스팅 영역에 생성합니다. 여기에는 backend.acme.example.com 및 beta.backend.acme.example.com 같은 레코드가 포함됩니다.
+ 하위 도메인(acme.example.com)의 호스팅 영역에 속한 레코드가 도메인(example.com)의 호스팅 영역에 포함된 경우, 하위 도메인의 호스팅 영역에 그 레코드를 복제합니다. 프로세스의 마지막 단계에서 중복 레코드를 도메인의 호스팅 영역에서 나중에 삭제합니다.
**중요**
도메인의 호스팅 영역과 하위 도메인의 호스팅 영역 양쪽에 하위 도메인의 레코드가 있는 경우 DNS 동작에 일관성이 없어집니다. 동작을 좌우하는 것은 DNS 해석기가 캐시한 이름 서버, 도메인 호스팅 영역(example.com)에 대한 이름 서버, 하위 도메인 호스팅 영역(acme.example.com)에 대한 이름 서버입니다. 레코드가 존재하되 DNS 해석기가 쿼리를 제출하는 호스팅 영역에 있는 것이 아닌 경우, Route 53은 NXDOMAIN(존재하지 않는 도메인)을 반환합니다.
자세한 내용은 [레코드 작업](rrsets-working-with.md) 섹션을 참조하세요.
### 도메인의 호스팅 영역 업데이트
호스팅 영역을 생성하면 Route 53에서 호스팅 영역에 4개의 이름 서버를 자동으로 할당합니다. 호스팅 영역의 NS 레코드는 도메인 또는 하위 도메인에 대한 DNS 쿼리에 응답하는 이름 서버를 식별합니다. 하위 도메인의 호스팅 영역에 있는 레코드를 사용하여 인터넷 트래픽 라우팅을 시작하려면, 도메인(example.com)의 호스팅 영역에 NS 레코드를 새로 생성하고, 이 레코드에 하위 도메인(acme.example.com) 이름을 지정합니다. NS 레코드 값으로는 하위 도메인의 호스팅 영역에서 이름 서버의 이름을 지정합니다.
다음은 Route 53가 하위 도메인(acme.example.com) 또는 그 하위 도메인 중 하나에 대해 DNS Resolver로부터 DNS 쿼리를 수신하면 어떻게 되는지 보여줍니다.
1. Route 53가 도메인(example.com)에 대한 호스팅 영역에서 하위 도메인(acme.example.com)에 대한 NS 레코드를 찾습니다.
1. Route 53는 example.com 도메인의 호스팅 영역에 있는 acme.example.com NS 레코드에서 이름 서버를 가져와 이러한 이름 서버를 DNS Resolver에 반환합니다.
1. 해석기가 acme.example.com에 대한 쿼리를 acme.example.com 호스팅 영역에 대한 이름 서버로 다시 제출합니다.
1. Route 53이 acme.example.com 호스팅 영역에 있는 레코드를 사용하여 쿼리에 응답합니다.
Route 53가 하위 도메인의 호스팅 영역을 사용하여 하위 도메인에 대한 트래픽을 라우팅하도록 구성하고, 도메인의 호스팅 영역에서 중복 레코드를 모두 삭제하려면 다음 절차를 수행합니다.
**하위 도메인(콘솔)의 호스팅 영역을 사용하도록 Route 53를 구성하려면**
1. Route 53 콘솔에서 하위 도메인에 대한 호스팅 영역의 이름 서버를 가져옵니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. **호스팅 영역(Hosted zones)** 페이지에서 하위 도메인의 호스팅 영역의 이름을 선택합니다.
1. 오른쪽 창에서 **호스팅 영역 세부 사항(Hosted zones details)** 섹션의 **이름 서버(Name servers)**에 나열된 4개 서버의 이름을 복사합니다.
1. 하위 도메인이 아니라 도메인(example.com)의 호스팅 영역 이름을 선택합니다.
1. **레코드 세트 생성**을 선택합니다.
1. **단순 라우팅(Simple routing)**을 선택하고 **다음(Next)**을 선택합니다.
1. **Define simple record(단순 레코드 정의)**를 선택합니다.
1. 다음 값을 지정하세요.
**이름**
하위 도메인의 이름(예: `acme.example.com`)을 입력합니다. 생성한 하위 도메인 호스팅 영역의 이름과 정확히 일치해야 합니다.
**값/트래픽 라우팅 대상**
**IP 주소 또는 레코드 유형에 따라 다른 값(IP address or another value depending on the record type)**을 선택하고 1단계에서 복사한 이름 서버의 이름을 붙여넣습니다.
**레코드 유형**
**NS - 호스팅 영역의 이름 서버(NS – Name servers for a hosted zone)**를 선택합니다.
**TTL(초)**
NS 레코드에 대한 보다 일반적인 값(예: 172800초)으로 변경합니다.
1. **단순 레코드 정의(Define simple record)**를 선택하고 **레코드 생성(Create records)**을 선택합니다.
1. 하위 도메인의 호스팅 영역에 생성한 레코드가 도메인의 호스팅 영역에 하나라도 포함된 경우, 도메인의 호스팅 영역에서 그 레코드를 삭제합니다. 자세한 내용은 [레코드 삭제](resource-record-sets-deleting.md) 섹션을 참조하세요.
작업이 끝나면 하위 도메인의 모든 레코드가 하위 도메인의 호스팅 영역에 위치하게 됩니다.
## 하위 도메인의 추가 수준에 대한 트래픽 라우팅
하위 도메인의 하위 도메인(예: backend.acme.example.com)에 대한 트래픽은 하위 도메인(예: acme.example.com)에 대한 트래픽을 라우팅하는 것과 동일한 방법으로 라우팅합니다. 도메인의 호스팅 영역에 레코드를 생성하거나, 하위 수준 하위 도메인의 호스팅 영역을 생성한 후 이 새로운 호스팅 영역에 레코드를 생성합니다.
낮은 수준의 하위 도메인을 위한 호스팅 영역을 별개로 생성하고자 한다면, 도메인 이름에서 한 수준 옆에 있는 하위 도메인의 호스팅 영역에 하위 수준 하위 도메인에 대한 NS 레코드를 생성합니다. 트래픽이 정확하게 리소스로 라우팅이 되도록 도와줍니다. 예를 들어 다음 하위 도메인에 대한 트래픽을 라우팅한다고 가정하겠습니다.
+ subdomain1.example.com
+ subdomain2.subdomain1.example.com
다른 호스팅 영역을 사용하여 subdomain2.subdomain1.example.com에 대한 트래픽을 라우팅하려면 다음과 같이 합니다.
1. subdomain2.subdomain1.example.com이라는 호스팅 영역을 만듭니다.
1. subdomain2.subdomain1.example.com hosted 호스팅 영역에 레코드를 생성합니다. 자세한 내용은 [하위 도메인에 대한 호스팅 영역에 레코드 생성](#dns-routing-traffic-for-subdomains-creating-records) 섹션을 참조하세요.
1. subdomain2.subdomain1.example.com 호스팅 영역의 이름 서버 이름을 복사합니다.
1. subdomain1.example.com 호스팅 영역에 subdomain2.subdomain1.example.com이라는 NS 레코드를 생성하고, subdomain2.subdomain1.example.com 호스팅 영역의 이름 서버 이름을 붙여 넣습니다.
또한 subdomain1.example.com에서 중복 레코드를 모두 삭제합니다. 자세한 내용은 [도메인의 호스팅 영역 업데이트](#dns-routing-traffic-for-subdomains-delegating-responsibility) 섹션을 참조하세요.
이 NS 레코드를 생성하면 Route 53가 subdomain2.subdomain1.example.com 호스팅 영역을 사용하여 subdomain2.subdomain1.example.com 하위 도메인에 대한 트래픽을 라우팅합니다.
# 호스팅 영역 작업
호스팅 영역이란 레코드의 컨테이너이며, 레코드에는 특정 도메인(예: example.com)과 그 하위 도메인(acme.example.com, zenith.example.com)의 트래픽을 라우팅하는 방식에 대한 정보가 포함됩니다. 호스팅 영역과 해당 도메인의 이름은 동일합니다. 호스팅 영역의 유형은 다음의 두 가지입니다.
+ *퍼블릭 호스팅 영역*은 인터넷에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함합니다. 자세한 내용은 [퍼블릭 호스팅 영역 작업](AboutHZWorkingWith.md) 섹션을 참조하세요.
+ *프라이빗 호스팅 영역*은 Amazon VPC에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함합니다. 자세한 내용은 [프라이빗 호스팅 영역 사용](hosted-zones-private.md) 섹션을 참조하세요.
# 퍼블릭 호스팅 영역 작업
퍼블릭 호스팅 영역이란 특정 도메인(예: 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
```
# 프라이빗 호스팅 영역 사용
*프라이빗 호스팅 영역*은 Amazon VPC 서비스로 생성한 하나 이상의 VPC 내에 있는 도메인과 그 하위 도메인에 대하여 Amazon Route 53의 DNS 쿼리 응답 정보가 담긴 컨테이너입니다. 프라이빗 호스팅 영역의 작업 방식은 다음과 같습니다.
1. 프라이빗 호스팅 영역을 생성(예: example.com) 및 호스팅 영역과 연결하려는 VPC를 지정합니다. 호스팅 영역을 생성한 후 더 많은 VPC를 여기에 연결할 수 있습니다.
1. VPC 중에서 도메인 및 하위 도메인 그리고 VPC 간에 대한 Route 53의 DNS 쿼리 응답 방식을 확인하는 호스팅 영역에 레코드를 생성합니다. 예를 들어, 데이터베이스 서버가 프라이빗 호스팅 영역에 연결한 VPC의 EC2 인스턴스에서 실행된다고 가정하겠습니다. A 또는 AAAA 레코드를 생성하고(예: db.example.com) 데이터베이스 서버의 IP 주소를 지정합니다.
레코드에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md) 단원을 참조하십시오. 프라이빗 호스팅 영역 사용에 대해 Amazon VPC 요구 사항에 대한 자세한 내용은 *Amazon VPC 사용 설명서*의 [프라이빗 호스팅 영역 사용](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones)을 참조하세요.
1. 애플리케이션이 db.example.com에 DNS 쿼리를 제출하면 Route 53가 해당 IP 주소를 반환합니다. 프라이빗 호스팅 영역에서 응답을 받으려면 연결된 VPC 중 하나에서 EC2 인스턴스를 실행 중이거나 하이브리드 설정의 인바운드 엔드포인트가 있어야 합니다. VPC 또는 하이브리드 설정 외부에서 프라이빗 호스팅 영역을 쿼리하려고 하면 인터넷에서 쿼리가 반복적으로 해결됩니다.
1. 애플리케이션은 Route 53에서 얻은 IP 주소를 사용하여 데이터베이스 서버와 연결합니다.
프라이빗 호스팅 영역을 생성할 때 다음 네임 서버가 사용됩니다.
+ ns-0.awsdns-00.com
+ ns-512.awsdns-00.net
+ ns-1024.awsdns-00.org
+ ns-1536.awsdns-00.co.uk
DNS 프로토콜을 사용하려면 모든 호스팅 영역에 NS 레코드 세트가 있어야 하기 때문에 이러한 네임 서버가 사용됩니다. 이러한 이름 서버는 예약되어 있으며 Route 53 퍼블릭 호스팅 영역에서 절대 사용되지 않습니다. 프라이빗 호스팅 영역에 지정된 VPC에 연결된 인바운드 엔드포인트를 사용하여 호스팅 영역에 연결된 VPC의 VPCs Resolver를 통해서만 해당 영역을 쿼리할 수 있습니다.
이름 서버는 인터넷에 표시되지만 VPC Resolver는 이름 서버 주소에 연결하지 않습니다. 또한 인터넷을 통해 이름 서버를 직접 쿼리하는 경우 프라이빗 호스팅 영역 정보가 반환되지 않습니다. 대신 VPC Resolver는 VPC와 호스팅 영역 연결을 기반으로 쿼리가 프라이빗 네임스페이스 내에 있음을 감지하고 직접 프라이빗 연결을 사용하여 프라이빗 DNS 서버에 도달합니다.
**참고**
원하는 경우 프라이빗 호스팅 영역에서 NS 레코드 세트를 변경할 수 있으며 프라이빗 DNS 확인은 계속 작동합니다. 그렇게 하는 것은 권장되지 않지만, 원한다면 퍼블릭 DNS 서버에서 사용하지 않는 예약된 도메인 이름을 사용해야 합니다.
인터넷에서 도메인에 대한 트래픽을 라우팅하고자 하는 경우 Route 53 *퍼블릭* 호스팅 영역을 사용합니다. 자세한 내용은 [퍼블릭 호스팅 영역 작업](AboutHZWorkingWith.md) 섹션을 참조하세요.
**Topics**
+ [프라이빗 호스팅 영역 작업 시 고려 사항](hosted-zone-private-considerations.md)
+ [프라이빗 호스팅 영역 생성](hosted-zone-private-creating.md)
+ [프라이빗 호스팅 영역 나열](hosted-zone-private-listing.md)
+ [더 많은 VPC를 프라이빗 호스팅 영역에 연결](hosted-zone-private-associate-vpcs.md)
+ [Amazon VPC와 다른 AWS 계정으로 생성한 프라이빗 호스팅 영역 연결](hosted-zone-private-associate-vpcs-different-accounts.md)
+ [프라이빗 호스팅 영역에서 VPC 연결 해제](hosted-zone-private-disassociate-vpcs.md)
+ [프라이빗 호스팅 영역 삭제](hosted-zone-private-deleting.md)
+ [VPC 권한](hosted-zone-private-vpc-permissions.md)
# 프라이빗 호스팅 영역 작업 시 고려 사항
프라이빗 호스팅 영역을 사용하는 경우 다음 고려 사항을 참조하십시오.
+ [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings)
+ [Route 53 health checks](#hosted-zone-private-considerations-health-checks)
+ [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies)
+ [Split-view DNS](#hosted-zone-private-considerations-split-view-dns)
+ [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping)
+ [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)
+ [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain)
+ [Custom DNS servers](#hosted-zone-private-considerations-custom-dns)
+ [Required IAM permissions](#hosted-zone-private-considerations-required-permissions)
**Amazon VPC 설정**
프라이빗 호스팅 영역을 사용하려면 다음과 같은 Amazon VPC 설정을 `true`로 설정해야 합니다.
+ `enableDnsHostnames`
+ `enableDnsSupport`
자세한 내용은 *Amazon VPC 사용 설명서*의 [VPC에 대한 DNS 속성 보기 및 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html)를 참조하세요.
**Route 53 상태 확인**
프라이빗 호스팅 영역에서는 Route 53 상태 확인을 장애 조치, 다중 응답, 가중치 기반, 지연 시간, 지리적 위치, 지리적 근접성 레코드에만 연결할 수 있습니다. 장애 조치 레코드를 이용한 상태 확인 연결에 대한 자세한 내용은 [프라이빗 호스팅 영역에서 장애 조치 구성](dns-failover-private-hosted-zones.md) 단원을 참조하십시오.
**프라이빗 호스팅 영역의 레코드에 대해 지원되는 라우팅 정책**
프라이빗 호스팅 영역에서 레코드를 생성할 때 다음 라우팅 정책을 사용할 수 있습니다.
+ [단순 라우팅](routing-policy-simple.md)
+ [장애 조치 라우팅](routing-policy-failover.md)
+ [다중값 응답 라우팅](routing-policy-multivalue.md)
+ [가중치 기반 라우팅](routing-policy-weighted.md)
+ [지연 시간 기반 라우팅](routing-policy-latency.md)
+ [지리적 라우팅](routing-policy-geo.md)
+ [지리 근접 라우팅](routing-policy-geoproximity.md)
다른 라우팅 정책을 이용해 프라이빗 호스팅 영역에서 레코드를 생성하는 것은 지원되지 않습니다.
**분할-보기 DNS**
Route 53를 사용하여 분할-보기 DNS(분할-수평 DNS)를 구성할 수 있습니다. 분할-보기 DNS에서는 내부 사용(accounting.example.com) 및 퍼블릭 웹사이트(www.example.com) 같은 외부 사용에 있어 동일한 도메인 이름(example.com)을 사용합니다. 내부 및 외부에서 동일한 하위 도메인 이름을 사용하되, 내부 및 외부 사용자에게 서로 다른 콘텐츠를 제공하거나 서로 다른 인증을 요구하고 싶을 수도 있습니다.
분할-보기 DNS를 구성하려면 다음 단계를 수행합니다.
1. 이름이 동일한 퍼블릭 호스팅 영역과 프라이빗 호스팅 영역을 생성합니다 (퍼블릭 호스팅 영역에서 다른 DNS 서비스를 사용하고 있는 경우에도 분할-보기 DNS는 여전히 작동).
1. 하나 이상의 Amazon VPC를 프라이빗 호스팅 영역에 연결합니다. Route 53 VPC Resolver는 프라이빗 호스팅 영역을 사용하여 지정된 VPCs.
1. 각 호스팅 영역에서 레코드를 생성합니다. 퍼블릭 호스팅 영역의 레코드는 인터넷 트래픽이 라우팅되는 방법을 제어하고, 프라이빗 호스팅 영역의 레코드는 Amazon VPC에서 트래픽이 라우팅되는 방법을 제어합니다.
VPC 및 온프레미스 워크로드의 이름 확인을 모두 수행해야 하는 경우 Route 53 VPC Resolver를 사용할 수 있습니다. 자세한 내용은 [Route 53 VPC Resolver란 무엇입니까?](resolver.md) 단원을 참조하십시오.
**네임스페이스가 겹치는 퍼블릭 및 프라이빗 호스팅 영역**
example.com 및 같이 네임스페이스가 중첩되는 프라이빗 및 퍼블릭 호스팅 영역이 있는 경우 accounting.example.com VPC Resolver는 가장 구체적인 일치 항목을 기반으로 트래픽을 라우팅합니다. 사용자가 프라이빗 호스팅 영역과 연결된 Amazon VPC의 EC2 인스턴스에 로그인하면 Route 53 VPC Resolver가 DNS 쿼리를 처리하는 방법은 다음과 같습니다.
1. VPC Resolver는 프라이빗 호스팅 영역의 이름이 accounting.example.com 같은 요청의 도메인 이름과 일치하는지 평가합니다. 일치는 다음 중 하나로 정의됩니다.
+ 동일한 일치
+ 프라이빗 호스팅 영역의 이름이 요청의 도메인 이름의 부모입니다. 예를 들어 요청에 있는 도메인 이름이 다음과 같다고 가정해 봅니다.
**seattle.accounting.example.com**
다음의 호스팅 영역들은 seattle.accounting.example.com의 부모이기 때문에 일치합니다.
+ **accounting.example.com**
+ **example.com**
일치하는 프라이빗 호스팅 영역이 없는 경우 VPC Resolver는 요청을 퍼블릭 DNS 해석기로 전달하고 요청은 일반 DNS 쿼리로 해결됩니다.
1. 요청에 있는 도메인 이름과 일치하는 프라이빗 호스팅 영역 이름이 있는 경우, 호스팅 영역에서 요청의 도메인 이름 및 DNS 유형(예: accounting.example.com의 A 레코드)과 일치하는 레코드를 찾습니다.
**참고**
일치하는 프라이빗 호스팅 영역이 있지만 요청의 도메인 이름 및 유형과 일치하는 레코드가 없는 경우 VPC Resolver는 요청을 퍼블릭 DNS 해석기로 전달하지 않습니다. 그 대신 NXDOMAIN(존재하지 않는 도메인)을 클라이언트로 반환합니다.
**네임스페이스가 겹치는 프라이빗 호스팅 영역**
example.com 및 accounting.example.com 같이 네임스페이스가 중첩되는 프라이빗 호스팅 영역이 두 개 이상 있는 경우 VPC Resolver는 가장 구체적인 일치 항목을 기반으로 트래픽을 라우팅합니다.
프라이빗 호스팅 영역(example.com)과 동일한 도메인 이름에 대해 트래픽을 네트워크로 라우팅하는 Route 53 VPC Resolver 규칙이 있는 경우 VPC Resolver 규칙이 우선합니다. [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)을(를) 참조하세요.
사용자가 모든 프라이빗 호스팅 영역과 연결된 Amazon VPC의 EC2 인스턴스에 로그인하면 VPC Resolver가 DNS 쿼리를 처리하는 방법은 다음과 같습니다.
1. VPC Resolver는 accounting.example.com 같은 요청의 도메인 이름이 프라이빗 호스팅 영역 중 하나의 이름과 일치하는지 평가합니다.
1. 요청의 도메인 이름과 정확히 일치하는 호스팅 영역이 없는 경우 VPC Resolver는 요청의 도메인 이름 상위인 이름을 가진 호스팅 영역을 확인합니다. 예를 들어 요청에 있는 도메인 이름이 다음과 같다고 가정해 봅니다.
`seattle.accounting.example.com`
다음 호스팅 영역은 `seattle.accounting.example.com`의 상위 영역이므로 일치합니다.
+ `accounting.example.com`
+ `example.com`
VPC Resolver는 보다 구체적`accounting.example.com`이기 때문에를 선택합니다`example.com`.
1. VPC Resolver는 `accounting.example.com` 호스팅 영역에서에 대한 A 레코드와 같이 요청의 도메인 이름 및 DNS 유형과 일치하는 레코드를 검색합니다`seattle.accounting.example.com`.
요청의 도메인 이름 및 유형과 일치하는 레코드가 없는 경우 VPC Resolver는 NXDOMAIN(존재하지 않는 도메인)을 클라이언트에 반환합니다.
**프라이빗 호스팅 영역 및 Route 53 VPC Resolver 규칙**
프라이빗 호스팅 영역(example.com)과 동일한 도메인 이름의 네트워크로 트래픽을 라우팅하는 VPC Resolver 규칙이 있는 경우 VPC Resolver 규칙이 우선합니다.
예를 들어, 다음과 같은 구성이 있다고 가정합니다.
+ example.com이라는 프라이빗 호스팅 영역이 있고 VPC와 연결합니다.
+ example.com 트래픽을 네트워크로 전달하는 Route 53 VPC Resolver 규칙을 생성하고 규칙을 동일한 VPC와 연결합니다.
이 구성에서는 VPC Resolver 규칙이 프라이빗 호스팅 영역보다 우선합니다. DNS 쿼리는 프라이빗 호스팅 영역의 레코드를 기반으로 해결되지 않고 네트워크로 전달됩니다.
**하위 도메인에 대한 책임 위임**
이제 프라이빗 호스팅 영역에 NS 레코드를 생성하여 하위 도메인에 대한 책임을 위임할 수 있습니다. 자세한 내용은 [Resolver 위임 규칙 자습서](outbound-delegation-tutorial.md) 단원을 참조하십시오.
**사용자 지정 DNS 서버**
VPC의 Amazon EC2 인스턴스에 사용자 정의 DNS 서버를 구성한 경우 해당 VPC에 대해 Amazon에서 제공한 DNS 서버의 IP 주소로 프라이빗 DNS 쿼리를 라우팅하도록 DNS 서버를 구성해야 합니다. 이 IP 주소는 기본 VPC 네트워크 범위에 "2를 더한" 주소입니다. 예를 들어, VPC에 대한 CIDR 범위가 10.0.0.0/16인 경우 DNS 서버의 IP 주소는 10.0.0.2입니다.
VPCs와 네트워크 간에 DNS 쿼리를 라우팅하려면 VPC Resolver를 사용할 수 있습니다. 자세한 내용은 [Route 53 VPC Resolver란 무엇입니까?](resolver.md) 단원을 참조하십시오.
**필수 IAM 권한**
프라이빗 호스팅 영역을 만들려면 Route 53 작업에 대한 권한 외에도 Amazon EC2 작업에 대해 IAM 권한을 부여해야 합니다. 자세한 내용은 *서비스 권한 부여 참조*에서 [Route 53에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html)를 참조하세요.
# 프라이빗 호스팅 영역 생성
프라이빗 호스팅 영역이란 하나 이상의 Amazon Virtual Private Cloud(VPC)에서 호스팅하는 도메인의 레코드를 모아 둔 컨테이너입니다. 도메인(예: example.com)에 대한 호스팅 영역을 생성한 다음 레코드를 생성하여 VPC 내부 및 VPC 간에 트래픽을 라우팅하는 방식을 Amazon Route 53에 지시합니다.
**중요**
프라이빗 호스팅 영역을 생성할 때는 VPC와 호스팅 영역을 연결해야 합니다. 이때 호스팅 영역을 생성할 때 사용하는 것과 동일한 계정으로 생성한 VPC를 지정해야 합니다. 호스팅 영역을 생성한 후 다른 AWS 계정을 사용하여 생성한 VPCs 포함하여 추가 VPCs를 여기에 연결할 수 있습니다.
한 계정에서 생성한 VPC를 다른 계정에서 생성한 프라이빗 호스팅 영역과 연결하려면 먼저 연결 권한을 부여한 다음 프로그래밍 방식으로 연결해야 합니다. 자세한 내용은 [Amazon VPC와 다른 AWS 계정으로 생성한 프라이빗 호스팅 영역 연결](hosted-zone-private-associate-vpcs-different-accounts.md) 섹션을 참조하세요.
Route 53 API를 사용하여 프라이빗 호스팅 영역을 만드는 방법에 대한 자세한 내용은 [Amazon Route 53 API 참조](https://docs.aws.amazon.com/Route53/latest/APIReference/)를 참조하세요.
**Route 53 콘솔을 사용하여 프라이빗 호스팅 영역을 생성하려면**
1. Route 53 호스팅 영역과 연결할 각 VPC에 대해 다음과 같은 VPC 설정을 `true`로 변경합니다.
+ `enableDnsHostnames`
+ `enableDnsSupport`
자세한 내용은 *Amazon VPC 사용 설명서*의 [VPC에 대한 DNS 지원 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)를 참조하세요.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. Route 53를 처음 사용하는 경우 **시작하기(Get started)**를 선택합니다.
Route 53를 이미 사용하고 있는 경우 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
1. **프라이빗 호스팅 영역 생성(Create private hosted zone)** 창에서 도메인 이름과 함께 필요한 설명을 입력합니다.
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하세요.
1. **유형(Type)** 목록에서 **프라이빗 호스팅 영역(Private hosted zone)**을 선택합니다.
1. **VPC ID** 목록에서 호스팅 영역과 연결할 VPC를 선택합니다.
**참고**
콘솔에 다음과 같은 메시지가 표시되면 동일한 VPC 내에서 다른 호스팅 영역과 동일한 네임스페이스를 사용하는 호스팅 영역과 연결하는 것을 의미합니다.
"충돌하는 도메인이 이미 지정된 VPC 또는 위임 세트와 연결되어 있습니다."
예를 들어 호스팅 영역 A와 호스팅 영역 B 둘 다 동일한 도메인 이름(예: `example.com`)을 갖는 경우 두 호스팅 영역을 모두 동일한 VPC와 연결할 수는 없습니다.
1. **호스팅 영역 생성(Create hosted zone)**을 선택합니다.
# 프라이빗 호스팅 영역 나열
Amazon Route 53 콘솔을 사용하여 현재 AWS 계정으로 생성한 모든 호스팅 영역을 나열할 수 있습니다. Route 53 API를 사용하여 호스팅 영역을 나열하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)를 참조하세요.
**AWS 계정과 연결된 호스팅 영역을 나열하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
**호스팅 영역** 페이지에는 현재 AWS 계정을 사용하여 생성된 모든 호스팅 영역의 목록이 자동으로 표시됩니다. [**Type**] 열의 정보로 호스팅 영역이 프라이빗인지 혹은 퍼블릭인지 알 수 있습니다. 열 머리글을 선택하여 모든 프라이빗 호스팅 영역 및 모든 퍼블릭 호스팅 영역을 그룹화합니다.
# 더 많은 VPC를 프라이빗 호스팅 영역에 연결
동일한 AWS 계정을 사용하여 호스팅 영역과 VPCs를 생성한 경우 Amazon Route 53 콘솔을 사용하여 더 많은 VPCs를 프라이빗 호스팅 영역과 연결할 수 있습니다.
**중요**
한 계정에서 생성한 VPC를 다른 계정에서 생성한 프라이빗 호스팅 영역과 연결하려면 먼저 연결 권한을 부여해야 합니다. 또한 연결 권한을 부여하거나 VPC와 호스팅 영역을 연결하는 경우 AWS 콘솔을 사용할 수 없습니다. 자세한 내용은 [Amazon VPC와 다른 AWS 계정으로 생성한 프라이빗 호스팅 영역 연결](hosted-zone-private-associate-vpcs-different-accounts.md) 섹션을 참조하세요.
Route 53 API를 사용하여 더 많은 VPC를 프라이빗 호스팅 영역에 연결하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html)을 참조하세요.
**Route 53 콘솔을 사용하여 프라이빗 호스팅 영역에 VPC를 추가로 연결하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. VPC를 추가로 연결할 프라이빗 호스팅 영역의 라디오 버튼을 선택합니다.
1. **편집**을 선택합니다.
1. **VPC 추가**를 선택합니다.
1. 이 호스팅 영역과 연결할 VPC의 ID 및 리전을 선택합니다.
1. 이 호스팅 영역에 VPC를 더 많이 연결하려면 5단계 및 6단계를 반복합니다.
1. **변경 사항 저장**을 선택합니다.
# Amazon VPC와 다른 AWS 계정으로 생성한 프라이빗 호스팅 영역 연결
한 AWS 계정으로 생성한 VPC를 다른 계정으로 생성한 프라이빗 호스팅 영역과 연결하려면 다음 절차를 수행합니다.
**Amazon VPC와 다른 AWS 계정에서 생성한 프라이빗 호스팅 영역을 연결하려면**
1. 호스팅 영역을 생성한 계정에서 다음 방법 중 한 가지를 사용하여 VPC와 프라이빗 호스팅 영역의 연결 권한을 부여합니다.
+ **AWS CLI** - *AWS CLI 명령 참조*의 [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html)을 참조하세요.
+ ** AWS SDK** 또는 **AWS Tools for Windows PowerShell** - 설명서 페이지에서 해당 [AWS설명서를](https://docs.aws.amazon.com/) 참조하세요.
+ **Amazon Route 53 API** - *Amazon Route 53 API 참조*의 [CreateVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) 참조
다음 사항에 유의하세요.
+ 한 계정에서 생성한 다수의 VPC를 다른 계정에서 생성한 호스팅 영역과 연결하려면 각 VPC마다 권한 부여 요청을 하나씩 제출해야 합니다.
+ 연결 권한을 부여할 때는 호스팅 영역 ID를 지정해야 합니다. 따라서 이미 존재하는 프라이빗 호스팅 영역이어야 합니다.
+ VPC와 프라이빗 호스팅 영역의 연결 권한을 부여하거나, 둘을 서로 연결하는 경우 Route 53 콘솔을 사용할 수 없습니다.
1. VPC를 생성한 계정에서 VPC와 호스팅 영역을 연결합니다. 연결 권한 부여와 마찬가지로 AWS SDK, Tools for Windows PowerShell AWS CLI, 또는 Route 53 API를 사용할 수 있습니다. 예를 들어 API를 사용할 경우에는 [AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) 작업을 사용하십시오.
1. *권장 사항* – VPC와 호스팅 영역을 연결할 수 있는 권한을 삭제합니다. 권한을 삭제하더라도 연결에는 아무런 영향도 미치지 않으며, 오히려 향후 VPC와 호스팅 영역을 다시 연결하는 일을 방지할 수 있습니다. VPC와 호스팅 영역을 다시 연결하려면 이번 절차에서 1 및 2단계를 반복해야 하기 때문입니다.
**중요**
`ListHostedZonesByVPC`는 VPC가 지정된 호스팅 영역을 반환하고 `GetHostedZone` API는 호스팅 영역에 연결된 VPC를 반환합니다. 이러한 API는 `AssociateVPCWithHostedZone` API에 의해 생성되거나 프라이빗 호스팅 영역이 생성될 때 호스팅 영역과 VPC 연결만 고려합니다. VPC에 대한 호스팅 영역 연결의 전체 목록을 보려면 [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html)를 호출합니다.
**참고**
생성 가능한 최대 권한 수는 [엔터티에 대한 할당량](DNSLimitations.md#limits-api-entities) 단원을 참조하십시오.
# 프라이빗 호스팅 영역에서 VPC 연결 해제
Amazon Route 53 콘솔을 사용하여 프라이빗 호스팅 영역에서 VPC를 연결 해제할 수 있습니다. 이렇게 하면 Route 53가 VPC에서 시작되는 DNS 쿼리에 대해 호스팅 영역의 레코드를 사용하여 트래픽 라우팅을 중지합니다. 예를 들어 example.com 호스팅 영역이 VPC와 연결되어 있는 상태에서 해당 VPC에서 호스팅 영역을 연결 해제하면 Route 53가 example.com 또는 example.com 호스팅 영역의 다른 레코드에 대한 DNS 쿼리 해석을 중지합니다.
**참고**
프라이빗 호스팅 영역에서 마지막 VPC의 연결은 해제할 수 없습니다. 해당 VPC의 연결을 해제하려면 먼저 다른 VPC를 호스팅 영역과 연결해야 합니다.
**프라이빗 호스팅 영역에서 VPC를 연결 해제하는 방법**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. 하나 이상의 VPC를 연결 해제할 프라이빗 호스팅 영역의 라디오 버튼을 선택합니다.
1. **편집**을 선택합니다.
1. 이 호스팅 영역에서 연결을 해제할 VPC 옆에 표시된 **VPC 제거**를 선택합니다.
1. **변경 사항 저장**을 선택합니다.
# 프라이빗 호스팅 영역 삭제
이 섹션에서는 Amazon Route 53 콘솔을 사용하여 프라이빗 호스팅 영역을 삭제하는 방법을 설명합니다.
기본 SOA 및 NS 레코드 이외의 레코드가 없는 경우에만 프라이빗 호스팅 영역을 삭제할 수 있습니다. 호스팅 영역에 다른 레코드가 포함되어 있는 경우, 호스팅 영역을 삭제하기 전에 이를 삭제해야 합니다. 이를 통해 레코드를 포함하고 있는 호스팅 영역을 실수로 삭제하는 일을 방지할 수 있습니다.
**Topics**
+ [다른 서비스에서 생성한 프라이빗 호스팅 영역 삭제](#delete-private-hosted-zone-created-by-another-service)
+ [Route 53 콘솔을 사용하여 프라이빗 호스팅 영역 삭제](#delete-private-hosted-zone-procedure)
## 다른 서비스에서 생성한 프라이빗 호스팅 영역 삭제
프라이빗 호스팅 영역이 다른 서비스에서 생성된 경우에는 Route 53 콘솔을 사용하여 삭제할 수 없습니다. 대신 다른 서비스에 대한 해당 프로세스를 사용해야 합니다.
+ **AWS Cloud Map** - 프라이빗 DNS 네임스페이스를 생성할 때가 AWS Cloud Map 생성한 호스팅 영역을 삭제하려면 네임스페이스를 삭제합니다. 호스팅 영역을 자동으로 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. 삭제할 호스팅 영역에 NS 및 SOA 레코드만 포함되어 있는지 확인합니다. 다른 레코드가 있는 경우 다음과 같이 삭제합니다.
1. 삭제할 호스팅 영역의 이름을 선택합니다.
1. **레코드(Record)** 페이지에서 레코드 목록에 **유형(Type)** 열의 값이 **NS** 또는 **SOA** 이외의 레코드가 포함되어 있는 경우, 해당 행을 선택한 다음 **삭제(Delete)**를 선택합니다.
연속된 여러 레코드를 선택하려면 첫 번째 행을 선택한 다음, [**Shift**] 키를 누른 상태에서 마지막 행을 선택합니다. 비연속적인 여러 레코드를 선택하려면 첫 번째 행을 선택한 다음, [**Ctrl**] 키를 누른 상태에서 나머지 행을 선택합니다.
1. [Hosted Zones] 페이지에서 삭제할 호스팅 영역의 행을 선택합니다.
1. **삭제**를 선택합니다.
1. 확인 키를 입력하고 **삭제(Delete)**를 선택합니다.
# VPC 권한
VPC 권한은 자격 증명 및 액세스 관리(IAM) 정책 조건을 사용하여 [AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html), [DisassociateVPCFromHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisassociateVPCFromHostedZone.html), [CreateVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html), [DeleteVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html), [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html), [ListHostedZonesByVPC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZonesByVPC.html) API를 사용할 때 VPC에 대한 세분화된 권한을 설정할 수 있습니다.
IAM 정책 조건인를 `route53:VPCs`사용하면 다른 AWS 사용자에게 세분화된 관리 권한을 부여할 수 있습니다. 이렇게 하면 호스팅 영역을 연결하거나, 호스팅 영역을 연결 해제하거나, VPC 연결 권한을 생성하거나, VPC 연결 권한을 삭제하거나, 호스팅 영역을 생성하거나, 호스팅 영역을 나열할 수 있는 권한을 다른 사람에게 부여할 수 있습니다.
+ 단일 VPC.
+ 동일한 리전 내의 모든 VPC.
+ 다중 VPC.
VPC 권한에 대한 자세한 내용은 [IAM 정책 조건을 사용하여 세분화된 액세스 제어 구현](specifying-conditions-route53.md) 섹션을 참조하세요.
AWS 사용자를 인증하는 방법은 단원을 참조[ID를 통한 인증](security-iam.md#security_iam_authentication)하고 Route 53 리소스에 대한 액세스를 제어하는 방법은 단원을 참조하십시오[액세스 관리](security-iam.md#access-control).
# 호스팅 영역을 다른 AWS 계정으로 마이그레이션
호스팅 영역을 다른 로 마이그레이션할 때는 다음 권장 단계를 AWS 계정따르세요.
이 단계들은 레코드가 자주 변경되지 않는 호스팅 영역에 가장 적합합니다. 레코드 업데이트가 빈번한 호스팅 영역의 경우 다음을 고려합니다.
+ 마이그레이션 중에 리소스 레코드를 업데이트하지 않습니다.
+ 위임이 전송된 후 이전 호스팅 영역과 새 호스팅 영역 모두에 리소스 레코드 변경을 게시합니다.
**사전 조건**
AWS CLI설치 또는 업그레이드
다운로드, 설치 및 구성에 대한 자세한 내용은 [AWS Command Line Interface 사용 설명서를](https://docs.aws.amazon.com/cli/latest/userguide/) AWS CLI참조하세요.
**참고**
호스팅 영역을 생성한 계정과 호스팅 영역을 마이그레이션할 대상 계정을 모두 사용 중일 때는 CLI를 사용할 수 있도록 구성하십시오. 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)을 참조하세요.
이미를 사용하고 있는 경우 CLI 명령이 최신 Route 53 기능을 지원하도록 최신 버전의 CLI로 업그레이드하는 AWS CLI것이 좋습니다.
**Topics**
+ [1단계: 마이그레이션 준비](#hosted-zones-migrating-prepare)
+ [2단계: 새 호스팅 영역 생성](#hosted-zones-migrating-create-hosted-zone)
+ [3단계: (선택 사항) 상태 확인 마이그레이션](#hosted-zones-migrating-health-checks)
+ [4단계: 이전 호스팅 영역에서 새 호스팅 영역으로 레코드 마이그레이션](#hosted-zones-migrating-old-to-new)
+ [5단계: 이전 호스팅 영역과 새 호스팅 영역의 레코드 비교](#hosted-zones-migrating-compare)
+ [6단계: 새 호스팅 영역에 이름 서버를 사용하도록 도메인 등록 업데이트](#hosted-zones-migrating-update-domain)
+ [7단계: NS 레코드의 TTL을 더 높은 값으로 다시 변경](#hosted-zones-migrating-change-ttl)
+ [8단계: DNSSEC 서명 재활성화 및 신뢰 체인 설정(필요한 경우)](#hosted-zones-migrating-enable-dnssec)
+ [9단계: (선택 사항) 이전 호스팅 영역 삭제](#hosted-zones-migrating-delete-old-hosted-zone)
## 1단계: 마이그레이션 준비
준비 단계는 호스팅 영역 마이그레이션과 관련된 위험을 최소화하는 데 도움이 됩니다.
**1. 영역 가용성 모니터링**
영역의 도메인 이름 가용성을 모니터링할 수 있습니다. 이는 마이그레이션 롤백으로 이어질 수 있는 문제를 해결하는 데 도움이 될 수 있습니다. CloudWatch나 쿼리 로깅을 사용하여 대부분의 트래픽에서 도메인 이름을 모니터링할 수 있습니다. 쿼리 로깅 역할 설정에 대한 자세한 내용은 [Amazon Route 53 모니터링](monitoring-overview.md) 단원을 참조하세요.
모니터링은 셸 스크립트 또는 서드 파티 서비스를 통해 수행할 수 있습니다. 그러나 도메인을 사용할 수 없어서 고객에게 피드백을 받을 수도 있으므로 이것이 롤백이 필요한지 여부를 결정하는 유일한 신호는 아닙니다.
**2. TTL 설정 낮추기**
레코드에 대한 TTL(Time To Live) 설정으로 DNS 해석기가 얼마나 오랫동안 레코드를 캐시하고 캐시한 정보를 사용하도록 할지 지정합니다. TTL이 만료되면 해석기가 도메인의 DNS 서비스 공급자에게 최신 정보를 획득하라는 다른 쿼리를 전송합니다.
NS 레코드에 대한 일반적인 TTL 설정은 172,800초 또는 2일입니다. NS 레코드는 Domain Name System(DNS)이 도메인에 대한 트래픽 라우팅 방법에 대한 정보를 가져오는 데 사용할 수 있는 이름 서버를 나열합니다. 현재 DNS 서비스 공급자와 Route 53를 둘 다 사용하여 NS 레코드에 대한 TTL을 낮추면 DNS를 Route 53로 마이그레이션하는 동안 문제를 발견하는 경우 도메인의 가동 중지 시간이 감소합니다. TTL을 낮추지 않을 경우 뭔가 문제가 있을 때 최장 2일간 인터넷에서 도메인에 접속할 수 없을 수 있습니다.
**TTL 낮추기**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택합니다.
1. 호스팅 영역의 이름을 선택합니다.
1. NS 레코드를 선택하고 **레코드 세부 정보** 창에서 **레코드 편집**을 선택합니다.
1. [**TTL (Seconds)**]의 값을 변경합니다. 60초에서 900초(15분) 사이의 값을 지정하는 것이 좋습니다.
1. **저장**을 선택합니다.
**3. 상위 영역에서 DS 레코드 제거(DNSSEC를 구성한 경우)**
도메인에 대해 DNSSEC를 구성한 경우 도메인을 Route 53로 마이그레이션하기 전에 상위 영역에서 DS(Delegation Signer) 레코드를 제거합니다.
상위 영역이 Route 53를 통해 호스팅되는 경우 [도메인의 퍼블릭 키 삭제](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys)에서 자세한 내용을 참조하세요. 상위 영역이 다른 등록 기관에 호스팅되는 경우, 해당되는 등록 기관에 연락해 DS 레코드를 제거합니다.
Route 53는 현재 DNSSEC 설정 마이그레이션을 지원하지 않습니다. 따라서 마이그레이션 전에 상위 영역에서 DS 레코드를 제거하여 도메인에 대해 수행된 DNSSEC 검증을 비활성화해야 합니다. 마이그레이션 후에 새 호스팅 영역에서 DNSSEC를 구성하고 상위 영역에 각 DS 레코드를 추가하여 DNSSEC 검증을 다시 활성화할 수 있습니다.
**4. 마이그레이션 호스팅 영역에 의존하는 다른 진행 중인 작업이 없는지 확인**
일부 작업은 호스팅 영역 마이그레이션 시 DNS 확인을 사용합니다. 예를 들어 TLS/SSL 인증서 갱신 프로세스에 DNS 레코드 변경이 필요할 수 있으며 제공업체는 검증 방법으로 DNS 레코드를 확인하려고 시도합니다. 호스팅 영역 마이그레이션으로 인한 예기치 못한 영향을 피하려면 마이그레이션 전에 다른 작업이 발생하지 않는지 확인해야 합니다.
## 2단계: 새 호스팅 영역 생성
호스팅 영역을 마이그레이션할 계정에 새 호스팅 영역을 생성합니다.
AWS CLI 또는 콘솔에 대한 지침을 보려면 탭을 선택합니다.
+ [CLI](#migrate-hz-cli)
+ [콘솔](#migrate-hz-console)
------
#### [ CLI ]
다음 명령을 입력합니다.
```
aws route53 create-hosted-zone \
--name $hosted_zone_name \
--caller-reference $unique_string
```
자세한 내용은 [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html)을 참조하세요.
------
#### [ Console ]
**다른 계정을 사용하여 새 호스팅 영역을 생성하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
호스팅 영역을 마이그레이션하려는 대상 계정에 대해 계정 자격 증명으로 로그인하십시오.
1. 호스팅 영역 생성. 자세한 내용은 [퍼블릭 호스팅 영역 생성](CreatingHostedZone.md) 섹션을 참조하세요.
1. 호스팅 영역 ID를 기록해 둡니다. 경우에 따라 이 프로세스 후반부에 이 정보가 필요할 것입니다.
1. Route 53 콘솔에서 로그아웃합니다.
준비 1단계 TTL 설정 낮추기에서 TTL 설정을 낮춘 것과 마찬가지로 새 영역의 NS TTL도 낮춥니다.
------
## 3단계: (선택 사항) 상태 확인 마이그레이션
새 계정의 DNS 레코드를 마이그레이션하려는 계정의 Route 53 상태 확인과 연결할 수 있습니다. Route 53 상태 확인을 마이그레이션하려면 기존 계정과 동일한 구성으로 새 계정에서 새 상태 확인을 생성해야 합니다. 자세한 내용은 [Amazon Route 53 상태 확인 생성](dns-failover.md) 단원을 참조하십시오.
## 4단계: 이전 호스팅 영역에서 새 호스팅 영역으로 레코드 마이그레이션
콘솔 또는를 사용하여에서 다른 로 레코드를 마이그레이션 AWS 계정 할 수 있습니다 AWS CLI.
------
#### [ Console ]
영역에 레코드가 단 몇 개만 포함된 경우 Route 53 콘솔을 사용하여 이전 영역의 레코드를 나열하고, 이를 기록해 둔 다음 새 영역에 레코드를 생성하는 것이 좋습니다. [3단계: (선택 사항) 상태 확인 마이그레이션](#hosted-zones-migrating-health-checks)에서 상태 확인을 마이그레이션했다면 새 호스팅 영역에서 레코드를 생성할 때 새 상태 확인 ID를 지정해야 합니다. 자세한 내용은 다음 항목을 참조하세요.
+ [레코드 나열](resource-record-sets-listing.md)
+ [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md)
+ [DNS 장애 조치 구성](dns-failover-configuring.md)
1단계에서 TTL 설정을 낮춘 것과 마찬가지로 새 영역에서도 NS TTL을 낮춰야 합니다.
------
#### [ CLI ]
영역에 많은 수의 레코드가 포함된 경우 마이그레이션할 레코드를 파일로 내보내고 파일을 편집한 후 편집된 파일을 사용하여 새 호스팅 영역에 레코드를 만들 수 있습니다. 다음 절차에서는 AWS CLI 명령을 사용하지만 타사 도구도이 용도로 사용할 수 있습니다.
****
1. 다음 명령을 실행합니다.
```
aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file
```
다음 사항에 유의하세요.
+ *hosted-zone-id*의 경우 마이그레이션하려는 레코드가 포함된 이전 호스팅 영역의 ID를 지정합니다.
+ *path-to-output-file*의 경우 출력을 저장하고 싶은 디렉터리 경로와 파일 이름을 지정하십시오.
+ `>` 문자를 사용해 지정한 파일로 출력을 보낼 수 있습니다.
+ 는 100개가 넘는 레코드가 포함된 호스팅 영역의 페이지 매김을 AWS CLI 자동으로 처리합니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*[의 AWS 명령줄 인터페이스의 페이지 매김 옵션 사용을 참조하세요](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html).
다른 프로그래밍 방법을 사용하여 AWS SDKs 중 하나와 같은 레코드를 나열하는 경우 결과 페이지당 최대 100개의 레코드를 얻을 수 있습니다. 호스팅 영역에 100개를 초과하는 레코드가 있을 경우 모든 레코드를 나열하려면 복수의 요청을 제출해야 합니다.
이 출력의 복사본을 만듭니다. 새 호스팅 영역에서 레코드를 생성한 후에는 새 호스팅 영역에서 명령을 실행 AWS CLI `list-resource-record-sets`하고 두 출력을 비교하여 모든 레코드가 생성되었는지 확인하는 것이 좋습니다.
1. 마이그레이션하려는 레코드를 편집합니다.
내보낸 파일을 편집한 후에 `change-resource-record-sets` 명령으로 파일을 사용할 수 있습니다. 텍스트 편집기에서 검색 및 바꾸기 기능을 사용하여 변경할 수 있습니다.
**참고**
다음 단계에서는 텍스트 편집기를 사용한 수동 편집에 대해 설명합니다. 고급 사용자는 jq, Python 또는 기타 스크립팅 언어와 같은 프로그래밍 도구를 사용하여 이러한 변환을 자동화할 수 있습니다.
이 절차의 1단계에서 생성한, 마이그레이션하려는 레코드가 포함된 파일의 사본을 열고 다음과 같이 변경합니다.
+ 파일 상단의 ResourceRecordSets 요소를 `Changes` 요소로 바꿉니다.
+ 선택 사항 - `Comment` 요소를 추가합니다.
+ 호스팅 영역 이름의 NS 및 SOA 레코드와 관련된 줄을 삭제합니다. 새 호스팅 영역에 이미 해당 레코드가 있습니다.
+ 각 레코드마다 `Action` 및 `ResourceRecordSets` 요소를 추가하고 필요에 따라 여는 괄호와 닫는 괄호(`{ }`)를 추가하여 JSON 코드를 유효하게 만듭니다.
**참고**
중괄호와 대괄호가 알맞은 곳에 있는지 확인하려면 JSON 검사기를 사용할 수 있습니다. 온라인 JSON 검사기를 찾으려면 브라우저에서 "JSON 검사기"를 검색합니다.
+ 호스팅 영역에 같은 호스팅 영역에 있는 다른 레코드를 참조하는 별칭이 포함되어 있을 경우 다음과 같이 변경하십시오.
+ 호스팅 영역의 ID를 새 호스팅 영역의 ID로 변경하십시오.
**중요**
별칭 레코드가 다른 리소스(예: 로드 밸런서)를 가리키는 경우 호스팅 영역 ID를 도메인의 호스팅 영역 ID로 변경하지 마세요. 호스팅 영역 ID를 실수로 변경하는 경우 호스팅 영역 ID를 도메인의 호스팅 영역 ID가 아닌 리소스 자체의 호스팅 영역 ID로 롤백합니다. 리소스 호스팅 영역 ID는 리소스가 생성된 AWS 콘솔에서 찾을 수 있습니다.
+ 파일의 맨 아래로 별칭 레코드를 이동합니다. Route 53는 별칭 레코드가 참조하는 레코드를 먼저 생성해야 별칭 레코드를 생성할 수 있습니다.
**중요**
하나 이상의 별칭 레코드가 다른 별칭 레코드를 참조하는 경우 별칭 대상인 레코드는 파일에서 참조하는 별칭 레코드 앞에 나와야 합니다. 예를 들어, `alias.example.com`이 `alias.alias.example.com`의 별칭 대상인 경우 `alias.example.com`이 파일에서 먼저 나와야 합니다.
+ 트래픽을 트래픽 정책 인스턴스로 라우팅하는 별칭 레코드를 모두 삭제하십시오. 이후에 레코드를 다시 생성할 수 있도록 기록해 두십시오.
+ [3단계: (선택 사항) 상태 확인 마이그레이션](#hosted-zones-migrating-health-checks)에서 상태 확인을 마이그레이션했다면 새로 생성된 상태 확인 ID와 연결되도록 레코드를 변경합니다.
다음 예제에서는 example.com에 대한 호스팅 영역을 위한 레코드의 편집된 버전을 보여줍니다. 빨간색 기울임꼴 텍스트가 새로운 내용입니다.
```
{
"Comment": "string",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet":{
"ResourceRecords": [
{
"Value": "192.0.2.4"
},
{
"Value": "192.0.2.5"
},
{
"Value": "192.0.2.6"
}
],
"Type": "A",
"Name": "route53documentation.com.",
"TTL": 300
}
},
{
"Action": "CREATE",
"ResourceRecordSet":{
"AliasTarget": {
"HostedZoneId": "Z3BJ6K6RIION7M",
"EvaluateTargetHealth": false,
"DNSName": "s3-website-us-west-2.amazonaws.com."
},
"Type": "A",
"Name": "www.route53documentation.com."
}
}
]
}
```
1. 큰 파일을 여러 작은 파일로 분할
레코드가 많이 있거나 값이 많은 레코드(예: 많은 IP 주소)가 있을 경우 파일을 여러 작은 파일로 분할해야 할 수 있습니다. 최대값은 다음과 같습니다.
+ 각 파일에는 최대 1,000개의 레코드가 포함될 수 있습니다.
+ 모든 `Value` 요소에서 값의 최대 총 길이는 32,000바이트입니다.
1. 새 호스팅 영역에 레코드 생성
다음 CLI를 입력합니다.
```
aws route53 change-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--change-batch file://path-to-file-that-contains-records
```
다음 값을 지정하세요.
+ `new-hosted-zone-id`의 경우 새 호스팅 영역의 ID를 지정합니다.
+ `path-to-file-that-contains-records`의 경우 이전 단계에서 편집한 디렉터리 경로와 파일 이름을 지정합니다.
트래픽을 트래픽 정책 인스턴스로 라우팅하는 별칭 레코드를 모두 삭제한 경우 Route 53 콘솔을 사용하여 별칭 레코드를 다시 생성하세요. 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 단원을 참조하십시오.
------
## 5단계: 이전 호스팅 영역과 새 호스팅 영역의 레코드 비교
새 호스팅 영역에 모든 레코드를 올바로 생성했음을 확인하려면 다음 CLI 명령을 입력해 새 호스팅 영역의 레코드를 나열하고 이전 호스팅 영역의 레코드 목록과 출력 내용을 비교합니다.
```
aws route53 list-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--output json > path-to-output-file
```
다음 값을 지정하세요.
+ `new-hosted-zone-id`의 경우 새 호스팅 영역의 ID를 지정합니다.
+ `path-to-output-file`의 경우 출력을 저장하고 싶은 디렉터리 경로와 파일 이름을 지정합니다. 4단계에서 사용한 파일 이름과 다른 파일 이름을 사용합니다.
`>` 문자를 사용해 지정한 파일로 출력을 보낼 수 있습니다.
출력을 4단계의 출력과 비교합니다. NS 및 SOA 레코드의 값과 4단계에서 변경한 사항(예: 다른 호스팅 영역 ID 또는 도메인 이름) 외에도 이 두 출력 내용이 같아야 합니다.
새 호스팅 영역의 레코드가 기존 호스팅 영역의 레코드와 일치하지 않을 경우 다음 중 하나를 수행합니다.
+ Route 53 콘솔을 사용하여 사소한 사항을 수정하세요. 자세한 내용은 [레코드 편집](resource-record-sets-editing.md) 단원을 참조하십시오.
+ 새 호스팅 영역에서 NS 및 SOA 레코드를 제외한 모든 레코드를 삭제하고 4단계의 절차를 반복합니다.
## 6단계: 새 호스팅 영역에 이름 서버를 사용하도록 도메인 등록 업데이트
새 호스팅 영역으로의 레코드 마이그레이션을 마치면 새 호스팅 영역을 위한 이름 서버를 사용하도록 도메인 등록의 이름 서버를 변경합니다. 자세한 내용은 Amazon Route 53를 기존 도메인의 DNS 서비스로 지정 섹션을 참조하세요.
호스팅 영역이 사용 중인 경우 - 예를 들어 사용자가 도메인 이름을 사용하여 웹 사이트를 찾거나 웹 애플리케이션에 액세스하는 경우 웹 사이트 또는 애플리케이션 트래픽, 이메일 등을 포함하여 호스팅 영역의 트래픽과 가용성을 계속 모니터링해야 합니다.
+ **트래픽이 느려지거나 중지되는 경우** - 도메인 등록의 이름 서버를 이전 호스팅 영역의 이전 이름 서버로 다시 변경합니다. 그런 다음 문제를 알아냅니다.
+ **트래픽이 영향을 받지 않는 경우** - 다음 단계로 계속 진행합니다.
## 7단계: NS 레코드의 TTL을 더 높은 값으로 다시 변경
새 호스팅 영역에서 NS 레코드의 TTL을 더 일반적인 값으로 변경합니다(예: 172,800초(2일)). 그러면 종종 그랬듯이 DNS 해석기가 도메인의 이름 서버에 대한 쿼리를 보내기를 기다릴 필요가 없으므로 사용자 입장에서는 지연 시간이 짧아지는 효과가 있습니다.
**TTL 변경 방법**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택합니다.
1. 호스팅 영역의 이름을 선택합니다.
1. NS 레코드를 선택하고 **레코드 세부 정보** 창에서 **레코드 편집**을 선택합니다.
1. **TTL(초)** 값을 DNS 해석기가 도메인의 이름 서버의 이름을 캐시하도록 할 시간(초)으로 변경합니다. 172,800초의 값을 권장합니다.
1. **저장**을 선택합니다.
## 8단계: DNSSEC 서명 재활성화 및 신뢰 체인 설정(필요한 경우)
다음 두 단계로 DNSSEC 서명을 다시 활성화할 수 있습니다.
1. Route 53에 대해 DNSSEC 서명을 활성화하고, AWS Key Management Service의 고객 관리형 키를 기반으로 키 서명 키(KSK)를 Route 53에서 생성하도록 요청합니다.
1. DNS 응답이 신뢰할 수 있는 암호화 서명으로 인증될 수 있도록 상위 영역에 DS(Delegation Signer) 레코드를 추가하여 호스팅 영역에 대한 신뢰 체인을 만듭니다.
지침은 [DNSSEC 서명 활성화 및 신뢰 체인 설정](dns-configuring-dnssec-enable-signing.md) 섹션을 참조하세요.
## 9단계: (선택 사항) 이전 호스팅 영역 삭제
기존 호스팅 영역이 이제는 필요하지 않다고 확신할 때는 이를 선택적으로 삭제할 수 있습니다. 지침은 [퍼블릭 호스팅 영역 삭제](DeleteHostedZone.md) 섹션을 참조하세요.
**중요**
새 호스팅 영역에 대한 이름 서버를 사용하도록 도메인 등록을 업데이트한 후 적어도 48시간 동안 이전 호스팅 영역이나 해당 호스팅 영역에서 레코드를 삭제하지 마십시오. DNS 해석기가 해당 호스팅 영역의 레코드 사용을 중지하기 전에 이전의 호스팅 영역을 삭제하면, 해석기가 새 호스팅 영역을 사용하기 시작할 때까지 인터넷에서 도메인을 사용할 수 없게 됩니다.
# 레코드 작업
example.com과 같은 도메인에 대해 호스팅 영역을 생성한 후, 트래픽을 도메인에 라우팅하는 방식을 Domain Name System(DNS)에 알려줄 레코드를 생성합니다.
예를 들어, DNS가 다음 작업을 수행하도록 만드는 레코드를 생성할 수도 있습니다.
+ example.com에 대한 인터넷 트래픽을 데이터 센터에 있는 호스트의 IP 주소로 라우팅하기.
+ 도메인에 대한 이메일(ichiro@example.com)을 메일 서버(mail.example.com)로 라우팅하기.
+ operations.tokyo.example.com이라는 하위 도메인에 대한 트래픽을 다른 호스트의 IP 주소로 라우팅하기.
각 레코드에는 도메인 또는 하위 도메인의 이름, 레코드 유형(예: MX 유형의 레코드는 이메일을 라우팅), 그리고 레코드 유형에 해당되는 다른 정보(MX 레코드의 경우, 1개 이상의 메일 서버의 호스트 이름과 각 서버에 대한 우선 순위)가 담겨 있습니다. 다양한 레코드 유형에 대한 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
호스팅 영역에 있는 각 레코드의 이름은 반드시 호스팅 영역의 이름으로 끝나야 합니다. 예를 들어, example.com 호스팅 영역은 www.example.com 및 accounting.tokyo.example.com 하위 도메인에 대한 레코드를 포함할 수 있지만 www.example.ca 하위 도메인에 대한 레코드는 포함할 수 없습니다.
**참고**
복잡한 라우팅 구성에 대한 레코드를 만들려면 Traffic Flow 시각적 편집기를 사용하고 구성을 트래픽 정책으로 저장할 수도 있습니다. 그런 다음 동일한 호스팅 영역이나 여러 호스팅 영역의 하나 이상의 도메인 이름(예: example.com) 또는 하위 도메인 이름(예: www.example.com)과 해당 트래픽 정책을 연결할 수 있습니다. 새 구성이 예상대로 수행되지 않을 경우 업데이트를 롤백할 수도 있습니다. 자세한 내용은 [트래픽 흐름을 사용하여 DNS 트래픽 라우팅](traffic-flow.md) 단원을 참조하십시오.
Amazon Route 53는 호스팅 영역에 추가하는 레코드에 대해서는 요금을 부과하지 않습니다. 호스팅 영역에 생성할 수 있는 최대 레코드 수에 대한 자세한 내용은 [할당량](DNSLimitations.md) 단원을 참조하십시오.
**Topics**
+ [라우팅 정책 선택](routing-policy.md)
+ [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md)
+ [지원되는 DNS 레코드 유형](ResourceRecordTypes.md)
+ [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md)
+ [리소스 레코드 세트 권한](resource-record-sets-permissions.md)
+ [Amazon Route 53 레코드를 생성 또는 편집할 때 지정하는 값](resource-record-sets-values.md)
+ [영역 파일을 가져와 레코드 생성](resource-record-sets-creating-import.md)
+ [레코드 편집](resource-record-sets-editing.md)
+ [레코드 삭제](resource-record-sets-deleting.md)
+ [레코드 나열](resource-record-sets-listing.md)
# 라우팅 정책 선택
레코드를 생성할 때 라우팅 정책을 선택하게 되는데, 이는 Amazon Route 53가 쿼리에 응답하는 방식을 결정합니다.
+ **단순 라우팅 정책(Simple routing policy)** - 도메인에 대해 특정 기능을 수행하는 하나의 리소스만 있는 경우(예: example.com 웹 사이트의 콘텐츠를 제공하는 하나의 웹 서버)에 사용합니다. 단순 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.
+ **장애 조치 라우팅 정책(Failover routing policy)** - 액티브-패시브 장애 조치를 구성하려는 경우에 사용합니다. 장애 조치 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.
+ **지리 위치 라우팅 정책(Geolocation routing policy)** - 사용자의 위치에 기반하여 트래픽을 라우팅하려는 경우에 사용합니다. 지리적 위치 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.
+ **지리 근접 라우팅 정책** - 리소스의 위치를 기반으로 트래픽을 라우팅하고 필요에 따라 한 위치의 리소스에서 다른 위치의 리소스로 트래픽을 보내려는 경우에 사용합니다. 지리 근접 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.
+ **지연 시간 라우팅 정책** - 여러에 리소스가 AWS 리전 있고 최상의 지연 시간을 제공하는 리전으로 트래픽을 라우팅하려는 경우에 사용합니다. 지연 시간 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.
+ **IP 기반 라우팅 정책** - 사용자의 위치에 기반하여 트래픽을 라우팅하고 트래픽이 시작되는 IP 주소가 있는 경우에 사용합니다.
+ **다중 응답 라우팅 정책(Multivalue answer routing policy)** - Route 53가 DNS 쿼리에 무작위로 선택된 최대 8개의 정상 레코드로 응답하게 하려는 경우에 사용합니다. 다중 값 응답 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.
+ **가중치 기반 라우팅 정책(Weighted routing policy)** - 사용자가 지정하는 비율에 따라 여러 리소스로 트래픽을 라우팅하려는 경우에 사용합니다. 가중치 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.
**Topics**
+ [단순 라우팅](routing-policy-simple.md)
+ [장애 조치 라우팅](routing-policy-failover.md)
+ [지리적 라우팅](routing-policy-geo.md)
+ [지리 근접 라우팅](routing-policy-geoproximity.md)
+ [지연 시간 기반 라우팅](routing-policy-latency.md)
+ [IP 기반 라우팅](routing-policy-ipbased.md)
+ [다중값 응답 라우팅](routing-policy-multivalue.md)
+ [가중치 기반 라우팅](routing-policy-weighted.md)
+ [Amazon Route 53에서 EDNS0을 사용하여 사용자의 위치를 예측하는 방법](routing-policy-edns0.md)
# 단순 라우팅
단순 라우팅에서는 가중치나 지연 시간 같은 특별한 Route 53 라우팅 없이 표준 DNS 레코드를 구성할 수 있습니다. 단순 라우팅에서는 보통 단일 리소스로 트래픽을 라우팅합니다. 예를 들면 웹 사이트에 대한 웹 서버로 라우팅합니다.
프라이빗 호스팅 영역의 레코드에 단순 라우팅 정책을 사용할 수 있습니다.
Route 53 콘솔에서 단순 라우팅 정책을 선택할 경우 동일한 이름과 유형을 가진 여러 레코드를 만들 수 없지만, 동일 레코드 안에 여러 값(예: 다중 IP 주소)을 지정할 수는 있습니다. (별칭 레코드에 대한 단순 라우팅 정책을 선택하는 경우 현재 호스팅 영역에서 하나의 AWS 리소스 또는 하나의 레코드만 지정할 수 있습니다.) 한 레코드에 다중 값을 지정한 경우 Route 53가 모든 값을 무작위 순서로 재귀적 해석기로 반환하며, 해석기는 DNS 쿼리를 제출한 클라이언트(웹 브라우저 같은)로 그 값을 반환합니다. 그러면 클라이언트가 값을 하나 선택하고 쿼리를 다시 제출합니다. 간단한 라우팅 정책을 사용하면 여러 IP 주소를 지정할 수 있지만 이러한 IP 주소의 상태는 확인되지 않습니다.
단순 라우팅 정책으로 레코드를 만들 때 지정하는 값에 대한 정보는 다음 주제를 참조하십시오.
+ [단순 레코드에 특정한 값](resource-record-sets-values-basic.md)
+ [단순 별칭 레코드에 특정한 값](resource-record-sets-values-alias.md)
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
# 장애 조치 라우팅
장애 조치 라우팅은 특정 리소스가 정상일 경우 해당 리소스로 트래픽을 라우팅하고 첫 번째 리소스가 비정상일 경우 다른 리소스로 트래픽을 라우팅합니다. 기본 및 보조 레코드는 웹 사이트로 구성되는 Amazon S3 버킷에서 복잡한 레코드 트리에 이르기까지 그 어느 것에도 트래픽을 라우팅할 수 있습니다. 자세한 내용은 [액티브-패시브 장애 조치](dns-failover-types.md#dns-failover-types-active-passive) 단원을 참조하십시오.
프라이빗 호스팅 영역의 레코드에 장애 조치 라우팅 정책을 사용할 수 있습니다.
장애 조치 라우팅 정책으로 레코드를 만들 때 지정하는 값에 대한 정보는 다음 주제를 참조하십시오.
+ [장애 조치 레코드에 특정한 값](resource-record-sets-values-failover.md)
+ [장애 조치 별칭 레코드에 특정한 값](resource-record-sets-values-failover-alias.md)
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
# 지리적 라우팅
지리적 라우팅을 사용하면 사용자의 지리 위치, 즉 DNS 쿼리가 발생하는 위치를 기반으로 트래픽을 제공하는 리소스를 선택할 수 있습니다. 예를 들어 유럽에서 발생하는 모든 쿼리를 프랑크푸르트 리전에 위치한 Elastic Load Balancing 로드 밸런서로 라우팅할 수 있습니다.
지리적 라우팅을 사용하는 경우, 콘텐츠를 지역화하고 웹 사이트의 일부 또는 전체를 사용자의 언어로 제공할 수 있습니다. 또한 지리적 라우팅을 사용하여 배포권이 있는 위치에서만 콘텐츠를 배포할 수 있도록 제한할 수 있습니다. 또한 예측 가능하고 간편하게 관리할 수 있는 방식으로 엔드포인트 간에 로드를 분산하는 데 사용함으로써, 사용자의 위치가 동일한 엔드포인트에 일관되게 라우팅되도록 할 수도 있습니다.
미국에서는 대륙, 국가 또는 주를 기준으로 지리적 위치를 지정할 수 있습니다. 중복되는 지리 리전에 대해 별도의 레코드를 생성하는 경우(예를 들면, 북미에 하나의 레코드, 캐나다에 하나의 레코드) 우선 순위는 가장 작은 지리 지역에 돌아갑니다. 이렇게 하면 한 대륙의 일부 쿼리를 하나의 리소스로 라우팅하고 그 대륙에서 선택된 여러 나라들의 쿼리는 다른 리소스로 라우팅할 수 있습니다. (각 대륙별 국가 목록은 다음([Location](resource-record-sets-values-geo.md#rrsets-values-geo-location))을 참조하십시오).
지리 위치는 IP 주소를 위치에 매핑하는 방식으로 작동합니다. 그러나 일부 IP 주소들은 지리 위치에 매핑되지 않으므로, 7개 대륙 전체를 포괄하는 지리 위치 레코드를 생성한다 해도 Amazon Route 53는 식별할 수 없는 위치에서 온 일부 DNS 쿼리를 수신합니다. 어떤 위치에도 매핑되지 않는 IP 주소로부터 온 쿼리, 그리고 지리 위치 레코드를 생성하지 않은 위치로부터 온 쿼리 모두를 처리하는 기본 레코드를 생성할 수 있습니다. 기본 레코드를 생성하지 않으면, Route 53는 그 위치에서 온 쿼리에 대해 "응답 없음(no answer)"을 반환합니다.
퍼블릭 및 프라이빗 호스팅 영역의 레코드의 지리적 위치 라우팅을 사용할 수 있습니다.
자세한 내용은 [Amazon Route 53에서 EDNS0을 사용하여 사용자의 위치를 예측하는 방법](routing-policy-edns0.md) 단원을 참조하십시오.
지리적 위치 라우팅 정책으로 레코드를 만들 때 지정하는 값에 대한 정보는 다음 주제를 참조하십시오.
+ [지리 위치 레코드에 특정한 값](resource-record-sets-values-geo.md)
+ [지리 위치 별칭 레코드에 특정한 값](resource-record-sets-values-geo-alias.md)
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
# 프라이빗 호스팅 영역의 지리적 위치 라우팅
프라이빗 호스팅 영역의 경우 Route 53는 쿼리가 시작된 VPC AWS 리전 의를 기반으로 DNS 쿼리에 응답합니다. 목록은 *Amazon EC2 사용 설명서*의 리전 및 영역을 AWS 리전참조하세요. [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)
DNS 쿼리가 하이브리드 네트워크의 온프레미스 부분에서 시작된 경우, DNS 쿼리는 VPC 있는 위치의 AWS 리전 에서 시작된 것으로 간주됩니다.
상태 확인을 포함하는 경우 다음에 대한 기본 레코드를 생성할 수 있습니다.
+ 지리적 위치에 매핑되지 않은 IP 주소.
+ 지리적 위치 레코드를 생성하지 않은 위치에서 오는 DNS 쿼리.
DNS 쿼리의 리전에 대한 지리적 위치 레코드가 비정상이면 기본 레코드(정상인 경우)가 반환됩니다.
다음 그림의 예제 구성에서 us-east-1 AWS 리전 (버지니아)에서 오는 DNS 쿼리는 1.1.1.1 엔드포인트로 라우팅됩니다.
![\[프라이빗 호스팅 영역에 대한 지리적 위치 레코드를 보여주는 스크린샷.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/geolocation-phz.png)
# 지리 근접 라우팅
Amazon Route 53는 지리 근접 라우팅을 사용하여 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅할 수 있습니다. 사용 가능한 가장 가까운 리소스로 트래픽을 라우팅합니다. 또는 *바이어스*라고 하는 값을 지정하여 해당 리소스로 라우팅하는 트래픽의 양을 늘리거나 줄일 수도 있습니다. 바이어스는 트래픽이 리소스로 라우팅되는 지리적 리전의 크기를 확장하거나 축소합니다.
리소스에 대한 지리 근접 규칙을 생성하고 각 규칙에 대해 다음 값 중 하나를 지정합니다.
+ AWS 리소스를 사용하는 경우 리소스를 생성한 AWS 리전 또는 로컬 영역 그룹을 지정합니다.
+ 리소스가 아닌 리소스를 사용하는 경우 리소스의 위도와 경도를AWS 지정합니다.
AWS 로컬 영역을 사용하려면 먼저 활성화해야 합니다. 자세한 내용은 *AWS Local Zones User Guide*의 [Getting started with Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html)를 참조하세요.
AWS 리전 와 로컬 영역의 차이점에 대해 알아보려면 *Amazon EC2 사용 설명서*의 [리전 및 영역을 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
Route 53가 트래픽을 리소스로 라우팅하는 지리적 리전의 크기를 선택적으로 변경하려면 바이어스에 대해 해당하는 값을 지정합니다.
+ Route 53가 트래픽을 리소스로 라우팅하는 지리적 리전의 크기를 확장하려면 바이어스에 대해 1\$199의 양의 정수를 지정합니다. Route 53는 인접 리전의 크기를 축소합니다.
+ Route 53가 트래픽을 리소스로 라우팅하는 지리적 리전의 크기를 축소하려면 바이어스에 대해 1\$199의 음의 바이어스를 지정합니다. Route 53는 인접 리전의 크기를 확장합니다.
**참고**
Route 53용 Traffic Flow 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다.
사용 중인 콘솔의 탭을 선택합니다.
+ [새로운 콘솔](#traffic-flow-geoprox-routing-map-new)
+ [이전 콘솔](#traffic-flow-geoprox-routing-map-old)
------
#### [ New console ]
다음 맵은 4개 AWS 리전 (1\$15번)를 보여줍니다.
1. 미국 서부(오리건)
1. 유럽(프랑크푸르트)
1. 아시아 태평양(도쿄)
1. 아프리카(케이프타운)
1. Middle East (Bahrain)
**참고**
맵은 Traffic Flow에서만 사용할 수 있습니다.
![\[AWS 리전 의 미국 서부(오리건), 유럽(프랑크푸르트), 아시아 태평양(도쿄), 아프리카(케이프타운), 중동(바레인)에 리소스에 대한 지리 근접성 레코드가 있을 때 트래픽이 라우팅되는 방식을 보여주는 세계 지도.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)
다음 지도를 보면 미국 서부(오리건) 리전(지도에서 **1**번)에 25개 이상의 바이어스를 추가하면 어떻게 되는지 알 수 있습니다. 이전과 달리 북미의 더 넓은 부분과 남미 전역에서 발생하는 트래픽이 해당 리전의 리소스로 라우팅됩니다.
![\[미국 동부(버지니아 북부) 리전에 25개 이상의 바이어스를 추가할 때 트래픽이 어떻게 라우팅되는지를 보여주는 세계 지도.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)
다음 지도를 보면 미국 서부(오리건) 리전의 바이어스를 25개 이하로 변경하면 어떻게 되는지 알 수 있습니다. 트래픽은 이전보다 북미 및 남아메리카의 더 작은 부분에서 해당 리전의 리소스로 라우팅되고, 더 많은 트래픽은 인접 리전 **2**, **3**, **4**의 리소스로 라우팅됩니다.
![\[미국 서부(오리건) 리전에 25개 이하의 바이어스를 추가할 때 트래픽이 어떻게 라우팅되는지를 보여주는 세계 지도.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)
------
#### [ Old console ]
다음 맵은 위도 및 경도 AWS 리전 (5)로 지정된 남아프리카 공화국 요하네스버그의 4개(1\$14번) 및 위치를 보여줍니다.
**참고**
맵은 Traffic Flow에서만 사용할 수 있습니다.
![\[미국 서부(오레곤), 미국 동부(버지니아 북부), 유럽(파리) 및 아시아 태평양(도쿄)의 리소스 AWS 리전 에 대한 지리 근접성 레코드가 있고 남아프리카 공화국 요하네스버그의 비AWS 리소스에 대한 레코드가 있을 때 트래픽이 라우팅되는 방식을 보여주는 세계 지도입니다.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)
다음 지도를 보면 미국 동부(버지니아 북부) 리전(지도에서 **2**번)에 25개 이상의 바이어스를 추가하면 어떻게 되는지 알 수 있습니다. 리소스로 트래픽이 라우팅되는 리전이 북미 지역은 전보다 많아지고, 남미는 모든 지역에서 이루어집니다.
![\[미국 동부(버지니아 북부) 리전에 25개 이상의 바이어스를 추가할 때 트래픽이 어떻게 라우팅되는지를 보여주는 세계 지도.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)
다음 지도를 보면 미국 동부(버지니아 북부) 리전의 바이어스를 25개 이하로 변경하면 어떻게 되는지 알 수 있습니다. 리소스로 트래픽이 라우팅되는 리전이 북미와 남미 지역은 이전보다 작아지고, 인접 리전 **1**, **3**, **5**의 리소스로 트래픽이 더 많이 라우팅됩니다.
![\[미국 동부(버지니아 북부) 리전에 25개 이하의 바이어스를 추가할 때 트래픽이 어떻게 라우팅되는지를 보여주는 세계 지도.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)
------
리소스에 대한 바이어스를 변경할 때의 효과는 다음을 포함하여 여러 요인에 따라 달라집니다.
+ 보유한 리소스의 수.
+ 리소스가 서로 근접한 정도.
+ 지리적 리전 간의 경계 영역 근처에 있는 사용자의 수. 예를 들어 AWS 리전 미국 동부(버지니아 북부) 및 미국 서부(오레곤)에 리소스가 있고 미국 텍사스주 댈러스, 오스틴 및 샌안토니오에 사용자가 많다고 가정해 보겠습니다. 이러한 도시는 리소스 간에 거의 동등하므로 편향의 작은 변화로 인해 리소스 간 트래픽이 크게 변동할 수 있습니다 AWS 리전 .
예상치 못한 트래픽의 증가로 인해 리소스가 부족하지 않도록 바이어스를 조금씩 일정하게 변경하는 것이 좋습니다.
자세한 내용은 [Amazon Route 53에서 EDNS0을 사용하여 사용자의 위치를 예측하는 방법](routing-policy-edns0.md) 단원을 참조하십시오.
## Amazon Route 53가 바이어스를 사용하여 트래픽을 라우팅하려면
다음은 Amazon Route 53가 트래픽을 라우팅하는 방법을 결정하기 위해 사용하는 수식입니다.
**편향**
`Biased distance = actual distance * [1 - (bias/100)]`
바이어스 값이 양수인 경우 Route 53은 DNS 쿼리의 소스와 지리 근접 레코드에 지정하는 리소스(예:의 EC2 인스턴스 AWS 리전)를 실제보다 더 가까운 것처럼 취급합니다. 예를 들어 다음과 같은 지리 근접 레코드가 있다고 가정하겠습니다.
+ 양수 바이어스 값 50을 가진 웹 서버 A의 레코드
+ 바이어스가 없는 웹 서버 B의 레코드
지리 근접 레코드가 양수 바이어스 값 50을 가지고 있을 때 Route 53는 쿼리의 소스와 그 레코드에 대한 리소스 사이의 거리를 반으로 줄입니다. 그러면 Route 53에서 어떤 리소스가 쿼리의 소스에 더 가까운지 계산합니다. 웹 서버 A와 B가 쿼리의 소스로부터 각각 150킬로미터와 100킬로미터 떨어져 있다고 가정해 봅시다. 어느 쪽 레코드에도 바이어스가 없다면 Route 53는 더 가까이 있는 웹 서버 B로 쿼리를 라우팅할 것입니다. 하지만 웹 서버 A의 레코드에 양수 바이어스 값 50이 있으므로, Route 53는 웹 서버 A가 쿼리의 소스로부터 75킬로미터 떨어져 있는 것처럼 처리합니다. 결과적으로, Route 53는 쿼리를 웹 서버 A로 라우팅합니다.
다음은 양수 바이어스 값 50에 대한 계산 과정입니다.
```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]
Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```
# 지연 시간 기반 라우팅
애플리케이션이 여러에서 호스팅되는 경우 지연 시간을 최소화 AWS 리전 하는에서 요청을 처리하여 사용자의 성능을 개선할 AWS 리전수 있습니다.
**참고**
사용자와 리소스 간의 지연 시간에 대한 데이터는 전적으로 사용자와 AWS 데이터 센터 간의 트래픽을 기반으로 합니다. 에서 리소스를 사용하지 않는 경우 사용자와 리소스 간의 AWS 리전실제 지연 시간은 AWS 지연 시간 데이터와 크게 다를 수 있습니다. 리소스가 AWS 리전과 같은 도시에 있는 경우에도 마찬가지입니다.
지연 시간 기반 라우팅을 사용하려면 여러 AWS 리전에 위치하는 리소스에 대해 지연 시간 레코드를 생성해야 합니다. Route 53에서 도메인 또는 하위 도메인(example.com 또는 acme.example.com)에 대한 DNS 쿼리를 수신하면 지연 시간 레코드가 생성된 AWS 리전 을 확인하고 사용자에게 가장 낮은 지연 시간을 제공하는 리전을 결정한 후 해당 리전의 지연 시간 레코드를 선택합니다. Route 53는 선택한 레코드의 값(예: 웹 서버의 IP 주소)으로 응답합니다.
예를 들어 미국 서부(오레곤) 리전 및 아시아 태평양(싱가포르) 리전에 Elastic Load Balancing 로드 밸런서가 있다고 가정합시다. 각 로드 밸런서에 대해 지연 시간 레코드를 생성합니다. 다음은 런던에 있는 사용자가 브라우저에 도메인 이름을 입력했을 때 발생하는 현상입니다.
1. DNS가 Route 53 이름 서버로 쿼리를 라우팅합니다.
1. Route 53는 런던과 싱가포르 리전 간, 그리고 런던과 오레곤 리전 간의 지연 시간에 대한 데이터를 참조합니다.
1. 런던 리전과 오레곤 리전 간의 지연 시간이 더 짧다면, Route 53는 오레곤 로드 밸런서의 IP 주소로 쿼리에 응답합니다. 런던 리전과 싱가포르 리전 간의 지연 시간이 더 짧다면, Route 53는 싱가포르 로드 밸런서의 IP 주소로 응답합니다.
인터넷상의 호스트 간 지연 시간은 네트워크 연결 및 라우팅이 시간에 따라 변화하는 양상에 따라 달라집니다. 지연 시간 기반 라우팅은 일정 기간에 걸쳐 수행되는 지연 시간 측정에 기반을 두고 있으며, 측정치는 그 변화 양상을 반영합니다. 이번 주에는 오레곤 리전으로 라우팅되는 요청이 다음 주에는 싱가포르 리전으로 라우팅될 수 있습니다.
**참고**
브라우저 또는 다른 뷰어가 EDNS0의 edns-client-subnet 확장을 지원하는 DNS 해석기를 사용하는 경우, DNS 해석기는 잘린 버전의 사용자 IP 주소를 Route 53에 전송합니다. 지연 시간 기반 라우팅이 구성된 경우 Route 53는 트래픽을 리소스로 라우팅할 때 이 값을 고려합니다. 자세한 내용은 [Amazon Route 53에서 EDNS0을 사용하여 사용자의 위치를 예측하는 방법](routing-policy-edns0.md) 단원을 참조하십시오.
프라이빗 호스팅 영역의 레코드에 지연 시간 라우팅 정책을 사용할 수 있습니다.
지연 시간 라우팅 정책으로 레코드를 만들 때 지정하는 값에 대한 정보는 다음 주제를 참조하십시오.
+ [지연 시간 레코드에 특정한 값](resource-record-sets-values-latency.md)
+ [지연 시간 별칭 레코드에 특정한 값](resource-record-sets-values-latency-alias.md)
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
# 프라이빗 호스팅 영역의 지연 시간 기반 라우팅
프라이빗 호스팅 영역의 경우 Route 53는 쿼리 AWS 리전가 시작된 VPC AWS 리전 의와 동일하거나 가장 가까운 거리에 있는 엔드포인트를 사용하여 DNS 쿼리에 응답합니다.
**참고**
아웃바운드 엔드포인트가 인바운드 엔드포인트에 전달된 경우, 레코드는 아웃바운드 엔드포인트가 아니라 인바운드 엔드포인트의 위치를 기반으로 확인됩니다.
상태 확인을 포함하고 쿼리 오리진에 대한 지연 시간이 가장 낮은 레코드가 비정상인 경우, 지연 시간이 두 번째로 낮은 정상 엔드포인트가 반환됩니다.
다음 그림의 예제 구성에서 us-east-1 AWS 리전또는 가장 가까운에서 오는 DNS 쿼리는 1.1.1.1 엔드포인트로 라우팅됩니다. us-west-2에서 오거나 이에 가장 가까운 DNS 쿼리는 2.2.2.2 엔드포인트로 라우팅됩니다.
![\[프라이빗 호스팅 영역에 대한 두 개의 지연 시간 레코드를 보여주는 스크린샷.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/latency-phz.png)
# IP 기반 라우팅
Amazon Route 53에서 IP 기반 라우팅을 사용하면 네트워크, 애플리케이션 및 클라이언트에 대한 이해를 바탕으로 DNS 라우팅을 미세 조정하여 최종 사용자를 위한 최상의 DNS 라우팅을 결정할 수 있습니다. IP 기반 라우팅은 사용자 IP-엔드포인트 매핑 형태로 Route 53에 데이터를 업로드하여 성능을 최적화하거나 네트워크 비용을 절감할 수 있는 세분화된 제어 기능을 제공합니다.
위치 정보 및 지연 시간 기반 라우팅은 Route 53가 수집 및 최신 상태로 유지하는 데이터를 기반으로 합니다. 이 접근 방식은 대부분의 고객에게 적합하지만 IP 기반 라우팅은 고객층의 특정 지식을 기반으로 라우팅을 최적화할 수 있는 추가 기능을 제공합니다. 예를 들어 글로벌 비디오 콘텐츠 공급자가 특정 인터넷 서비스 제공업체(ISP)에서 최종 사용자로 라우팅하려 할 수 있습니다.
IP 기반 라우팅의 몇 가지 일반적인 사용 사례는 다음과 같습니다.
+ 네트워크 전송 비용 또는 성능을 최적화하기 위해 특정 ISP에서 특정 엔드포인트로 최종 사용자를 라우팅하려는 경우.
+ 고객의 물리적 위치에 대한 지식에 기반한 지리적 위치 라우팅과 같은 기존 Route 53 라우팅 유형에 재정의를 추가하려고 하는 경우.
**IP 범위 관리 및 리소스 레코드 세트(RRSet)와 IP 범위 연결**
IPv4의 경우 길이가 1\$124비트인 CIDR 블록을 사용할 수 있으며 IPv6의 경우 길이가 1\$148비트인 CIDR 블록을 사용할 수 있습니다. 0비트 CIDR 블록(0.0.0.0/0 또는 ::/0)을 정의하려면 기본(“\$1”) 위치를 사용합니다.
CIDR이 CIDR 컬렉션에 지정된 것보다 긴 DNS 쿼리의 경우 Route 53는 이를 더 짧은 CIDR과 일치시킵니다. 예를 들어 CIDR 컬렉션에 CIDR 블록으로 2001:0DB8::/32를 지정하고 쿼리가2001:0DB8:0000:1234::/48에서 시작된 경우 CIDR이 일치합니다. 반면에 CIDR 컬렉션에 2001:0DB8:0000:1234::/48을 지정하고 쿼리가 2001:0DB8::/32에서 시작된 경우 CDIR이 일치하지 않으므로 Route 53는 기본("\$1") 위치에 대한 레코드로 응답합니다.
CIDR 블록(또는 IP 범위) 집합을 CIDR 위치로 그룹화할 수 있으며, CIDR 위치는 다시 CIDR 컬렉션이라는 재사용 가능한 엔터티로 그룹화됩니다.
**CIDR 블록**
CIDR 표기법의 IP 범위입니다(예: 192.0.2.0/24 또는 2001:DB8::/32).
**CIDR 위치**
명명된 CIDR 블록 목록입니다. 예를 들어 example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:DB8::/32 ]입니다. CIDR 위치 목록의 블록은 인접하거나 동일한 범위일 필요는 없습니다.
단일 위치는 IPv4 및 IPv6 블록을 둘 다 가질 수 있으며 이 위치는 각각 A 및 AAAA 레코드 세트에 모두 연결될 수 있습니다.
위치 이름은 대개 규칙에 따른 위치이지만 임의의 문자열이 될 수 있습니다(예: *Company-A*).
**CIDR 컬렉션**
명명된 위치의 컬렉션입니다. 예를 들어 mycollection = [example-isp-seattle, example-isp-tokyo]입니다.
IP 기반 라우팅 리소스 레코드 세트는 컬렉션의 위치를 참조하며, 동일한 레코드 세트 이름 및 유형에 대한 모든 리소스 레코드 세트는 동일한 컬렉션을 참조해야 합니다. 예를 들어 두 리전에서 웹 사이트를 만들고 서로 다른 두 개의 CIDR 위치에서 원래 IP 주소를 기반으로 특정 웹 사이트로 DNS 쿼리를 보내려면 두 위치 모두 동일한 CIDR 컬렉션에 작성되어야 합니다.
프라이빗 호스팅 영역의 레코드에는 IP 기반 라우팅 정책을 사용할 수 없습니다.
IP 기반 라우팅 정책으로 레코드를 만들 때 지정하는 값에 대한 정보는 다음 주제를 참조하세요.
+ [IP 기반 레코드에 특정한 값](resource-record-sets-values-ipbased.md)
+ [IP 기반 별칭 레코드에 특정한 값](resource-record-sets-values-ipbased-alias.md)
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
**Topics**
+ [CIDR 위치 및 블록을 사용하여 CIDR 컬렉션 생성](resource-record-sets-creating-cidr-collection.md)
+ [CIDR 위치 및 블록으로 작업](resource-record-sets-working-with-cidr-locations.md)
+ [CIDR 컬렉션 삭제](resource-record-sets-delete-cidr-collection.md)
+ [지리적 위치에서 IP 기반 라우팅으로 이동](resource-record-sets-move-geolocation-to-cidr.md)
# CIDR 위치 및 블록을 사용하여 CIDR 컬렉션 생성
시작하려면 CIDR 컬렉션을 생성하고 CIDR 블록과 위치를 추가합니다.
**Route 53 콘솔을 사용하여 CIDR 컬렉션을 생성하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **IP 기반 라우팅(IP-based routing)**, **CIDR 컬렉션(CIDR collections)**을 차례로 선택합니다.
1. **CIDR 컬렉션 생성(Create CIDR collection)**을 선택합니다.
1. **CIDR 컬렉션 생성(Create CIDR collection)** 창의 **세부 정보(Details)**에 컬렉션의 이름을 입력합니다.
1. **컬렉션 생성(Create collection)**을 선택하여 빈 컬렉션을 생성합니다.
– 또는 -
**CIDR 위치 생성** 섹션의 **CIDR 위치** 상자에 CIDR 위치의 이름을 입력합니다. 위치 이름은 임의의 식별 문자열일 수 있습니다(예: **company 1** 또는 **Seattle**). 실제 지리적 위치일 필요는 없습니다.
**중요**
CIDR 위치 이름의 최대 길이는 16자입니다.
**CIDR 블록** 상자에 CIDR 블록을 한 줄에 하나씩 입력합니다. 이는 IPv4의 경우 /0에서 /24까지, IPv6의 경우 /0에서 /48까지 범위인 IPv4 또는 IPv6 주소일 수 있습니다.
1. CIDR 블록을 입력한 다음 **CIDR 컬렉션 생성(Create CIDR collection)**를 선택하거나 **다른 위치 추가(Add another location)**를 선택하여 위치 및 CIDR 블록을 계속 입력합니다. 컬렉션당 여러 CIDR 위치를 입력할 수 있습니다.
1. CIDR 위치를 입력한 후 **CIDR 컬렉션 생성(Create CIDR collection)**을 선택합니다.
# CIDR 위치 및 블록으로 작업
**Route 53 콘솔을 사용하여 CIDR 위치를 사용하여 작업하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **IP 기반 라우팅**, **CIDR 컬렉션**을 선택하고 **CIDR 컬렉션** 섹션에서 **컬렉션 이름** 목록의 CIDR 컬렉션에 대한 링크를 클릭합니다.
**CIDR 위치(CIDR locations)** 페이지에서 CIDR 위치를 생성하거나, 삭제하거나, 위치 및 해당 블록을 편집할 수 있습니다.
+ 위치를 생성하려면 **CIDR 위치 생성(Create CIDR location)**을 선택합니다.
+ **CIDR 위치 생성(Create CIDR location)** 창에서 위치 이름, 위치와 연결된 CIDR 블록을 입력한 다음**생성(Create)**을 선택합니다.
+ CIDR 위치 및 위치 내 블록을 보려면 위치 옆의 라디오 버튼을 선택하여 위치 이름과 CIDR 블록을 위치 창에 표시합니다.
이 창에서 **편집**을 선택하여 위치 또는 위치의 CIDR 블록 이름을 업데이트합니다. 편집을 완료했으면 **저장(Save)**을 선택합니다.
+ CIDR 위치 및 위치 내 블록을 삭제하려면 삭제하려는 위치 옆의 라디오 버튼을 선택한 다음 **삭제(Delete)**를 선택합니다. 삭제를 확인하려면 텍스트 입력 필드에 위치 이름을 입력하고 **삭제(Delete)**를 다시 한 번 선택합니다.
**중요**
CIDR 위치 삭제는 실행 취소할 수 없습니다. 위치와 연결된 DNS 레코드가 있는 경우 도메인에 연결할 수 없게 될 수 있습니다.
# CIDR 컬렉션 삭제
**Route 53 콘솔을 사용하여 CIDR 컬렉션, 컬렉션의 위치 및 블록을 삭제하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **IP 기반 라우팅(IP-based routing)**, **CIDR 컬렉션(CIDR collections)**을 차례로 선택합니다.
1. **CIDR 컬렉션(CIDR collections)** 섹션에서 삭제하려는 컬렉션의 링크된 이름을 클릭합니다.
1. **CIDR 위치(CIDR locations)** 페이지에서 각 위치를 한 번에 하나씩 선택하고 **삭제(Delete)**를 선택하고, 대화 상자에 이름을 입력한 다음 **삭제(Delete)**를 선택합니다. 컬렉션을 삭제할 수 있기 전에 CIDR 컬렉션과 연결된 각 위치를 삭제해야 합니다.
1. 각 CIDR 위치 삭제가 완료된 후 **CIDR 위치(CIDR locations)** 페이지에서 삭제하려는 컬렉션 옆의 라디오 버튼을 선택한 다음 **삭제(Delete)**를 선택합니다.
# 지리적 위치에서 IP 기반 라우팅으로 이동
지리적 위치 또는 지리적 근접성 라우팅 정책을 사용하고 특정 클라이언트가 물리적 위치 또는 네트워크 토폴로지에 따라 최적이 아닌 엔드포인트로 라우팅되는 것을 계속 확인하는 경우 IP 기반 라우팅을 사용하여 이러한 클라이언트의 퍼블릭 IP 범위를 더 효과적으로 타겟팅할 수 있습니다.
다음 표는 캘리포니아 IP 범위에 맞게 미세 조정할 기존 지리적 위치 라우팅에 대한 지리적 위치 구성의 예를 포함합니다.
| 레코드 세트 이름 | 라우팅 정책 및 출발지 | 애플리케이션 엔드포인트의 IP 주소 |
| --- | --- | --- |
| example.com | 지리적 위치 라우팅(미국) | `198.51.100.1` |
| example.com | 지리적 위치 라우팅(유럽) | `198.51.100.2` |
캘리포니아에서 IP 범위를 재정의하여 새 애플리케이션 엔드포인트로 이동하려면 먼저 새 레코드 세트 이름으로 지리적 위치 라우팅을 다시 생성합니다.
| 레코드 세트 이름 | 라우팅 정책 및 출발지 | 애플리케이션 엔드포인트의 IP 주소 |
| --- | --- | --- |
| geo.example.com | 지리적 위치 라우팅(미국) | `198.51.100.1` |
| geo.example.com | 지리적 위치 라우팅(유럽) | `198.51.100.2` |
그런 다음 IP 기반 라우팅 레코드와 최근에 재생성된 지리적 위치 라우팅 레코드세트를 가리키는 기본 레코드를 만듭니다.
| 레코드 세트 이름 | 라우팅 정책 및 출발지 | 애플리케이션 엔드포인트의 IP 주소 |
| --- | --- | --- |
| example.com | IP 기반 라우팅(기본값) | 기본값으로 사용하려는 geo.example.com 응용 프로그램 엔드포인트에 대한 별칭 레코드입니다. 예를 들어 `198.51.100.1`입니다. |
| example.com | IP 기반 라우팅(캘리포니아 IP 범위) | `198.51.100.3` |
# 다중값 응답 라우팅
다중값 응답 라우팅을 사용하면 Amazon Route 53가 DNS 쿼리에 대해 다수의 값(예: 웹 서버의 IP 주소)을 반환하도록 구성할 수 있습니다. 다중값은 거의 모든 레코드에 대해 지정할 수 있지만, 다중값 응답 라우팅을 사용하면 각 리소스의 상태를 확인할 수도 있으므로 Route 53는 정상 리소스의 값만 반환합니다. 이것이 로드 밸런서를 대체하는 것은 아니지만, 다수의 상태 확인 가능한 IP 주소를 반환하는 기능은 DNS를 사용하여 가용성 및 로드 밸런싱을 개선하는 한 방법입니다.
트래픽을 거의 무작위적으로 웹 서버 같은 다수의 리소스로 라우팅하려면 각 리소스마다 하나씩 다중값 응답 레코드를 생성하고, 선택적으로 Route 53 상태 확인을 각 레코드에 연결할 수 있습니다. Route 53는 최대 8개의 정상 레코드로 DNS 쿼리에 응답하며, DNS 해석기마다 다른 응답을 제공합니다. 해석기가 응답을 캐시한 후 한 웹 서버가 사용 불가능해질 경우 클라이언트 소프트웨어는 응답에 포함된 다른 IP 주소를 시도할 수 있습니다.
다음 사항에 유의하세요.
+ 상태 확인을 다중 응답 레코드와 연결할 경우 Route 53는 상태 확인이 정상일 경우에만 해당 IP 주소로 DNS 쿼리에 응답합니다.
+ 상태 검사를 다중 응답 레코드와 연결하지 않을 경우 Route 53는 항상 레코드가 정상이라고 간주합니다.
+ 정상 레코드가 8개 이하일 경우 Route 53는 모든 DNS 쿼리에 모든 정상 레코드로 응답합니다.
+ 모든 레코드가 비정상일 경우 Route 53는 최대 8개의 비정상 레코드로 DNS 쿼리에 응답합니다.
프라이빗 호스팅 영역의 레코드에 다중 응답 라우팅 정책을 사용할 수 있습니다.
다중 응답 라우팅 정책으로 레코드를 만들 때 지정하는 값에 대한 정보는 [다중값 응답 레코드에 특정한 값](resource-record-sets-values-multivalue.md) 및[모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md) 단원을 참조하십시오.
# 가중치 기반 라우팅
가중치 기반 라우팅을 사용하면 다수의 리소스를 단일 도메인 이름(example.com) 또는 하위 도메인 이름(acme.example.com)과 연결하고 각 리소스로 라우팅되는 트래픽 비율을 선택할 수 있습니다. 이러한 방식은 로드 밸런싱, 새 버전의 소프트웨어 테스트 등을 비롯한 다양한 목적에 활용될 수 있습니다.
가중치 기반 라우팅을 구성하려면 각 리소스에 대해 동일한 이름의 레코드를 생성합니다. 각 리소스에 보낼 트래픽 양에 해당하는 상대적 가중치를 각 레코드에 할당합니다. Amazon Route 53는 그룹 내 전체 레코드의 총 가중치에 대한 비율에 따라 레코드에 할당된 가중치를 기반으로 트래픽을 리소스에 전송합니다.
![\[특정 리소스로 라우팅되는 트래픽의 양을 계산하는 수식: 지정된 레코드의 가중치 / 모든 레코드의 가중치 합계.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/WRR_calculation.png)
예를 들어 한 리소스에 일부 트래픽만 전송하고 나머지를 다른 리소스로 전송하려는 경우 가중치 1과 255를 지정할 수 있습니다. 가중치 1이 할당된 리소스에는 트래픽의 1/256(1/1\$1255)이 전송되고, 다른 리소스에는 트래픽의 255/256(255/1\$1255)이 전송됩니다. 가중치를 변경하여 점진적으로 균형을 조정할 수 있습니다. 특정 리소스로 트래픽 전송을 중단하려면 해당 레코드의 가중치를 0으로 변경할 수 있습니다.
가중치 기반 라우팅 정책으로 레코드를 만들 때 지정하는 값에 대한 정보는 다음 주제를 참조하십시오.
+ [가중치 기반 레코드에 특정한 값](resource-record-sets-values-weighted.md)
+ [가중치 기반 별칭 레코드에 특정한 값](resource-record-sets-values-weighted-alias.md)
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
프라이빗 호스팅 영역의 레코드에 가중치 기반 라우팅 정책을 사용할 수 있습니다.
## 상태 확인 및 가중치 기반 라우팅
가중치 기반 레코드의 그룹에서 레코드 전체에 상태 확인을 추가하지만 어떤 레코드에는 0이 아닌 가중치를 부여하고 또 다른 레코드에는 0인 가중치를 부여하는 경우 상태 확인은 모든 레코드의 가중치가 0일 때와 동일하게 작업합니다. 단, 다음 경우는 예외입니다.
+ Route 53는 처음에 0이 아닌 가중치 기반 레코드만을 고려합니다(해당되는 경우).
+ 0보다 큰 가중치를 지닌 레코드 전체가 비정상인 경우 Route 53는 0인 가중치 기반 레코드를 고려합니다.
다음 표는 가중치가 0인 레코드에 상태 확인이 포함된 경우의 동작을 자세히 설명합니다.
| | 레코드 1 | 레코드 2 | 레코드 3 |
| --- |--- |--- |--- |
| 가중치 | 1 | 1 | 0 |
| 상태 확인 포함 여부 | 예 | 예 | 예 |
| |
| --- |
| 상태 확인 상태 | 비정상 | 비정상 | 정상 |
| DNS 쿼리가 응답되었습니까? | 아니요 | 아니요 | 예 |
| |
| --- |
| 상태 확인 상태 | 비정상 | 비정상 | 비정상 |
| DNS query answered? | 예 | 예 | 아니요 |
| |
| --- |
| 상태 확인 상태 | 비정상 | 정상 | 비정상 |
| DNS 쿼리에 대한 응답을 받았습니까? | 아니요 | 예 | 아니요 |
| |
| --- |
| 상태 확인 상태 | 정상 | 정상 | 비정상 |
| DNS 쿼리에 대한 응답을 받았습니까? | 예 | 예 | 아니요 |
| |
| --- |
| 상태 확인 상태 | 정상 | 정상 | 정상 |
| DNS 쿼리에 대한 응답을 받았습니까? | 예 | 예 | 아니요 |
다음 표는 가중치가 0인 레코드에 상태 확인이 포함되지 않은 경우의 동작을 자세히 설명합니다.
| | 레코드 1 | 레코드 2 | 레코드 3 |
| --- |--- |--- |--- |
| 가중치 | 1 | 1 | 0 |
| 상태 확인 포함 여부 | 예 | 예 | 아니요 |
| |
| --- |
| 상태 확인 상태 | 정상 | 정상 | N/A |
| DNS query answered? | Yes | 예 | No |
| |
| --- |
| 상태 확인 상태 | 비정상 | 비정상 | 해당 사항 없음 |
| DNS 쿼리에 대한 응답을 받았습니까? | 아니요 | 아니요 | 예 |
| |
| --- |
| 상태 확인 상태 | 비정상 | 정상 | 해당 사항 없음 |
| DNS query answered? | 아니요 | 예 | 아니요 |
# Amazon Route 53에서 EDNS0을 사용하여 사용자의 위치를 예측하는 방법
지리적 위치, 지리적 근접성, IP 기반, 대기 시간 라우팅의 정확도를 개선하기 위해 Amazon Route 53는 EDNS0의 edns-client-subnet 확장을 지원합니다. (EDNS0은 DNS 프로토콜에 선택적으로 몇 개의 확장을 추가합니다.) Route 53는 DNS 해석기가 edns-client-subnet을 지원할 때만 이를 사용할 수 있습니다.
+ 브라우저 또는 다른 최종 사용자가 edns-client-subnet을 지원하지 않는 DNS 해석기를 사용하는 경우, Route 53는 DNS 해석기의 소스 IP 주소를 이용해 사용자 위치의 근사치를 측정해 해석기의 위치에 대한 DNS 레코드로 지리 위치 쿼리에 응답합니다.
+ 브라우저 또는 다른 뷰어가 edns-client-subnet을 지원하는 DNS 해석기를 사용하는 경우, DNS 해석기는 잘린 버전의 사용자 IP 주소를 Route 53에 전송합니다. Route 53는 DNS 해석기의 원본 IP 주소가 아닌 잘린 IP 주소를 기반으로 사용자의 위치를 결정합니다. 이렇게 하면 일반적으로 사용자의 위치를 보다 정확하게 예측할 수 있습니다. 그런 다음 Route 53는 사용자의 위치에 대한 DNS 레코드를 사용하여 지리적 위치 쿼리에 응답합니다.
+ EDNS0는 프라이빗 호스팅 영역에 적용되지 않습니다. 프라이빗 호스팅 영역의 경우 Route 53는 프라이빗 호스팅 영역 AWS 리전 이 있는의 VPC 해석기의 데이터를 사용하여 지리적 위치 및 지연 시간 라우팅을 결정합니다.
edns-client-subnet에 대한 자세한 내용은 EDNS Client Subnet RFC의 [Client Subnet in DNS Requests](https://www.rfc-editor.org/rfc/rfc7871)를 참조하세요.
# 별칭 또는 비 별칭 레코드 선택
Amazon Route 53 *별칭 레코드*는 DNS 기능에 Route 53 고유의 확장을 제공합니다. 별칭 레코드를 사용하면 CloudFront 배포 및 Amazon S3 버킷을 포함하되 이에 국한되지 않는 선택된 AWS 리소스로 트래픽을 라우팅할 수 있습니다. 호스팅 영역의 한 레코드에서 다른 레코드로 트래픽을 라우팅할 수도 있습니다.
CNAME 레코드와 달리, *zone apex*라고도 하는 DNS 네임스페이스의 최상위 노드에 별칭 레코드를 만들 수 있습니다. 예를 들어, DNS 이름 example.com을 등록하면 zone apex는 example.com입니다. example.com에 대한 CNAME 레코드를 생성할 수 없지만 트래픽을 www.example.com으로 라우팅하는 example.com에 대한 별칭 레코드를 생성할 수 있습니다(www.example.com의 레코드 유형이 CNAME 유형이 아닌 한).
Route 53가 별칭 레코드에 대한 DNS 쿼리를 받으면, Route 53는 해당 리소스에 해당되는 값으로 응답합니다.
+ **Amazon API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API** - Route 53는 API의 하나 이상의 IP 주소로 응답합니다.
+ **Amazon VPC 인터페이스 엔드포인트** – Route 53는 인터페이스 엔드포인트의 하나 이상의 IP 주소로 응답합니다.
+ **CloudFront 배포** – Route 53는 콘텐츠를 제공할 수 있는 CloudFront 엣지 서버의 하나 이상의 IP 주소로 응답합니다.
+ **App Runner 서비스** - Route 53은 하나 이상의 IP 주소로 응답합니다.
+ **Elastic Beanstalk 환경** – Route 53는 환경에 대해 하나 이상의 IP 주소로 응답합니다.
+ **Elastic Load Balancing 로드 밸런서** – Route 53는 로드 밸런서에 대해 1개 이상의 IP 주소로 응답합니다. 여기에는 Application Load Balancer, Classic Load Balancer 및 Network Load Balancer가 포함됩니다.
+ ** AWS Global Accelerator 액셀러레이터** - Route 53는 액셀러레이터의 IP 주소로 응답합니다.
+ **OpenSearch Service** - Route 53은 OpenSearch Service 사용자 지정 도메인에 대해 하나 이상의 IP 주소로 응답합니다.
+ **정적 웹사이트로 구성되는 Amazon S3 버킷** – Route 53는 Amazon S3 버킷의 1개의 IP 주소로 응답합니다.
+ **동일한 호스팅 영역에 있는 같은 유형의 다른 Route 53 레코드** – Route 53는 해당 쿼리가 별칭 레코드가 참조한 레코드에 대한 것처럼 응답합니다([별칭 레코드와 CNAME 레코드의 비교](#resource-record-sets-choosing-alias-non-alias-comparison) 참조).
+ **AWS AppSync 도메인 이름** - Route 53은 인터페이스 엔드포인트에 대해 하나 이상의 IP 주소로 응답합니다.
자세한 내용은 [AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md) 단원을 참조하십시오.
별칭 레코드를 사용하여 트래픽을 AWS 리소스로 라우팅하면 Route 53는 리소스의 변경 사항을 자동으로 인식합니다. 예를 들어, example.com의 별칭 레코드가 lb1-1234.us-east-2.elb.amazonaws.com의 Elastic Load Balancing 로드 밸런서를 가리킨다고 가정합니다. 로드 밸런서의 IP 주소가 변경된다면, Route 53는 자동적으로 새로운 IP 주소를 사용하여 DNS 쿼리에 응답하기 시작합니다.
별칭 레코드가 AWS 리소스를 가리키는 경우 TTL(Time to Live)을 설정할 수 없습니다. Route 53은 리소스에 기본 TTL을 사용합니다. 별칭 레코드가 동일한 호스팅 영역의 다른 레코드를 가리키는 경우, Route 53는 별칭 레코드가 가리키는 레코드의 TTL을 사용합니다. Elastic Load Balancing의 현재 TTL 값에 대한 자세한 내용은 *Elastic Load Balancing 사용 설명서*의 [라우팅 요청](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing)으로 이동하여 ‘ttl’을 검색하세요.
Route 53 콘솔을 사용하여 레코드를 생성하는 방법에 대한 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 섹션을 참조하세요. 별칭 레코드에 대해 지정하는 값에 대한 자세한 내용은 [Amazon Route 53 레코드를 생성 또는 편집할 때 지정하는 값](resource-record-sets-values.md)의 해당 주제를 참조하십시오.
+ [단순 별칭 레코드에 특정한 값](resource-record-sets-values-alias.md)
+ [가중치 기반 별칭 레코드에 특정한 값](resource-record-sets-values-weighted-alias.md)
+ [지연 시간 별칭 레코드에 특정한 값](resource-record-sets-values-latency-alias.md)
+ [장애 조치 별칭 레코드에 특정한 값](resource-record-sets-values-failover-alias.md)
+ [지리 위치 별칭 레코드에 특정한 값](resource-record-sets-values-geo-alias.md)
+ [지리 근접성 별칭 레코드에 특정된 값](resource-record-sets-values-geoprox-alias.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
## 별칭 레코드와 CNAME 레코드의 비교
별칭 레코드는 CNAME 레코드와 비슷하지만, 다음과 같은 중요한 차이점이 몇 가지 있습니다. 다음 목록은 별칭 레코드와 CNAME 레코드를 비교합니다.
**쿼리를 리디렉션할 수 있는 리소스**
**별칭 레코드**
별칭 레코드는 다음을 포함하되 이에 국한되지 않는 선택된 AWS 리소스로만 쿼리를 리디렉션할 수 있습니다.
+ Amazon S3 버킷
+ CloudFront 배포
+ 동일한 Route 53 호스팅 영역의 다른 레코드
예를 들어, acme.example.com이라는 이름의 Amazon S3 버킷으로 쿼리를 리디렉션하는 acme.example.com이라는 별칭 레코드를 생성할 수 있습니다. example.com 호스팅 영역의 zenith.example.com 레코드로 쿼리를 리디렉션하는 acme.example.com 별칭 레코드를 생성할 수도 있습니다.
**CNAME 레코드**
CNAME 레코드는 DNS 쿼리를 DNS 레코드로 리디렉션할 수 있습니다. 예를 들어 acme.example.com에서 zenith.example.com 또는 acme.example.org로 쿼리를 리디렉션하는 CNAME 레코드를 생성할 수 있습니다. 쿼리를 리디렉션할 도메인의 DNS 서비스로 Route 53를 사용할 필요가 없습니다.
**도메인과 이름이 동일한 레코드 생성(zone apex의 레코드)**
**별칭 레코드**
대부분의 구성에서 호스팅 영역(zone apex)과 이름이 동일한 별칭 레코드를 만들 수 있습니다. 단, zone apex(예: example.com)의 쿼리를 CNAME 유형의 동일한 호스팅 영역에 있는 레코드(예: zenith.example.com)로 리디렉션하려는 경우는 예외입니다. 별칭 레코드는 트래픽이 라우팅되는 레코드와 동일한 유형이어야 하고 zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
**CNAME 레코드**
호스팅 영역(zone apex)과 이름이 동일한 CNAME 레코드는 만들 수 없습니다. 이는 도메인 이름(example.com)의 호스팅 영역과 하위 도메인(zenith.example.com)의 호스팅 영역 모두에 해당됩니다.
**DNS 쿼리 요금**
**별칭 레코드**
Route 53는 AWS 리소스에 대한 별칭 쿼리에 대해 요금을 부과하지 않습니다. 자세한 내용은 [Amazon Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요.
**CNAME 레코드**
Route 53는 CNAME 쿼리에 대해 요금을 부과합니다.
Route 53 호스팅 영역(동일한 호스팅 영역 또는 다른 호스팅 영역)에 있는 다른 레코드의 이름으로 리디렉션되는 CNAME 레코드를 생성하는 경우 각 DNS 쿼리는 다음 두 개의 쿼리로 요금이 부과됩니다.
+ Route 53는 리디렉션하려는 레코드의 이름으로 첫 번째 DNS 쿼리에 응답합니다.
+ 그런 다음 DNS 해석기는 트래픽을 리디렉션하려는 위치(예: 웹 서버의 IP 주소)에 대한 정보를 얻기 위해 첫 번째 응답의 레코드에 대한 다른 쿼리를 제출해야 합니다.
CNAME 레코드가 다른 DNS 서비스와 함께 호스팅되는 레코드의 이름으로 리디렉션되는 경우 Route 53는 한 개의 쿼리에 대해 요금을 부과합니다. 다른 DNS 서비스는 두 번째 쿼리에 대해 요금을 부과할 수 있습니다.
**DNS 쿼리에 지정된 레코드 유형**
**별칭 레코드**
Route 53는 별칭 레코드 이름(예: acme.example.com)과 별칭 레코드 유형(예: A 또는 AAAA)이 DNS 쿼리의 이름 및 유형과 일치할 때만 DNS 쿼리에 응답합니다.
**CNAME 레코드**
CNAME 레코드는 A 또는 AAAA와 같이 DNS 쿼리에 지정된 레코드 유형에 관계없이 레코드 이름에 대한 DNS 쿼리를 리디렉션합니다.
**레코드가 dig 또는 nslookup 쿼리에 나열되는 방법**
**별칭 레코드**
dig 또는 nslookup 쿼리에 대한 응답에서 별칭 레코드는 레코드를 생성할 때 지정한 레코드 유형(예: A 또는 AAAA)으로 나열됩니다. (별칭 레코드에 지정하는 레코드 유형은 트래픽을 라우팅하는 리소스에 따라 다릅니다. 예를 들어 S3 버킷으로 트래픽을 라우팅하려면 유형에 A를 지정합니다.) 별칭 속성은 Route 53 콘솔 또는 AWS CLI `list-resource-record-sets` 명령과 같은 프로그래밍 요청에 대한 응답에서만 볼 수 있습니다.
**CNAME 레코드**
CNAME 레코드는 dig 또는 nslookup 쿼리에 대한 응답에서 CNAME 레코드로 나열됩니다.
# 지원되는 DNS 레코드 유형
Amazon Route 53은 이 섹션에 나열된 DNS 레코드 유형을 지원합니다. 각 레코드 유형 역시 API를 사용해 Route 53에 액세스할 때 `Value` 요소를 포맷하는 방법에 대한 한 가지 예를 포함합니다.
**참고**
도메인 이름을 포함하는 레코드 유형에 대해서는 예를 들어 *www.example.com*과 같은 전체 주소 도메인 이름을 입력합니다. 뒤에 오는 점은 선택 사항이며, Route 53은 도메인 이름을 전체 주소 도메인 이름으로 간주합니다. 다시 말해 Route 53은 *www.example.com*(뒤에 점 없음)과 *www.example.com.*(뒤에 점 있음)을 동일하게 처리합니다.
Route 53은 별칭 레코드라고 하는 DNS 기능에 대한 확장을 제공합니다. CNAME 레코드와 마찬가지로 별칭 레코드를 사용하면 CloudFront 배포와 Amazon S3 버킷 등 선택한 AWS 리소스로 트래픽을 라우팅할 수 있습니다. 별칭 레코드와 CNAME 레코드의 비교를 포함한 자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하십시오.
**Topics**
+ [레코드 유형](#AFormat)
+ [AAAA 레코드 유형](#AAAAFormat)
+ [CAA 레코드 유형](#CAAFormat)
+ [CNAME 레코드 유형](#CNAMEFormat)
+ [DS 레코드 유형](#DSFormat)
+ [HTTPS 레코드 유형](#HTTPSFormat)
+ [MX 레코드 유형](#MXFormat)
+ [NAPTR 레코드 유식](#NAPTRFormat)
+ [NS 레코드 유형](#NSFormat)
+ [PTR 레코드 유형](#PTRFormat)
+ [SOA 레코드 유형](#SOAFormat)
+ [SPF 레코드 유형](#SPFFormat)
+ [SRV 레코드 유형](#SRVFormat)
+ [SSHFP 레코드 유형](#SSHFPFormat)
+ [SVCB 레코드 유형](#SVCBFormat)
+ [TLSA 레코드 유형](#TLSAFormat)
+ [TXT 레코드 유형](#TXTFormat)
## 레코드 유형
A 레코드에서 점이 있는 십진법으로 된 IPv4 주소를 사용하여 웹 서버와 같은 리소스로 트래픽을 라우팅합니다.
**Amazon Route 53 콘솔에 대한 예제**
```
192.0.2.1
```
**Route 53 API에 대한 예제**
```
192.0.2.1
```
## AAAA 레코드 유형
AAAA 레코드에서 콜론으로 구분된 16진법 형식의 IPv6 주소를 사용하여 웹 서버와 같은 리소스로 트래픽을 라우팅합니다.
**Amazon Route 53 콘솔에 대한 예제**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
**Route 53 API에 대한 예제**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
## CAA 레코드 유형
CAA 레코드는 도메인 또는 하위 도메인에 대한 인증서 발급이 허용되는 인증 기관(CA)을 지정합니다. CAA 레코드를 생성하면 잘못된 CA가 도메인에 대한 인증서를 발급하는 것을 방지하는 데 도움이 됩니다. CAA 레코드는 인증 기관에서 지정한 보안 요구 사항(예: 도메인의 소유자임을 확인하기 위한 요구 사항) 대신 사용할 수 없습니다.
CAA 레코드를 사용하여 다음을 지정할 수 있습니다.
+ SSL/TLS 인증서(있는 경우)를 발급할 수 있는 인증 기관(CA)
+ CA가 도메인 또는 하위 도메인에 인증서를 발급할 때 연락처의 이메일 주소 또는 URL
CAA 레코드를 호스팅 영역에 추가할 때 공백으로 구분하여 다음 세 가지 설정을 지정합니다.
`flags tag "value"`
CAA 레코드의 형식에 대해 다음을 알아 두십시오.
+ `tag` 값에는 A-Z, a-z, 0-9 등의 문자만 포함될 수 있습니다.
+ `value`는 항상 인용 부호("")로 묶습니다.
+ 일부 CA는 `value`에 대한 추가 값을 허용하거나 요구합니다. 이름-값 페어로 추가 값을 지정하고 세미콜론(;)으로 구분합니다. 예를 들면 다음과 같습니다.
`0 issue "ca.example.net; account=123456"`
+ CA가 하위 도메인(예: www.example.com)에 대한 인증서 요청을 받았는데 해당 하위 도메인에 대해 아무런 CAA 레코드도 없는 경우, CA는 상위 도메인(예: example.com)용 CAA 레코드에 대한 DNS 쿼리를 제출합니다. 상위 도메인에 대한 레코드가 존재하고 인증서 요청이 유효한 경우 CA는 하위 도메인에 대한 인증서를 발행합니다.
+ CAA 레코드에 대해 지정할 값을 결정하려면 CA에 문의하는 것이 좋습니다.
+ 이름이 동일한 CAA 레코드와 CNAME 레코드를 생성할 수 없습니다. DNS에서 CNAME 레코드와 기타 다른 유형의 레코드에 대해 동일한 이름을 사용하지 못하도록 하기 때문입니다.
**Topics**
+ [CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하도록 승인](#CAAFormat-issue)
+ [CA가 도메인 또는 하위 도메인에 대한 와일드카드 인증서를 발행하도록 승인](#CAAFormat-issue-wild)
+ [CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하지 못하도록 금지](#CAAFormat-prevent-issue)
+ [CA가 잘못된 인증서 요청을 수신하는 경우 CA가 사용자에게 연락하도록 요청](#CAAFormat-contact)
+ [CA에서 지원하는 다른 설정 사용](#CAAFormat-custom-setting)
+ [예시](#CAAFormat-examples)
### CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하도록 승인
CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하도록 승인하려면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다.
+ **flags** – `0`
+ **tag** – `issue`
+ **value** - 도메인 또는 하위 도메인에 대한 인증서를 발행하도록 승인하는 CA에 대한 코드
예를 들어, ca.example.net에서 example.com에 대한 인증서를 발행하도록 승인하려는 경우를 가정해 봅시다. 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.
```
0 issue "ca.example.net"
```
AWS Certificate Manager가 인증서를 발급하도록 승인하는 방법에 대한 자세한 내용은 *AWS Certificate Manager 사용 설명서*의 [CAA 레코드 구성](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html)을 참조하세요.
### CA가 도메인 또는 하위 도메인에 대한 와일드카드 인증서를 발행하도록 승인
CA가 도메인 또는 하위 도메인에 대한 와일드카드 인증서를 발행하도록 승인하려면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다. 와일드카드 인증서는 도메인 또는 하위 도메인 및 모든 하위 도메인에 적용됩니다.
+ **flags** – `0`
+ **tag** – `issuewild`
+ **value** - 도메인 또는 하위 도메인과 그 하위 도메인에 대한 인증서를 발행하도록 승인하는 CA에 대한 코드
예를 들어, ca.example.net에서 example.com에 대한 와일드카드 인증서(example.com과 example.com의 모든 하위 도메인에 적용되는 인증서)를 발행하도록 승인하려는 경우를 가정해 봅시다. 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.
```
0 issuewild "ca.example.net"
```
CA가 도메인 또는 하위 도메인에 대한 와일드카드 인증서를 발행하도록 승인하고 싶으면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다. 와일드카드 인증서는 도메인 또는 하위 도메인 및 모든 하위 도메인에 적용됩니다.
### CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하지 못하도록 금지
CA가 도메인 또는 하위 도메인에 대한 인증서를 발행하지 못하도록 금지하려면 해당 도메인 또는 하위 도메인과 같은 이름을 가진 레코드를 만들고 다음 설정을 지정합니다.
+ **flags** – `0`
+ **tag** – `issue`
+ **value** – `";"`
예를 들어, 어떤 CA에서도 example.com에 대한 인증서를 발행하지 못하도록 하려는 경우를 가정해 봅시다. 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.
`0 issue ";"`
어떤 CA에서도 example.com 또는 그 하위 도메인에 대한 인증서를 발행하지 못하도록 하려면 다음 설정으로 example.com에 대한 CAA 레코드를 생성합니다.
`0 issuewild ";"`
**참고**
example.com에 대한 CA 레코드를 생성하고 다음 값을 둘 다 지정하면 ca.example.net 값을 사용하는 CA가 example.com에 대한 인증서를 발행할 수 있습니다.
```
0 issue ";"
0 issue "ca.example.net"
```
### CA가 잘못된 인증서 요청을 수신하는 경우 CA가 사용자에게 연락하도록 요청
인증서에 대해 잘못된 요청을 수신하는 CA가 귀하에게 연락하도록 하려면 다음 설정을 지정합니다.
+ **flags** – `0`
+ **tag** – `iodef`
+ **value** - CA가 인증서에 대해 잘못된 요청을 수신한 경우 CA가 알리려는 URL 또는 이메일 주소입니다. 해당하는 형식을 사용합니다.
`"mailto:email-address"`
`"http://URL"`
`"https://URL"`
예를 들어, 인증서에 대해 잘못된 요청을 수신하는 CA가 admin@example.com으로 이메일을 보내도록 하려는 경우 다음 설정으로 CAA 레코드를 생성합니다.
```
0 iodef "mailto:admin@example.com"
```
### CA에서 지원하는 다른 설정 사용
CA가 CAA 레코드에 대해 RFC에 정해지지 않은 기능을 지원하는 경우 다음 설정을 지정합니다.
+ **flags** - 128(이 값은 CA가 지정된 기능을 지원하지 않으면 인증서를 발행하지 못하도록 합니다.)
+ **tag** - CA가 사용하도록 승인한 태그
+ **value** - 태그의 값에 해당하는 값
예를 들어, CA가 잘못된 인증서 요청을 수신하는 경우 문자 메시지 전송 기능을 지원한다고 가정해 봅시다. (이 옵션을 지원하는 CA에 대해서는 알지 못합니다.) 레코드에 대한 설정은 다음과 같을 수 있습니다.
```
128 exampletag "15555551212"
```
### 예시
**Route 53 콘솔에 대한 예제**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
**Route 53 API에 대한 예제**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
## CNAME 레코드 유형
CNAME 레코드는 acme.example.com과 같은 현재 레코드의 이름에 대한 DNS 쿼리를 다른 도메인(example.com or example.net) 또는 하위 도메인(acme.example.com or zenith.example.org)으로 매핑합니다.
**중요**
DNS 프로토콜을 사용하면 Zone Apex라고 하는 DNS 네임스페이스의 최상위 노드에 대한 CNAME 레코드를 생성할 수 없습니다. 예를 들어, DNS 이름 example.com을 등록하면 zone apex는 example.com입니다. example.com에 대한 CNAME 레코드를 생성할 수는 없지만, www.example.com, newproduct.example.com 등에 대한 CNAME 레코드는 생성할 수 있습니다.
뿐만 아니라, 하위 도메인에 대한 CNAME 레코드를 생성하면, 그 하위 도메인에 대해서는 다른 레코드를 생성할 수 없습니다. 예를 들어 www.example.com에 대한 CNAME을 생성한 경우, **이름** 필드의 값이 www.example.com인 다른 레코드는 생성할 수 없습니다.
Amazon Route 53은 별칭 레코드로 지원하므로 CloudFront 배포와 Amazon S3 버킷 등의 선택한 AWS 리소스로 쿼리를 라우팅할 수 있습니다. 별칭들은 어떤 면에서 CNAME 레코드 유형과 유사하지만, zone apex에 대한 별칭을 생성할 수 있습니다. 자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 섹션을 참조하세요.
**Route 53 콘솔에 대한 예제**
```
hostname.example.com
```
**Route 53 API에 대한 예제**
```
hostname.example.com
```
## DS 레코드 유형
DS(Delegation Signer) 레코드는 위임된 하위 도메인 영역의 영역 키를 참조합니다. DNSSEC 서명을 구성할 때 신뢰 체인을 설정하면 DS 레코드를 만들 수 있습니다. Route 53의 DNSSEC 구성에 관한 정보는 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md) 섹션을 참조하세요.
처음 세 개의 값은 키 태그, 알고리즘 및 다이제스트 유형을 나타내는 10진수입니다. 네 번째 값은 영역 키의 다이제스트입니다. DS 레코드 유형에 대한 자세한 내용은 [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt)를 참조하세요.
**Route 53 콘솔에 대한 예제**
```
123 4 5 1234567890abcdef1234567890absdef
```
**Route 53 API에 대한 예제**
```
123 4 5 1234567890abcdef1234567890absdef
```
## HTTPS 레코드 유형
HTTPS 리소스 레코드는 확장된 구성 정보를 제공하는 서비스 바인딩(SVCB) DNS 레코드의 한 형태로, 클라이언트가 HTTP 프로토콜을 사용하여 서비스에 쉽고 안전하게 연결할 수 있게 해줍니다. 구성 정보는 여러 DNS 쿼리를 필요로 하는 대신 하나의 DNS 쿼리로 연결이 가능한 파라미터로 제공됩니다.
HTTPS 리소스 레코드의 형식은 다음과 같습니다.
`SvcPriority TargetName SvcParams(optional)`
다음 파라미터는 [RFC 9460, 섹션 9.1](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1)에 설명되어 있습니다.
**SvcPriority**
우선순위를 나타내는 정수입니다. 0의 우선순위는 별칭 모드를 의미하며 일반적으로 zone apex에서 별칭을 지정하기 위한 것입니다. 이 값은 Route 53의 경우 0-32767의 정수이며,이 중 1-32767은 서비스 모드 레코드입니다. 우선순위가 낮을수록 먼저 선택됩니다.
**TargetName**
별칭 대상(별칭 모드의 경우) 또는 대체 엔드포인트(ServiceMode의 경우)의 도메인 이름입니다.
**SvcParams(선택 사항)**
공백으로 구분된 목록으로, 각 파라미터는 Key=Value 페어 또는 독립 실행형 키로 구성됩니다. 값이 둘 이상인 경우 쉼표로 구분된 목록으로 표시됩니다. 다음은 정의된 SvcParams입니다.
+ `1:alpn` - 애플리케이션 계층 프로토콜 협상 프로토콜 ID. 기본값은 HTTP/1.1이고, `h2`는 TLS를 통한 HTTP/2이고, `h3`는 HTTP/3(QUIC 프로토콜을 통한 HTTP)입니다.
+ `2:no-default-alpn` - 기본값은 지원되지 않으므로 `alpn` 파라미터를 제공해야 합니다.
+ `3:port` - 대체 엔드포인트 또는 서비스에 연결할 수 있는 포트입니다.
+ `4:ipv4hint` - IPv4 주소 힌트.
+ `5:ech` - 암호화된 Client Hello.
+ `6:ipv6hint` - IPv6 주소 힌트.
+ `7:dohpath` – HTTPS를 통한 DNS 템플릿
+ `8:ohttp` - 이 서비스는 Oblivious HTTP 대상으로 작동함
**Amazon Route 53 콘솔의 별칭 모드에 대한 예제**
```
0 example.com
```
**Amazon Route 53 콘솔의 서비스 모드에 대한 예제**
```
16 example.com alpn="h2,h3" port=808
```
**Amazon Route 53 API의 별칭 모드에 대한 예제**
```
0 example.com
```
**Route 53 API의 서비스 모드에 대한 예제**
```
16 example.com alpn="h2,h3" port=808
```
자세한 내용은 [RFC 9460, DNS를 통한 서비스 바인딩 및 파라미터 사양(SVCB 및 HTTPS 리소스 레코드)](https://datatracker.ietf.org/doc/html/rfc9460)을 참조하세요.
**참고**
Route 53는 임의의 알 수 없는 키 표시 형식 `keyNNNNN`을 지원하지 않습니다.
## MX 레코드 유형
MX 레코드는 메일 서버의 이름을 지정하고, 두 개 이상의 메일 서버가 있는 경우 우선 순위를 지정합니다. MX 레코드의 각 값마다 다음과 같은 두 가지 값인 우선 순위와 도메인 이름이 포함됩니다.
**우선순위**
이메일 서버의 우선 순위를 나타내는 정수. 서버를 1개만 지정하는 경우 우선 순위는 0\$165535의 정수가 될 수 있습니다. 서버를 다수 지정하는 경우 우선 순위로 지정하는 값은 이메일이 라우팅되는 이메일 서버의 순서를 의미합니다. priority 값이 가장 낮은 서버가 우선 순위를 갖습니다. 예를 들어 이메일 서버가 2개이고 우선 순위로 10과 20을 지정하면, 사용할 수 없는 경우를 제외하고 이메일이 항상 우선 순위가 10인 서버로 라우팅됩니다. 하지만 10과 10으로 지정하면 이메일이 거의 동일하게 두 서버로 라우팅됩니다.
**도메인 이름**
이메일 서버의 도메인 이름. A 또는 AAAA 레코드의 이름(예: mail.example.com)을 지정합니다. [RFC 2181, Clarifications to the DNS Specification](https://tools.ietf.org/html/rfc2181)의 단원 10.3에서는 도메인 이름 값에 CNAME 레코드의 이름 지정을 금지합니다. (RFC에서 언급하는 "별칭"은 Route 53 별칭 레코드가 아닌 CNAME 레코드를 의미합니다.)
**Amazon Route 53 콘솔에 대한 예제**
```
10 mail.example.com
```
**Route 53 API에 대한 예제**
```
10 mail.example.com
```
## NAPTR 레코드 유식
이름 인증 포인터(NAPTR)는 하나의 값을 또 다른 값으로 변환하거나 대체하기 위해 Dynamic Delegation Discovery System(DDDS) 애플리케이션에서 사용하는 레코드의 유형입니다. 예를 들어, 하나의 일반적인 용도는 전화번호를 SIP URI로 변환하는 것입니다.
NAPTR 레코드의 `Value` 요소는 공백으로 구분된 6개의 값으로 구성되어 있습니다.
**Order**
레코드를 두 개 이상 지정할 때 DDDS 애플리케이션이 레코드를 평가하도록 할 시퀀스입니다. 유효한 값은 0\$165535입니다.
**기본 설정**
[**Order**]가 동일하게 지정된 레코드를 세 개 이상 지정할 경우 이러한 레코드가 평가되는 시퀀스에 대한 기본 설정입니다. 예를 들어, 두 개의 레코드에 [**Order**]가 1로 지정된 경우 DDDS 애플리케이션이 더 낮은 [**Preference**]이 적용되는 레코드를 먼저 평가합니다. 유효한 값은 0\$165535입니다.
**플래그**
DDDS 애플리케이션에 고유한 설정입니다. [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)에 현재 정의된 값은 대문자 및 소문자 [**"A"**], [**"P"**], [**"S"**] 및 [**"U"**]와 빈 문자열 [**""**]입니다. [**Flags**]는 인용 부호로 묶여 있습니다.
**Service**
DDDS 애플리케이션에 고유한 설정입니다. [**Service**]는 인용 부호로 묶여 있습니다.
자세한 내용은 관련 RFC를 참조하십시오.
+ **URI DDDS 애플리케이션** - [https://tools.ietf.org/html/rfc3404\$1section-4.4](https://tools.ietf.org/html/rfc3404#section-4.4)
+ **S-NAPTR DDDS 애플리케이션** - [https://tools.ietf.org/html/rfc3958\$1section-6.5](https://tools.ietf.org/html/rfc3958#section-6.5)
+ **U-NAPTR DDDS 애플리케이션** - [https://tools.ietf.org/html/rfc4848\$1section-4.5](https://tools.ietf.org/html/rfc4848#section-4.5)
**Regexp**
DDDS 애플리케이션에서 입력 값을 출력 값으로 변환하는 데 사용하는 정규식입니다. 예를 들어, IP 전화 시스템에서 사용자가 입력한 전화번호를 SIP URI로 변환하는 정규식을 사용할 수 있습니다. [**Regexp**]는 인용 부호로 묶여 있습니다. [**Regexp**]의 값 또는 [**Replacement**]의 값 중 하나만 지정합니다.
정규식에 다음과 같은 인쇄 가능한 ASCII 문자를 포함할 수 있습니다.
+ a-z
+ 0\$19
+ - (하이픈)
+ (공백)
+ \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 .
+ "(인용 부호) 문자열에 리터럴 따옴표를 포함하려면 \$1 문자를 앞에 입력합니다(\$1").
+ \$1 (backslash). 문자열에 백슬래시를 포함하려면 \$1 문자를 앞에 입력합니다(\$1\$1).
다국어 도메인 이름과 같은 기타 모든 값은 8진수 형식으로 지정합니다.
**Regexp**에 대한 구문을 보려면 [RFC 3402, 3.2절 대체식 구문](https://tools.ietf.org/html/rfc3402#section-3.2)을 참조하십시오.
**대체**
DDDS 애플리케이션에서 DNS 쿼리를 제출하도록 할 다음 도메인 이름의 정규화된 도메인 이름(FQDN)입니다. DDDS 애플리케이션이 입력 값을 [**Replacement**]에 지정하는 값으로 대체합니다(있는 경우). [**Regexp**]의 값 또는 [**Replacement**]의 값 중 하나만 지정합니다. **Regexp**의 값을 지정하는 경우에는 점(**.**)을 **교체**에 지정합니다.
도메인 이름에 a-z, 0-9 및 -(하이픈)을 포함할 수 있습니다.
DDDS 애플리케이션 및 NAPTR 레코드에 대한 자세한 내용은 다음 RFC를 참조하십시오.
+ [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt)
+ [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt)
+ [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt)
+ [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)
**Amazon Route 53 콘솔에 대한 예제**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
**Route 53 API에 대한 예제**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
## NS 레코드 유형
NS 레코드는 호스팅 영역에 대한 이름 서버를 식별합니다. 다음 사항에 유의하세요.
+ NS 레코드의 가장 일반적인 용도는 도메인에 대해 인터넷 트래픽이 라우팅되는 방식을 제어하는 것입니다. 호스팅 영역의 레코드를 사용하여 도메인의 트래픽을 라우팅하려면 기본 NS 레코드에 있는 네 개의 이름 서버를 사용하도록 도메인 등록 설정을 업데이트합니다. 이는 호스팅 영역과 이름이 같은 NS 레코드입니다.
+ 하위 도메인(acme.example.com)에 대해 별도의 호스팅 영역을 생성하고 해당 호스팅 영역을 사용하여 하위 도메인과 그 하위 도메인(subdomain.acme.example.com)에 대한 인터넷 트래픽을 라우팅할 수 있습니다. 루트 도메인(example.com)에 대한 호스팅 영역에 다른 NS 레코드를 생성하여 “하위 도메인에 대한 책임을 호스팅 영역으로 위임”이라고 하는 이 구성을 설정합니다. 자세한 내용은 [하위 도메인에 대한 트래픽 라우팅](dns-routing-traffic-for-subdomains.md) 섹션을 참조하세요.
+ 또한 NS 레코드를 사용하여 화이트 레이블 이름 서버를 구성합니다. 자세한 내용은 [화이트 레이블 이름 서버 구성](white-label-name-servers.md) 섹션을 참조하세요.
+ NS 레코드의 또 다른 용도는 프라이빗 호스팅 영역에서 하위 도메인에 대한 권한을 온프레미스 해석기에 위임하는 위임 규칙을 생성하는 것입니다. 위임 규칙을 생성하려면 먼저 이 NS 레코드를 생성해야 합니다. 자세한 내용은 [Resolver 엔드포인트VPCs에서 네트워크로 DNS 쿼리를 전달하는 방법](resolver-overview-forward-vpc-to-network.md) 섹션을 참조하세요.
NS 및 SOA 레코드에 대한 자세한 내용은 [Amazon Route 53에서 퍼블릭 호스팅 영역에 대해 생성하는 NS 및 SOA 레코드](SOA-NSrecords.md) 단원을 참조하십시오.
**Amazon Route 53 콘솔에 대한 예제**
```
ns-1.example.com
```
**Route 53 API에 대한 예제**
```
ns-1.example.com
```
## PTR 레코드 유형
PTR 레코드는 IP 주소를 해당 도메인 이름에 매핑합니다.
**Amazon Route 53 콘솔에 대한 예제**
```
hostname.example.com
```
**Route 53 API에 대한 예제**
```
hostname.example.com
```
## SOA 레코드 유형
권한 시작(SOA) 레코드에는 도메인 및 해당 Amazon Route 53 호스팅 영역에 대한 정보가 제공됩니다. SOA 레코드의 필드에 대한 자세한 내용은 [Amazon Route 53에서 퍼블릭 호스팅 영역에 대해 생성하는 NS 및 SOA 레코드](SOA-NSrecords.md) 단원을 참조하십시오.
**Route 53 콘솔에 대한 예제**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
**Route 53 API에 대한 예제**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
## SPF 레코드 유형
SPF 레코드는 이전에는 이메일 메시지 발신자의 자격 증명을 확인하는 데 사용되었습니다. 그러나 레코드 유형이 SPF인 레코드 생성은 권장하지 않습니다. RFC 7208, 즉 *Sender Policy Framework(SPF) for Authorizing Use of Domains in Email, Version 1*(이메일에서 도메인 사용을 인증하기 위한 메일 서버 등록제, 버전 1)은 "...[RFC4408]에 정의된 그 존재 및 메커니즘은 어떤 상호 운용성 문제로 귀결되었다. 따라서 SPF 버전 1에 대해 그것을 사용하는 것은 이제 적절하지 않다. 구현은 그것을 사용해서는 안 된다"라는 내용으로 업데이트되었습니다. RFC 7208에서는 14.1 섹션인 [SPF DNS 레코드 유형](http://tools.ietf.org/html/rfc7208#section-14.1)을 참조하십시오.
저희는 SPF 레코드 대신에 해당되는 값을 포함하는 TXT 레코드를 생성하도록 권장합니다. 유효한 값에 대한 자세한 내용은 Wikipedia 기사 [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework)를 참조하십시오.
**Amazon Route 53 콘솔에 대한 예제**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Route 53 API에 대한 예제**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
## SRV 레코드 유형
SRV 레코드 `Value` 요소는 공백으로 구분된 4개의 값으로 구성되어 있습니다. 처음의 세 값은 우선 순위, 가중치, 포트를 나타내는 10진수들입니다. 4번째 값은 도메인 이름입니다. SRV 레코드는 이메일 또는 통신용 서비스 등의 서비스에 액세스하는 데 사용됩니다. SRV 레코드 유형에 대한 자세한 내용은 연결할 서비스의 설명서를 참조하세요.
**Amazon Route 53 콘솔에 대한 예제**
```
10 5 80 hostname.example.com
```
**Route 53 API에 대한 예제**
```
10 5 80 hostname.example.com
```
## SSHFP 레코드 유형
Secure Shell 지문 레코드(SSHFP)는 도메인 이름과 연결된 SSH 키를 식별합니다. 신뢰 체인을 설정하려면 SSHFP 레코드를 DNSSEC로 보호해야 합니다. DNSSEC에 대한 자세한 내용은 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md) 섹션을 참조하세요.
SSHFP 리소스 레코드의 형식은 다음과 같습니다.
`[Key Algorithm] [Hash Type] Fingerprint`
다음 파라미터는 [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255)에 정의되어 있습니다.
**주요 알고리즘**
알고리즘 유형:
+ `0` - 예약되어 있어서 사용되지 않습니다.
+ `1: RSA` – Rivest–Shamir–Adleman 알고리즘은 최초의 퍼블릭 키 암호화 시스템 중 하나이며 보안 데이터 전송에 여전히 사용되고 있습니다.
+ `2: DSA` - 디지털 서명 알고리즘은 디지털 서명에 대한 연방 정보 처리 표준입니다. DSA는 모듈러 거듭제곱 및 이산 로그 수학 모델을 기반으로 합니다.
+ `3: ECDSA` - 타원 곡선 디지털 서명 알고리즘은 타원 곡선 암호화를 사용하는 DSA의 변형입니다.
+ `4: Ed25519` – Ed25519 알고리즘은 SHA-512(SHA-2) 및 Curve25519를 사용하는 EdDSA 서명 체계입니다.
+ `6: Ed448` – Ed448은 SHAKE256 및 Curve448을 사용하는 EdDSA 서명 체계입니다.
**해시 유형**
퍼블릭 키 해시를 생성하는 데 사용되는 알고리즘:
+ `0` - 예약되어 있어서 사용되지 않습니다.
+ `1: SHA-1`
+ `2: SHA-256`
**지문**
해시의 16진수 표현입니다.
**Amazon Route 53 콘솔에 대한 예제**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
**Route 53 API에 대한 예제**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
자세한 내용은 [RFC 4255: DNS를 사용하여 Secure Shell(SSH) 키 지문을 안전하게 게시](https://datatracker.ietf.org/doc/html/rfc4255)를 참조하세요.
## SVCB 레코드 유형
SVCB 레코드는 서비스 엔드포인트에 액세스하기 위한 구성 정보를 제공하는 데 사용됩니다. SVCB는 범용 DNS 레코드이며 다양한 애플리케이션 프로토콜의 파라미터를 협상하는 데 사용할 수 있습니다.
SVCB 리소스 레코드의 형식은 다음과 같습니다.
`SvcPriority TargetName SvcParams(optional)`
다음 파라미터는 [RFC 9460, 섹션 2.3](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3)에 설명되어 있습니다.
**SvcPriority**
우선순위를 나타내는 정수입니다. 0의 우선순위는 별칭 모드를 의미하며 일반적으로 zone apex에서 별칭을 지정하기 위한 것입니다. 우선순위가 낮을수록 먼저 선택됩니다.
**TargetName**
별칭 대상(별칭 모드의 경우) 또는 대체 엔드포인트(ServiceMode의 경우)의 도메인 이름입니다.
**SvcParams(선택 사항)**
공백으로 구분된 목록으로, 각 파라미터는 Key=Value 페어 또는 독립 실행형 키로 구성됩니다. 값이 둘 이상인 경우 쉼표로 구분된 목록으로 표시됩니다. 이 값은 Route 53의 경우 0-32767의 정수이며,이 중 1-32767은 서비스 모드 레코드입니다. 다음은 정의된 SvcParams입니다.
+ `1:alpn` - 애플리케이션 계층 프로토콜 협상 프로토콜 ID. 기본값은 HTTP/1.1이고, `h2`는 TLS를 통한 HTTP/2이고, `h3`는 HTTP/3(QUIC 프로토콜을 통한 HTTP)입니다.
+ `2:no-default-alpn` - 기본값은 지원되지 않으므로 `alpn` 파라미터를 제공해야 합니다.
+ `3:port` - 서비스에 연결할 수 있는 대체 엔드포인트의 포트입니다.
+ `4:ipv4hint` - IPv4 주소 힌트.
+ `5:ech` - 암호화된 Client Hello.
+ `6:ipv6hint` - IPv6 주소 힌트.
+ `7:dohpath` – HTTPS를 통한 DNS 템플릿
+ `8:ohttp` - 이 서비스는 Oblivious HTTP 대상으로 작동함
**Amazon Route 53 콘솔의 별칭 모드에 대한 예제**
```
0 example.com
```
**Amazon Route 53 콘솔의 서비스 모드에 대한 예제**
```
16 example.com alpn="h2,h3" port=808
```
**Amazon Route 53 API의 별칭 모드에 대한 예제**
```
0 example.com
```
**Route 53 API의 서비스 모드에 대한 예제**
```
16 example.com alpn="h2,h3" port=808
```
자세한 내용은 [RFC 9460, DNS를 통한 서비스 바인딩 및 파라미터 사양(SVCB 및 HTTPS 리소스 레코드)](https://datatracker.ietf.org/doc/html/rfc9460)을 참조하세요.
**참고**
Route 53는 임의의 알 수 없는 키 표시 형식 `keyNNNNN`을 지원하지 않습니다.
## TLSA 레코드 유형
TLSA 레코드를 사용하여 DNS-based Authentication of Named Entities(DANE)를 사용합니다. TLSA 레코드는 인증서/퍼블릭 키를 Transport Layer Security(TLS) 엔드포인트와 연결하며, 클라이언트는 DNSSEC로 서명된 TLSA 레코드를 사용하여 인증서/퍼블릭 키를 검증할 수 있습니다.
도메인에서 DNSSEC가 활성화된 경우에만 TLSA 레코드를 신뢰할 수 있습니다. DNSSEC에 대한 자세한 내용은 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md) 섹션을 참조하세요.
TLSA 리소스 레코드의 형식은 다음과 같습니다.
`[Certificate usage] Selector [Matching type] [Certificate association data]`
다음 파라미터는 [RFC 6698, 섹션 3](https://datatracker.ietf.org/doc/html/rfc6698#section-3)에 명시되어 있습니다.
**인증서 사용(Certificate usage)**
TLS 핸드셰이크에 제시된 인증서가 일치하는지 확인하는 데 사용할 제공된 연결 정보를 지정합니다.
+ 0: CA 제약 조건 - 인증서 또는 퍼블릭 키는 TLS에서 서버가 제공하는 최종 엔터티 인증서의 퍼블릭 키 인프라(PKIX) 인증 경로 중 하나에서 찾을 수 있어야 합니다. 이 제약 조건은 지정된 서비스에 대한 인증서를 발급하는 데 사용할 수 있는 CA를 제한합니다.
+ 1: 서비스 인증서 제약 조건 - TLS에서 서버가 제공한 최종 엔터티 인증서와 일치해야 하는 최종 엔터티 인증서(또는 퍼블릭 키)를 지정합니다. 이 인증은 호스트의 특정 서비스가 사용할 수 있는 최종 엔터티 인증서를 제한합니다.
+ 2: 트러스트 앵커 어설션 - TLS에서 서버가 제공하는 최종 엔터티 인증서를 검증할 때 "트러스트 앵커"로 사용해야 하는 인증서(또는 퍼블릭 키)를 지정합니다. 도메인 관리자가 트러스트 앵커를 지정할 수 있습니다.
+ 3: 도메인 발급 인증 - TLS에서 서버가 제공한 최종 엔터티 인증서와 일치해야 하는 인증서(또는 퍼블릭 키)를 지정합니다. 이 인증은 도메인 관리자가 타사 CA를 사용하지 않고 도메인에 대한 인증서를 발급할 수 있도록 허용합니다. 이 인증서는 PKIX 검증을 통과할 필요가 없습니다.
**Selector**
핸드셰이크에서 서버가 제시한 인증서의 어떤 부분이 연결 값과 일치해야 하는지 지정합니다.
+ 0: 전체 인증서가 일치해야 합니다.
+ 1: Subject Public Key 또는 DER 인코딩 바이너리 구조가 일치해야 합니다.
**일치 유형(Matching type)**
인증서 일치에 대한 표현(Selector 필드에 의해 결정됨)을 지정합니다.
+ 0: 콘텐츠가 정확히 일치.
+ 1: SHA-256 해시.
+ 2: SHA-512 해시.
**인증서 연결 데이터(Certificate association data)**
다른 필드의 설정에 따라 일치해야 할 데이터입니다.
**Amazon Route 53 콘솔에 대한 예제**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
**Route 53 API에 대한 예제**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
자세한 내용은 [RFC 6698, DNS-Based Authentication of Named Entities(DANE) Transport Layer Security(TLS) 프로토콜: TLSA](https://datatracker.ietf.org/doc/html/rfc6698)를 참조하세요.
## TXT 레코드 유형
TXT 레코드는 큰따옴표(`"`)로 묶여 있는 하나 이상의 문자열을 포함합니다. 간단한 [라우팅 정책](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)을 사용할 때 도메인(example.com) 또는 하위 도메인(www.example.com)에 대한 모든 값을 같은 TXT 레코드에 포함합니다.
**Topics**
+ [TXT 레코드 값 입력](#TXTformat-limits)
+ [TXT 레코드 값의 특수 문자](#TXTformat-special-characters)
+ [TXT 레코드 값의 대문자 및 소문자](#TXTformat-case)
+ [예시](#TXTformat-examples)
### TXT 레코드 값 입력
단일 문자열에는 다음을 포함하여 최대 255자가 포함될 수 있습니다.
+ a-z
+ A-Z
+ 0\$19
+ 공간
+ - (하이픈)
+ \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 .
255자보다 긴 값을 입력해야 하는 경우, 값을 255자 이하의 문자열로 나누고 각 문자열을 큰따옴표(`"`)로 묶습니다. 콘솔에서 모든 문자열을 같은 줄에 나열하십시오.
```
"String 1" "String 2" "String 3"
```
API의 경우 동일한 `Value` 요소에 모든 문자열을 포함시킵니다.
```
"String 1" "String 2" "String 3"
```
TXT 레코드의 최대 값 길이는 4,000자입니다.
TXT 값을 하나 이상 입력하려면 행당 하나의 값을 입력합니다.
### TXT 레코드 값의 특수 문자
TXT 레코드에 다음 문자가 포함되어 있는 경우, `\`*three-digit octal code* 형식의 이스케이프 코드를 사용하여 문자를 지정해야 합니다.
+ 000 - 040 사이의 8진수 문자(0 - 32 사이의 10진수, 0x00 - 0x20 사이의 16진수)
+ 177 - 377 사이의 8진수 문자(127 - 255 사이의 10진수, 0x7F - 0xFF 사이의 16진수)
예를 들어 TXT 레코드의 값이 `"exämple.com"`인 경우 `"ex\344mple.com"`을 지정합니다.
ASCII 문자와 8진수 코드 사이의 매핑을 수행하려면 인터넷에서 "ASCII octal codes"를 검색하세요. 한 가지 유용한 참조 웹 페이지는 [ASCII Code - The extended ASCII table](https://www.ascii-code.com/)입니다.
문자열에 인용 부호(`"`)를 포함하려면 인용 부호 앞에 백래시(`\`) 문자를 넣으십시오(즉, `\"`).
### TXT 레코드 값의 대문자 및 소문자
대/소문자가 유지되므로 `"Ab"`와 `"aB"`는 서로 다른 값임에 유의하십시오.
### 예시
**Amazon Route 53 콘솔에 대한 예제**
각 값을 별도의 라인에 입력합니다.
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Route 53 API에 대한 예제**
각 값을 별도의 `Value` 요소에 입력합니다.
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
# Amazon Route 53 콘솔을 사용하여 레코드 생성
다음 절차는 Amazon Route 53 콘솔을 사용하여 레코드를 생성하는 방법을 설명합니다. Route 53 API를 사용하여 레코드를 생성하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)를 참조하세요.
**참고**
복잡한 라우팅 구성에 대한 레코드를 만들려면 Traffic Flow 시각적 편집기를 사용하고 구성을 트래픽 정책으로 저장할 수도 있습니다. 그런 다음 동일한 호스팅 영역이나 여러 호스팅 영역의 하나 이상의 도메인 이름(예: example.com) 또는 하위 도메인 이름(예: www.example.com)과 해당 트래픽 정책을 연결할 수 있습니다. 새 구성이 예상대로 수행되지 않을 경우 업데이트를 롤백할 수도 있습니다. 자세한 내용은 [트래픽 흐름을 사용하여 DNS 트래픽 라우팅](traffic-flow.md) 단원을 참조하십시오.
**Route 53 콘솔을 사용하여 라우팅을 생성하려면**
1. 별칭 레코드를 생성하지 않는 경우에는 2단계로 이동합니다.
또한 DNS 트래픽을 Elastic Load Balancing 로드 밸런서 또는 다른 Route 53 레코드 이외의 AWS 리소스로 라우팅하는 별칭 레코드를 생성하는 경우 2단계로 이동합니다.
트래픽을 Elastic Load Balancing 로드 밸런서로 라우팅하는 별칭 레코드를 생성하는 경우, 그리고 서로 다른 계정을 사용해 호스팅 영역 및 로드 밸런서를 생성한 경우에는 [Elastic Load Balancing 로드 밸런서의 DNS 이름 가져오기](#resource-record-sets-elb-dns-name-procedure)의 절차를 수행해 로드 밸런서에 대한 DNS 이름을 가져옵니다.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택합니다.
1. 도메인의 호스팅 영역이 이미 있다면 5단계로 건너뜁니다. 없다면 해당 절차를 수행하여 호스팅 영역을 생성합니다.
+ 인터넷 트래픽을 Amazon S3 버킷 또는 Amazon EC2 인스턴스 같은 리소스로 라우팅하려면 [퍼블릭 호스팅 영역 생성](CreatingHostedZone.md)을 참조하세요.
+ VPC에서 트래픽을 라우팅하려면 [프라이빗 호스팅 영역 생성](hosted-zone-private-creating.md)을 참조하십시오.
1. **호스팅 영역(Hosted Zones)** 페이지에서 레코드를 생성할 호스팅 영역의 이름을 선택합니다.
1. **레코드 세트 생성**을 선택합니다.
1. 해당하는 라우팅 정책 및 값을 선택하고 정의합니다. 자세한 내용은 생성하려는 레코드의 종류에 대한 주제를 참조하십시오.
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
+ [단순 레코드에 특정한 값](resource-record-sets-values-basic.md)
+ [단순 별칭 레코드에 특정한 값](resource-record-sets-values-alias.md)
+ [장애 조치 레코드에 특정한 값](resource-record-sets-values-failover.md)
+ [장애 조치 별칭 레코드에 특정한 값](resource-record-sets-values-failover-alias.md)
+ [지리 위치 레코드에 특정한 값](resource-record-sets-values-geo.md)
+ [지리 위치 별칭 레코드에 특정한 값](resource-record-sets-values-geo-alias.md)
+ [지리 근접성 레코드에 특정된 값](resource-record-sets-values-geoprox.md)
+ [지리 근접성 별칭 레코드에 특정된 값](resource-record-sets-values-geoprox-alias.md)
+ [지연 시간 레코드에 특정한 값](resource-record-sets-values-latency.md)
+ [지연 시간 별칭 레코드에 특정한 값](resource-record-sets-values-latency-alias.md)
+ [IP 기반 레코드에 특정한 값](resource-record-sets-values-ipbased.md)
+ [IP 기반 별칭 레코드에 특정한 값](resource-record-sets-values-ipbased-alias.md)
+ [다중값 응답 레코드에 특정한 값](resource-record-sets-values-multivalue.md)
+ [가중치 기반 레코드에 특정한 값](resource-record-sets-values-weighted.md)
+ [가중치 기반 별칭 레코드에 특정한 값](resource-record-sets-values-weighted-alias.md)
1. **레코드 생성**을 선택합니다.
**참고**
새 레코드는 Route 53 DNS 서버로 전파되기까지 시간이 걸립니다. 현재 변경 사항의 전파 여부를 확인하는 유일한 방법은 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 작업을 사용하는 것입니다. 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름의 서버로 전파됩니다.
1. 레코드를 여러 개 생성하는 경우에는 7\$18단계를 반복합니다.
**Elastic Load Balancing 로드 밸런서의 DNS 이름 가져오기**
1. 별칭 레코드를 생성할 Classic, Application 또는 Network Load Balancer를 생성하는 데 사용된 AWS 계정을 AWS Management Console 사용하여에 로그인합니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **로드 밸런서**를 클릭합니다.
1. 로드 밸런서 목록에서 별칭 레코드를 만들고자 하는 로드 밸런서를 선택합니다.
1. [**Description**] 탭에서 [**DNS name**] 값을 찾습니다.
1. 다른 Elastic Load Balancing 로드 밸런서를 위한 별칭 레코드를 생성하고 싶다면, 4\$15단계를 반복하세요.
1. 에서 로그아웃합니다 AWS Management Console.
1. Route 53 호스팅 영역을 생성하는 데 사용한 AWS 계정을 사용하여에 AWS Management Console 다시 로그인합니다.
1. [Amazon Route 53 콘솔을 사용하여 레코드 생성](#resource-record-sets-creating) 절차의 3단계로 돌아갑니다.
# 리소스 레코드 세트 권한
리소스 레코드 세트 권한은 ID 및 액세스 관리(IAM) 정책 조건을 사용하여 Route 53 콘솔에서의 작업 또는 [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) API 사용에 대해 세분화된 권한을 설정할 수 있습니다.
리소스 레코드 세트는 동일한 이름과 유형(그리고 클래스가 있음. 하지만 대부분의 용도에서 클래스는 항상 IN, 즉 인터넷임)을 가진 여러 리소스 레코드로 정의되나, 서로 다른 데이터를 포함합니다. 예를 들어 지리적 위치 라우팅을 선택한 경우 동일한 도메인의 서로 다른 엔드포인트를 가리키는 A 레코드나 AAAA 레코드가 여러 개 있을 수 있습니다. 이러한 A 레코드나 AAAA 레코드가 모두 함께 리소스 레코드 세트를 구성합니다. DNS 용어에 대한 자세한 내용은 [RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719)를 참조하세요.
IAM 정책 조건인 `route53:ChangeResourceRecordSetsActions`, `route53:ChangeResourceRecordSetsRecordTypes`및 `route53:ChangeResourceRecordSetsNormalizedRecordNames`를 사용하면 다른 AWS 계정의 다른 AWS 사용자에게 세분화된 관리 권한을 부여할 수 있습니다. 다른 사람에게 다음 권한을 부여할 수 있습니다.
+ 단일 리소스 레코드 세트.
+ 특정 DNS 레코드 유형의 모든 리소스 레코드 세트.
+ 이름에 특정 문자열이 포함된 리소스 레코드 세트.
+ [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) API 또는 Route 53 콘솔을 사용할 때는 `CREATE | UPSERT | DELETE `작업 중 아무거나 또는 모두를 수행합니다.
어떤 Route 53 정책 조건이든 결합된 액세스 권한을 생성할 수도 있습니다. 예를 들어, 다른 사람에게 markeing-example.com의 A 레코드 데이터를 수정할 수 있는 권한을 부여하고, 해당 사용자가 레코드를 삭제하도록 허용하지 않을 수 있습니다.
리소스 레코드 세트 권한 및 사용 방법 예제에 대한 자세한 내용은 [IAM 정책 조건을 사용하여 세분화된 액세스 제어 구현](specifying-conditions-route53.md) 섹션을 참조하세요.
AWS 사용자를 인증하는 방법은 단원을 참조[ID를 통한 인증](security-iam.md#security_iam_authentication)하고 Route 53 리소스에 대한 액세스를 제어하는 방법은 단원을 참조하십시오[액세스 관리](security-iam.md#access-control).
# Amazon Route 53 레코드를 생성 또는 편집할 때 지정하는 값
Amazon Route 53 콘솔을 사용하여 레코드를 생성할 때 지정하는 값은 사용하려는 라우팅 정책과 트래픽을 AWS 리소스로 라우팅하는 별칭 레코드를 생성할지 여부에 따라 달라집니다.
대상 AWS 리소스를 지정하는 특정 리소스(예: Elastic Load Balancing, CloudFront 배포, Amazon S3 버킷)로 트래픽을 라우팅하는 별칭 레코드입니다. 선택적으로 상태 확인을 연결하고 대상 상태 평가를 구성할 수도 있습니다. 다음 주제에서는 각 라우팅 정책 및 레코드 유형에 필요한 값에 대한 상세한 정보를 제공하여 Route 53 레코드를 효과적으로 구성하는 데 도움이 됩니다.
**Topics**
+ [모든 라우팅 정책에 공통적인 값](resource-record-sets-values-shared.md)
+ [모든 라우팅 정책의 별칭 레코드에 공통되는 값](resource-record-sets-values-alias-common.md)
+ [단순 레코드에 특정한 값](resource-record-sets-values-basic.md)
+ [단순 별칭 레코드에 특정한 값](resource-record-sets-values-alias.md)
+ [장애 조치 레코드에 특정한 값](resource-record-sets-values-failover.md)
+ [장애 조치 별칭 레코드에 특정한 값](resource-record-sets-values-failover-alias.md)
+ [지리 위치 레코드에 특정한 값](resource-record-sets-values-geo.md)
+ [지리 위치 별칭 레코드에 특정한 값](resource-record-sets-values-geo-alias.md)
+ [지리 근접성 레코드에 특정된 값](resource-record-sets-values-geoprox.md)
+ [지리 근접성 별칭 레코드에 특정된 값](resource-record-sets-values-geoprox-alias.md)
+ [지연 시간 레코드에 특정한 값](resource-record-sets-values-latency.md)
+ [지연 시간 별칭 레코드에 특정한 값](resource-record-sets-values-latency-alias.md)
+ [IP 기반 레코드에 특정한 값](resource-record-sets-values-ipbased.md)
+ [IP 기반 별칭 레코드에 특정한 값](resource-record-sets-values-ipbased-alias.md)
+ [다중값 응답 레코드에 특정한 값](resource-record-sets-values-multivalue.md)
+ [가중치 기반 레코드에 특정한 값](resource-record-sets-values-weighted.md)
+ [가중치 기반 별칭 레코드에 특정한 값](resource-record-sets-values-weighted-alias.md)
# 모든 라우팅 정책에 공통적인 값
이것은 Amazon Route 53 레코드를 생성 또는 편집할 때 지정할 수 있는 공통적인 값입니다. 이러한 값은 모든 라우팅 정책에서 사용됩니다.
**Topics**
+ [레코드 이름](#rrsets-values-common-name)
+ [값/트래픽 라우팅 대상](#rrsets-values-common-value)
+ [TTL(초)](#rrsets-values-common-ttl)
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **이름** 필드에 값(예: @ 기호)을 입력하지 마십시오.
**CNAME 레코드**
**레코드 유형(Record type)** 값이 **CNAME**인 레코드를 생성하는 경우 레코드의 이름은 호스팅 영역의 이름과 같을 수 없습니다.
**특수 문자**
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하십시오.
**와일드카드 문자**
이름에 별표(\$1) 문자를 사용할 수 있습니다. DNS는 이름에 표시되는 위치에 따라 \$1 문자를 와일드카드 또는 \$1 문자(ASCII 42)로 처리합니다. 자세한 내용은 [호스팅 영역 및 레코드의 이름에 별표(\$1) 사용](DomainNameFormat.md#domain-name-format-asterisk) 단원을 참조하십시오.
\$1 와일드카드를 유형이 **NS**인 리소스 레코드 세트에 사용할 수 없습니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
**A – IPv4 주소**
IPv4 형식의 IP 주소(예: **192.0.2.235**)
**AAAA - IPv6 주소**
IPv6 형식의 IP 주소(예: **2001:0db8:85a3:0:0:8a2e:0370:7334**)
**CAA - 인증 기관 인증**
**레코드 이름(Record name)**으로 지정되는 도메인 또는 하위 도메인에 대한 인증서나 와일드카드 인증서 발급이 허용되는 인증 기관을 제어하는 공백으로 구분된 3개의 값. CAA 레코드를 사용하여 다음을 지정할 수 있습니다.
+ SSL/TLS 인증서(있는 경우)를 발급할 수 있는 인증 기관(CA)
+ CA가 도메인 또는 하위 도메인에 인증서를 발급할 때 연락처의 이메일 주소 또는 URL
**CNAME – 정식 이름**
Route 53에서 이 레코드의 DNS 쿼리에 대한 응답으로 반환하려는 정규화된 도메인 이름(예: *www.example.com*)입니다. 뒤에 오는 점은 선택 사항이며, Route 53은 도메인 이름을 정규화된 도메인 이름으로 간주합니다. 다시 말해 Route 53은 *www.example.com*(뒤에 점 없음)과 *www.example.com.*(뒤에 점 있음)을 동일하게 처리합니다.
**MX - 메일 교환**
우선 순위와 메일 서버를 지정하는 도메인 이름(예: **10 mailserver.example.com**) 뒤에 오는 점은 선택 사항으로 처리됩니다.
**NAPTR - 이름 권한 포인터**
하나의 값을 또 다른 값으로 변환하거나 대체하기 위해 Dynamic Delegation Discovery System(DDDS) 애플리케이션이 사용하는 공백으로 구분된 6개의 설정. 자세한 내용은 [NAPTR 레코드 유식](ResourceRecordTypes.md#NAPTRFormat) 단원을 참조하십시오.
**PTR - 포인터**
Route 53이 반환하려는 도메인 이름입니다.
**NS - 이름 서버**
이름 서버의 도메인 이름(예: **ns1.example.com**)
단순 라우팅 정책만 사용하여 NS 레코드를 지정할 수 있습니다.
**SPF - 발신자 정책 프레임워크**
인용 부호 안에 들어 있는 SPF 레코드(예: **"v=spf1 ip4:192.168.0.1/16-all"**). SPF 레코드는 권장되지 않습니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
**SRV - 서비스 로케이터**
SRV 기록. SRV 레코드는 이메일 또는 통신용 서비스 등의 서비스에 액세스하는 데 사용됩니다. SRV 레코드 유형에 대한 자세한 내용은 연결할 서비스의 설명서를 참조하세요. 뒤에 오는 점은 선택 사항으로 처리됩니다.
SRV 레코드 유형은 다음과 같습니다.
**[우선 순위] [가중치] [포트] [서버 호스트 이름]**
예:
**1 10 5269 xmpp-server.example.com.**
**TXT - 텍스트**
텍스트 레코드. 인용 부호 안에 들어 있는 텍스트(예: **"Sample Text Entry"**).
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
# 모든 라우팅 정책의 별칭 레코드에 공통되는 값
이것은 Amazon Route 53 레코드를 생성 또는 편집할 때 지정할 수 있는 공통적인 별칭 값입니다. 이러한 값은 모든 라우팅 정책에서 사용됩니다.
**Topics**
+ [레코드 이름](#rrsets-values-common-alias-name)
+ [값/트래픽 라우팅 대상](#rrsets-values-alias-common-target)
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **이름** 필드에 값(예: @ 기호)을 입력하지 마십시오.
**CNAME 레코드**
**유형** 값이 **CNAME**인 레코드를 생성하는 경우 레코드의 이름은 호스팅 영역의 이름과 같을 수 없습니다.
**CloudFront 배포 및 Amazon S3 버킷에 대한 별칭**
지정하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 부분적으로 달라집니다.
+ **CloudFront 배포(CloudFront distribution)** – 배포에 레코드 이름과 일치하는 대체 도메인 이름이 포함되어야 합니다. 예를 들어, 레코드 이름이 **acme.example.com**인 경우 CloudFront 배포에 **acme.example.com**이 대체 도메인 이름 중 하나로 포함되어야 합니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*에서 [대체 도메인 이름(CNAME) 사용](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)을 참조하세요.
+ **Amazon S3 버킷** - 레코드 이름은 Amazon S3 버킷 이름과 일치해야 합니다. 예를 들어, 버킷의 이름이 **acme.example.com**이면 이 레코드의 이름도 **acme.example.com**이어야 합니다.
그리고 웹사이트 호스팅용 버킷을 구성해야 합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [웹 사이트 호스팅에 대한 버킷 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html)을 참조하십시오.
**특수 문자**
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하십시오.
**와일드카드 문자**
이름에 별표(\$1) 문자를 사용할 수 있습니다. DNS는 이름에 표시되는 위치에 따라 \$1 문자를 와일드카드 또는 \$1 문자(ASCII 42)로 처리합니다. 자세한 내용은 [호스팅 영역 및 레코드의 이름에 별표(\$1) 사용](DomainNameFormat.md#domain-name-format-asterisk) 단원을 참조하십시오.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
**중요**
동일한 AWS 계정을 사용하여 트래픽을 라우팅하는 호스팅 영역과 리소스를 생성하고 리소스가 **엔드포인트** 목록에 표시되지 않는 경우 다음을 확인합니다.
**레코드 유형(Record type)**에 대해 지원되는 값을 선택했는지 확인합니다. 지원되는 값은 트래픽을 라우팅하는 리소스에 고유합니다. 예를 들어 S3 버킷으로 트래픽을 라우팅하려면 **레코드 유형(Record type**에 대한 **A - IPv4 주소**를 선택해야 합니다.
계정에 해당 리소스를 나열하는 데 필요한 IAM 권한이 있는지 확인합니다. 예를 들어, CloudFront 배포가 **엔드포인트(Endpoint)** 목록에 나타나려면, 계정에 `cloudfront:ListDistributions` 작업을 수행할 권한이 있어야 합니다.
IAM 정책 예제는 [Amazon Route 53 콘솔 사용에 필요한 권한](access-control-managing-permissions.md#console-required-permissions) 단원을 참조하세요.
다른 AWS 계정을 사용하여 호스팅 영역과 리소스를 생성한 경우 **엔드포인트** 목록에 리소스가 표시되지 않습니다. 리소스 유형이 **엔드포인트(Endpoint)**에 입력할 값을 결정하려면 다음 문서를 참조하세요.
**API Gateway 사용자 지정 리전 API와 엣지 최적화 API**
API Gateway 사용자 지정 리전 API와 엣지 최적화 API의 경우 다음 중 하나를 수행하세요.
+ **동일 계정을 사용하여 Route 53 호스팅 영역과 API를 생성한 경우** - **엔드포인트(Endpoint)**를 선택하고 목록에서 API를 선택합니다. API가 많은 경우 API 엔드포인트의 처음 몇 자를 입력하여 목록을 필터링할 수 있습니다.
**참고**
이 레코드 이름은 API의 사용자 지정 도메인 이름과 일치해야 합니다(예: **api.example.com**).
+ **다른 계정을 사용하여 Route 53 호스팅 영역과 API를 생성한 경우** - API에 대한 API 엔드포인트(예: **api.example.com**)를 입력합니다.
한 AWS 계정을 사용하여 현재 호스팅 영역을 생성하고 다른 계정을 사용하여 API를 생성한 경우 API Gateway API 아래의 **엔드포인트** 목록에 API가 표시되지 않습니다. ** APIs**
한 계정을 사용하여 현재 호스팅 영역을 생성하고 하나 이상의 다른 계정을 사용하여 모든 API 버킷을 생성한 경우 **엔드포인트(Endpoints)** 목록에는 **API Gateway APIs**의 **사용 가능한 대상 없음(No Targets Available)**이 표시됩니다. 자세한 내용은 [도메인 이름을 사용하여 Amazon API Gateway API로 트래픽 라우팅](routing-to-api-gateway.md) 단원을 참조하십시오.
**CloudFront 배포**
CloudFront 배포에 대해 다음 중 하나를 수행합니다.
+ **동일 계정을 사용하여 Route 53 호스팅 영역과 CloudFront 배포를 생성한 경우** - **엔드포인트(Endpoint)**를 선택하고 목록에서 배포를 선택합니다. 배포가 많을 경우에는 배포 도메인 이름의 처음 몇 자를 입력하여 목록을 필터링할 수 있습니다.
목록에 배포가 없을 때는 다음에 유의하십시오.
+ 이 레코드의 이름은 배포의 대체 도메인 이름과 일치해야 합니다.
+ 배포에 대체 도메인 이름을 추가한 경우 변경 사항이 모든 CloudFront 엣지 로케이션으로 전해지는데 15분 걸릴 수 있습니다. 변경 사항이 전파되기 전까지 Route 53은 새 대체 도메인 이름을 알 수 없습니다.
+ **다른 계정을 사용하여 Route 53 호스팅 영역 및 배포를 생성한 경우** - 배포의 CloudFront 도메인 이름을 입력합니다(예: **d111111abcdef8.cloudfront.net**).
한 AWS 계정을 사용하여 현재 호스팅 영역을 생성하고 다른 계정을 사용하여 배포를 생성한 경우 **엔드포인트** 목록에 배포가 표시되지 않습니다.
한 계정을 사용하여 현재 호스팅 영역을 생성하고 하나 이상의 다른 계정을 사용하여 모든 배포를 생성한 경우에는 **엔드포인트(Endpoints)** 목록에 **CloudFront 배포(CloudFront Distributions)** 아래 **사용 가능한 대상 없음(No Targets Available)**이 표시됩니다.
모든 엣지 로케이션으로 전파되지 않은 CloudFront 배포로 쿼리를 라우팅하지 않거나 사용자가 해당 콘텐츠에 액세스할 수 없습니다.
CloudFront 배포에는 레코드 이름과 일치하는 대체 도메인 이름이 포함되어야 합니다. 예를 들어, 레코드 이름이 **acme.example.com**인 경우 CloudFront 배포에 **acme.example.com**이 대체 도메인 이름 중 하나로 포함되어야 합니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*에서 [대체 도메인 이름(CNAME) 사용](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)을 참조하세요.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **레코드 유형(Record type)** 값이 **A - IPv4 주소**이고 하나는 값이 **AAAA — IPv6 주소**입니다. 자세한 내용은 [도메인 이름을 사용하여 Amazon CloudFront 배포로 트래픽 라우팅](routing-to-cloudfront-distribution.md) 단원을 참조하십시오.
**App Runner 서비스**
App Runner 서비스에 대해 다음 중 하나를 수행합니다.
+ **동일한 계정을 사용하여 Route 53 호스팅 영역과 App Runner 서비스를 생성한 경우**를 선택한 AWS 리전다음 목록에서 트래픽을 라우팅할 환경의 도메인 이름을 선택합니다.
+ **서로 다른 계정을 사용하여 Route 53 호스팅 영역과 App Runner를 생성한 경우** - 사용자 지정 도메인 이름을 입력합니다. 자세한 내용은 [App Runner의 사용자 지정 도메인 이름 관리](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html)를 참조하세요.
한 AWS 계정을 사용하여 현재 호스팅 영역을 생성하고 다른 계정을 사용하여 App Runner를 생성한 경우 App Runner가 **엔드포인트** 목록에 표시되지 않습니다.
자세한 내용은 [Amazon Route 53를 구성하여 App Runner 서비스로 트래픽 라우팅](routing-to-app-runner.md#routing-to-app-runner-configuring) 단원을 참조하십시오.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
Elastic Beanstalk 환경의 도메인 이름에 환경을 배포한 리전이 포함되는 경우 트래픽을 환경으로 라우팅하는 별칭 레코드를 생성할 수 있습니다. 예를 들어 도메인 이름 `my-environment.us-west-2.elasticbeanstalk.com`은 리전이 지정된 도메인 이름입니다.
2016년 초 이전에 생성된 환경의 경우 도메인 이름에 리전이 포함되지 않습니다. 이러한 환경으로 트래픽을 라우팅하려면 별칭 레코드 대신에 CNAME 레코드를 생성해야 합니다. 루트 도메인 이름에는 CNAME 레코드를 생성할 수 없습니다. 예를 들어 도메인 이름이 example.com이라면 acme.example.com에 대한 트래픽을 Elastic Beanstalk 환경으로 라우팅하는 레코드를 생성할 수 있습니다. 그러나 example.com에 대한 트래픽을 Elastic Beanstalk 환경으로 라우팅하는 레코드는 생성할 수 없습니다.
리전화된 하위 도메인이 있는 Elastic Beanstalk 환경에 대해서는 다음 중 한 가지 작업을 수행하세요.
+ **동일 계정을 사용하여 Route 53 호스팅 영역과 Elastic Beanstalk 환경을 생성한 경우** - **엔드포인트(Endpoint)**를 선택하고 목록에서 환경을 선택합니다. 환경이 많을 경우에는 환경에 대한 CNAME 속성의 처음 몇 자를 입력하여 목록을 필터링할 수 있습니다.
+ **서로 다른 계정을 사용하여 Route 53 호스팅 영역과 Elastic Beanstalk 환경을 생성한 경우** – Elastic Beanstalk 환경에 대한 CNAME 속성을 입력합니다.
자세한 내용은 [AWS Elastic Beanstalk 환경으로 트래픽 라우팅](routing-to-beanstalk-environment.md) 단원을 참조하십시오.
**ELB 로드 밸런서**
ELB 로드 밸런서의 경우 다음 중 하나를 수행합니다.
+ **동일 계정을 사용하여 Route 53 호스팅 영역과 로드 밸런서를 생성한 경우** – **엔드포인트(Endpoint)**를 선택하고 목록에서 로드 밸런서를 선택합니다. 로드 밸런서가 많은 경우에는 DNS 이름의 처음 몇 자를 입력하여 목록을 필터링할 수 있습니다.
+ **다른 계정을 사용하여 Route 53 호스팅 영역과 로드 밸런서를 생성한 경우** – [Elastic Load Balancing 로드 밸런서의 DNS 이름 가져오기](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) 절차에서 얻은 값을 입력합니다.
하나의 AWS 계정을 사용하여 현재 호스팅 영역을 생성하고 다른 계정을 사용하여 로드 밸런서를 생성한 경우 로드 밸런서는 **엔드포인트** 목록에 표시되지 않습니다.
한 계정을 사용하여 현재 호스팅 영역을 생성하고 하나 이상의 다른 계정을 사용하여 모든 로드 밸런서를 생성한 경우 **엔드포인트(Endpoints)** 목록에는 **Elastic Load Balancers** 아래 **사용 가능한 대상 없음(No Targets Available)**이 표시됩니다.
다른 계정의 애플리케이션 및 Classic Load Balancer의 경우 콘솔이 앞에 **dualstack.**을 추가합니다. 웹 브라우저와 같은 클라이언트가 도메인 이름(example.com) 또는 하위 도메인 이름(www.example.com)에 대한 IP 주소를 요청할 때 클라이언트는 IPv4 주소(A 레코드), IPv6 주소(AAAA 레코드), 또는 IPv4 및 IPv6 주소(별도 요청의 경우) 둘 다를 요청할 수 있습니다. **dualstack.**을 지정하면 Route 53에서 클라이언트가 요청한 IP 주소 형식에 따라 로드 밸런서에 적절한 IP 주소로 응답할 수 있습니다.
자세한 내용은 [ELB 로드 밸런서로 트래픽 라우팅](routing-to-elb-load-balancer.md) 단원을 참조하십시오.
**AWS Global Accelerator 액셀러레이터**
AWS Global Accelerator 액셀러레이터에 액셀러레이터의 DNS 이름을 입력합니다. 현재 AWS 계정을 사용하거나 다른 계정을 사용하여 생성한 액셀러레이터의 DNS 이름을 입력할 수 AWS 있습니다.
**Amazon S3 버킷**
웹 사이트 엔드포인트로 구성되는 Amazon S3 버킷은 다음 중 하나를 수행합니다.
+ **동일 계정을 사용하여 Route 53 호스팅 영역과 Amazon S3 버킷을를 생성한 경우** - **엔드포인트(Endpoint)**를 선택하고 목록에서 버킷을 선택합니다. 버킷이 많은 경우 DNS 이름의 처음 몇 자를 입력하여 목록을 필터링할 수 있습니다.
**엔드포인트(Endpoint)**의 값은 버킷의 Amazon S3 웹 사이트 엔드포인트로 변경됩니다.
+ **다른 계정을 사용하여 Route 53 호스팅 영역과 Amazon S3 버킷을 생성한 경우** – S3 버킷을 생성한 리전의 이름을 입력합니다. *Amazon Web Services 일반 참조*의 [Amazon S3 웹 사이트 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) 테이블에 있는 **웹 사이트 엔드포인트** 열에 표시되는 값을 사용합니다.
현재 AWS 계정 이외의 계정을 사용하여 Amazon S3 버킷을 생성한 경우 **엔드포인트** 목록에 버킷이 표시되지 않습니다.
웹 사이트 호스팅용 버킷을 구성해야 합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [웹 사이트 호스팅에 대한 버킷 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html)을 참조하십시오.
레코드의 이름은 Amazon S3 버킷의 이름과 일치해야 합니다. 예를 들어, Amazon S3 버킷의 이름이 **acme.example.com**이면 이 레코드의 이름도 **acme.example.com**이어야 합니다.
가중 별칭, 지연 시간 별칭, 장애 조치 별칭 또는 지리 위치 별칭 레코드 그룹에서 Amazon S3 버킷으로 쿼리를 라우팅하는 레코드 한 개만 생성할 수 있는데 그 이유는 레코드의 이름이 버킷 이름과 일치해야 하며, 버킷 이름은 전세계적으로 고유해야 하기 때문입니다.
**Amazon OpenSearch Service**
OpenSearch Service에 대해 다음 중 하나를 수행합니다.
+ **OpenSearch Service 사용자 지정 도메인**: 레코드의 이름이 사용자 지정 도메인과 일치해야 합니다. 예를 들어, 사용자 지정 도메인의 이름이 test.example.com이면 이 레코드의 이름도 test.example.com이어야 합니다.
+ **동일한 계정을 사용하여 Route 53 호스팅 영역과 OpenSearch Service 도메인을 생성한 경우**를 선택한 AWS 리전다음 도메인 이름을 선택합니다.
+ **서로 다른 계정을 사용하여 Route 53 호스팅 영역과 OpenSearch Service 도메인을 생성한 경우** - 사용자 지정 도메인 이름을 입력합니다. 자세한 내용은 [사용자 지정 엔드포인트 생성](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html)을 참조하세요.
하나의 AWS 계정을 사용하여 현재 호스팅 영역을 생성하고 다른 계정을 사용하여 OpenSearch Service 도메인을 생성한 경우 도메인이 **엔드포인트** 목록에 표시되지 않습니다.
하나의 계정을 사용하여 현재 호스팅 영역을 생성하고 하나 이상의 다른 계정을 사용하여 모든 OpenSearch Service 도메인을 생성한 경우 **엔드포인트** 목록의 **OpenSearch Service**에 **사용 가능한 대상 없음**이 표시됩니다.
자세한 내용은 [트래픽을 Amazon OpenSearch Service 도메인 엔드포인트로 라우팅하도록 Amazon Route 53 구성](routing-to-open-search-service.md#routing-to-open-search-service-configuring) 단원을 참조하십시오.
**Amazon VPC 인터페이스 엔드포인트**
Amazon VPC 인터페이스 엔드포인트에 대해 다음 중 하나를 수행하세요.
+ **동일 계정을 사용하여 Route 53 호스팅 영역과 인터페이스 엔드포인트를 생성한 경우** – **엔드포인트(Endpoint)**를 선택한 다음 목록에서 인터페이스 엔드포인트를 선택합니다. 인터페이스 엔드포인트가 많은 경우 DNS 호스트 이름의 처음 몇 자를 입력하여 목록을 필터링할 수 있습니다.
+ **다른 계정을 사용하여 Route 53 호스팅 영역과 인터페이스 엔드포인트를 생성한 경우** – 인터페이스 엔드포인트에 대한 DNS 호스트 이름(예: **vpce-123456789abcdef01-example-us-east-1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**)을 입력합니다.
한 AWS 계정을 사용하여 현재 호스팅 영역을 생성하고 다른 계정을 사용하여 인터페이스 엔드포인트를 생성한 경우 **VPC** 엔드포인트 아래의 **엔드포인트** 목록에 인터페이스 엔드포인트가 표시되지 않습니다.
한 계정을 사용하여 현재 호스팅 영역을 생성하고 하나 이상의 다른 계정을 사용하여 모든 인터페이스 엔드포인트를 생성한 경우 **엔드포인트(Endpoints)** 목록에는 **VPC 엔드포인트(VPC endpoints)** 아래에 **사용 가능한 대상 없음(No Targets Available)**이 표시됩니다.
자세한 내용은 [도메인 이름을 사용하여 Amazon Virtual Private Cloud 인터페이스 엔드포인트로 트래픽 라우팅](routing-to-vpc-interface-endpoint.md) 단원을 참조하십시오.
**이 호스팅 영역의 레코드**
이 호스팅 영역 내 레코드의 경우 **엔드포인트(Endpoint)**를 선택하고 해당하는 레코드를 선택합니다. 레코드가 많은 경우 이름의 처음 몇 자를 입력하여 목록을 필터링할 수 있습니다.
호스팅 영역에 기본 NS 및 SOA 레코드만 있는 경우에는 **엔드포인트(Endpoints)** 목록에 **사용 가능한 대상 없음(No Targets Available)**이 표시됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **레코드 유형(Record type)** 값이 **CNAME**인 레코드를 선택할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
# 단순 레코드에 특정한 값
단순 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**Topics**
+ [라우팅 정책](#rrsets-values-basic-routing-policy)
+ [레코드 이름](#rrsets-values-basic-name)
+ [값/트래픽 라우팅 대상](#rrsets-values-basic-value)
+ [레코드 유형](#rrsets-values-basic-type)
+ [TTL(초)](#rrsets-values-basic-ttl)
## 라우팅 정책
**단순 라우팅(Simple routing)**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **이름** 필드에 값(예: @ 기호)을 입력하지 마십시오.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-shared.md#rrsets-values-common-name) 섹션을 참조하십시오.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **CNAME – 정식 이름**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **NS - 이름 서버**
이름 서버의 도메인 이름(예: **ns1.example.com**)
**참고**
단순 라우팅 정책만 사용하여 NS 레코드를 지정할 수 있습니다.
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
Route 53이 DNS 쿼리에 응답하는 방식에 따라 **레코드 유형(Record type)**에 대한 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
# 단순 별칭 레코드에 특정한 값
별칭 레코드를 생성할 때 다음과 같은 값을 지정합니다. 자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하십시오.
**참고**
에서 Route 53를 사용하는 경우 AWS GovCloud (US) Region이 기능에 몇 가지 제한이 있습니다. 자세한 내용은 *AWS GovCloud (US) 사용 설명서*의 [Amazon Route 53 페이지](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html)를 참조하세요.
**Topics**
+ [라우팅 정책](#rrsets-values-alias-routing-policy)
+ [레코드 이름](#rrsets-values-alias-name)
+ [값/트래픽 라우팅 대상](#rrsets-values-alias-alias-target)
+ [레코드 유형](#rrsets-values-alias-type)
+ [대상 상태 평가](#rrsets-values-alias-evaluate-target-health)
## 라우팅 정책
**단순 라우팅(Simple routing)**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **이름** 필드에 값(예: @ 기호)을 입력하지 마십시오.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) 섹션을 참조하십시오.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
대상으로 지정할 수 있는 AWS 리소스에 대한 자세한 내용은 [값/라우팅 트래픽에 대한 별칭 레코드의 공통 값을 참조하세요](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
트래픽을 라우팅할 AWS 리소스를 기반으로 해당 값을 선택합니다.
**API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**Amazon VPC 인터페이스 엔드포인트**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**CloudFront 배포**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **유형(Type)** 값이 **A - IPv4 주소(A - IPv4 address)**이고 하나는 값이 **AAAA - IPv6 주소(AAAA - IPv6 address)**입니다.
**App Runner 서비스**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**ELB 로드 밸런서**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**Amazon S3 버킷**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**OpenSearch Service**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**호스팅 영역의 또 다른 레코드**
별칭을 생성 중인 레코드 유형을 선택합니다. **NS** 및 **SOA**를 제외한 모든 유형이 지원됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **유형** 값이 **CNAME**인 레코드로 트래픽을 라우팅할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
## 대상 상태 평가
**라우팅 정책** 값이 **단순**인 경우 **아니요** 또는 기본값인 **예** 중 하나를 선택할 수 있습니다. **대상 상태 평가**는 **단순** 라우팅에 영향을 미치지 않기 때문입니다. 지정된 이름과 유형이 있는 레코드가 하나만 있는 경우 Route 53은 리소스가 정상인지 여부에 관계없이 해당 레코드의 값을 사용하여 DNS 쿼리에 응답합니다.
다른 라우팅 정책의 경우 별칭 레코드가 참조하는 리소스의 상태를 Route 53가 확인하는지 여부가 **대상 상태 평가**에 따라 결정됩니다.
+ **대상 상태 평가가 운영상의 이점을 제공하는 서비스**: 로드 밸런서(ELB) 및 로드 밸런서가 있는 AWS Elastic Beanstalk 환경의 경우 **대상 상태 평가**를 **예**로 설정하면 Route 53가 비정상 리소스로 트래픽이 라우팅되지 않도록 할 수 있습니다.
+ **고가용성 서비스**: Amazon S3 버킷, VPC 인터페이스 엔드포인트, Amazon API Gateway AWS Global Accelerator, Amazon OpenSearch Service 및 Amazon VPC Lattice와 같은 서비스의 경우 대상 **상태 평가는** 고가용성을 위해 설계되었기 때문에 운영상의 이점을 제공하지 않습니다. 이러한 서비스를 사용하는 장애 조치 시나리오의 경우 [Route 53 상태 확인](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html)을 대신 사용합니다.
다양한 AWS 서비스에서 **대상 상태 평가**의 작동 방식에 대한 자세한 내용은 API 참조의 [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth) 설명서를 참조하세요.
# 장애 조치 레코드에 특정한 값
장애 조치 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**참고**
프라이빗 호스팅 영역에서 장애 조치 레코드를 생성하는 방법에 대한 자세한 내용은 [프라이빗 호스팅 영역에서 장애 조치 구성](dns-failover-private-hosted-zones.md) 단원을 참조하세요
**Topics**
+ [라우팅 정책](#rrsets-values-failover-routing-policy)
+ [레코드 이름](#rrsets-values-failover-name)
+ [레코드 유형](#rrsets-values-failover-type)
+ [TTL(초)](#rrsets-values-failover-ttl)
+ [값/트래픽 라우팅 대상](#rrsets-values-failover-value)
+ [장애 조치 레코드 유형](#rrsets-values-failover-record-type)
+ [상태 확인](#rrsets-values-failover-associate-with-health-check)
+ [레코드 ID](#rrsets-values-failover-set-id)
## 라우팅 정책
**장애 조치(Failover)**를 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름(Record name)** 필드에 값(예: @ 기호)을 입력하지 마세요.
장애 조치 레코드 그룹의 레코드 모두에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-shared.md#rrsets-values-common-name) 섹션을 참조하십시오.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
기본 및 보조 장애 조치 레코드 모두에 대해 동일 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **CNAME – 정식 이름**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## 장애 조치 레코드 유형
이 레코드에 해당하는 값을 선택합니다. 장애 조치가 제대로 작동하려면 기본 및 보조 장애 조치 레코드를 각각 1개씩 생성해야 합니다.
**레코드 이름(Record name)** 및 **레코드 유형(Record type)** 값이 장애 조치 레코드와 같은 비-장애 조치 레코드를 생성할 수 있습니다.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가(Evaluate Target Health)**에서 **예(Yes)**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 레코드 ID
기본 및 보조 레코드를 고유하게 식별하는 값을 선택합니다.
# 장애 조치 별칭 레코드에 특정한 값
장애 조치 별칭 레코드를 생성할 때 다음과 같은 값을 지정합니다.
자세한 내용은 다음 주제를 참조하세요.
+ 프라이빗 호스팅 영역에서 장애 조치 레코드를 생성하는 방법에 대한 자세한 내용은 [프라이빗 호스팅 영역에서 장애 조치 구성](dns-failover-private-hosted-zones.md) 단원을 참조하세요
+ 별칭 레코드에 대한 자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하세요.
**Topics**
+ [라우팅 정책](#rrsets-values-failover-alias-routing-policy)
+ [레코드 이름](#rrsets-values-failover-alias-name)
+ [레코드 유형](#rrsets-values-failover-alias-type)
+ [값/트래픽 라우팅 대상](#rrsets-values-failover-alias-alias-target)
+ [장애 조치 레코드 유형](#rrsets-values-failover-alias-failover-record-type)
+ [상태 확인](#rrsets-values-failover-alias-associate-with-health-check)
+ [대상 상태 평가](#rrsets-values-failover-alias-evaluate-target-health)
+ [레코드 ID](#rrsets-values-failover-alias-set-id)
## 라우팅 정책
**장애 조치(Failover)**를 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름(Record name)** 필드에 값(예: @ 기호)을 입력하지 마세요.
장애 조치 레코드 그룹의 레코드 모두에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
트래픽을 라우팅할 AWS 리소스를 기반으로 해당 값을 선택합니다. 기본 및 보조 장애 조치 레코드 모두에 대해 동일 값을 선택합니다.
**API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**Amazon VPC 인터페이스 엔드포인트**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**CloudFront 배포**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **유형(Type)** 값이 **A - IPv4 주소(A - IPv4 address)**이고 하나는 값이 **AAAA - IPv6 주소(AAAA - IPv6 address)**입니다.
**App Runner 서비스**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**ELB 로드 밸런서**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**Amazon S3 버킷**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**OpenSearch Service**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**호스팅 영역의 또 다른 레코드**
별칭을 생성 중인 레코드 유형을 선택합니다. **NS** 및 **SOA**를 제외한 모든 유형이 지원됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **유형** 값이 **CNAME**인 레코드로 트래픽을 라우팅할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
대상으로 지정할 수 있는 AWS 리소스에 대한 자세한 내용은 [값/라우팅 트래픽에 대한 별칭 레코드의 공통 값을 참조하세요](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
**참고**
주 장애 조치 및 보조 장애 조치 레코드를 만들 때 **이름(Name)** 및 **레코드 유형(Record type)**에 대해 동일한 값을 갖는 하나의 장애 조치(failover) 와 하나의 장애 조치 *별칭(alias)*을 선택적으로 만들 수 있습니다. 장애 조치와 장애 조치 별칭 레코드를 혼합할 경우 둘 중 하나는 기본 레코드가 될 수 있습니다.
## 장애 조치 레코드 유형
이 레코드에 해당하는 값을 선택합니다. 장애 조치가 제대로 작동하려면 기본 및 보조 장애 조치 레코드를 각각 1개씩 생성해야 합니다.
**레코드 이름(Record name)** 및 **레코드 유형(Record type)** 값이 장애 조치 레코드와 같은 비-장애 조치 레코드를 생성할 수 있습니다.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가(Evaluate Target Health)**에서 **예(Yes)**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 대상 상태 평가
**엔드포인트**에서 지정된 리소스의 상태를 확인하여 Route 53가 레코드를 사용해 DNS 쿼리에 응답할지 여부를 결정하게 하려는 경우 **예**를 선택합니다.
다음 사항에 유의하세요.
**API Gateway 사용자 지정 리전 API와 엣지 최적화 API**
엔드포인트가 API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API인 경우 **대상 상태 평가(Evaluate target health)**를 **예(Yes)**로 설정하기 위한 특별한 요구 사항은 없습니다.
**CloudFront 배포**
엔드포인트가 CloudFront 배포인 경우 **대상 상태 평가**를 **예**로 설정할 수 없습니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**엔드포인트(Endpoint)**에 Elastic Beanstalk 환경을 지정하고 환경에 ELB 로드 밸런서가 포함된 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. (하나의 환경에 한 개 이상의 Amazon EC2 인스턴스가 포함된 경우 ELB 로드 밸런서가 자동으로 포함됩니다.) **대상 상태 평가**를 **예**로 설정했는데 정상인 Amazon EC2 인스턴스가 없거나 로드 밸런서 자체가 비정상인 경우 Route 53는 양호한 다른 리소스로 쿼리를 라우팅합니다.
환경에 하나의 Amazon EC2 인스턴스가 포함된 경우에는 특별한 요구 사항이 없습니다.
**ELB 로드 밸런서**
상태 확인 동작은 로드 밸런서의 유형에 따라 달랍니다.
+ **Classic Load Balancer**: **엔드포인트(Endpoint)**에 ELB Classic Load Balancer를 지정한 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. **대상 상태 평가**를 **예**로 설정하고 EC2 인스턴스가 정상 상태가 아니거나 로드 밸런서 자체가 비정상인 경우 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ **Application Load Balancer 및 Network Load Balancer** - ELB Application Load Balancer 또는 Network Load Balancer를 지정하고 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정한 경우 은 로드 밸런서와 연결된 대상 그룹의 상태에 따라 쿼리를 로드 밸런서로 라우팅합니다.
+ Application Load Balancer 또는 Network Load Balancer가 정상 상태로 간주되려면 대상을 포함하는 대상 그룹에 정상 상태 대상이 하나 이상 포함되어야 합니다. 대상 그룹에 정상이 아닌 대상만 포함되는 경우 로드 밸런서는 정상이 아닌 상태로 간주되고 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ 등록된 대상이 없는 대상 그룹은 정상이 아닌 상태로 간주됩니다.
로드 밸런서를 생성할 때 Elastic Load Balancing 상태 확인에 대한 설정을 구성하게 되는데, 이러한 확인은 Route 53 상태 확인은 아니지만 비슷한 기능을 수행합니다. ELB 로드 밸런서에 등록하는 EC2 인스턴스에 대해 Route 53 상태 확인을 생성하지 마십시오.
**S3 버킷**
엔드포인트가 S3 버킷인 경우 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정하는 데 필요한 특정 요건은 없습니다.
**Amazon VPC 인터페이스 엔드포인트**
엔드포인트가 Amazon VPC 인터페이스 엔드포인트인 경우 **대상 상태 평가**를 **예**로 설정하는 데 필요한 특별한 요구 사항이 없습니다.
**동일 호스팅 영역 내 다른 레코드**
**엔드포인트**에서 지정하는 AWS 리소스가 레코드 또는 레코드 그룹(예: 가중치 기반 레코드 그룹)이지만 다른 별칭 레코드가 아닌 경우 상태 확인을 엔드포인트의 모든 레코드와 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 생략하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting) 단원을 참조하십시오.
## 레코드 ID
기본 및 보조 레코드를 고유하게 식별하는 값을 선택합니다.
# 지리 위치 레코드에 특정한 값
지리 위치 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**Topics**
+ [라우팅 정책](#rrsets-values-geo-routing-policy)
+ [레코드 이름](#rrsets-values-geo-name)
+ [레코드 유형](#rrsets-values-geo-type)
+ [TTL(초)](#rrsets-values-geo-ttl)
+ [값/트래픽 라우팅 대상](#rrsets-values-geo-value)
+ [Location](#rrsets-values-geo-location)
+ [미국 주](#rrsets-values-geo-sublocation)
+ [상태 확인](#rrsets-values-geo-associate-with-health-check)
+ [레코드 ID](#rrsets-values-geo-set-id)
## 라우팅 정책
**지리적 위치(Geolocation)**를 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **이름** 필드에 값(예: @ 기호)을 입력하지 마십시오.
지리 위치 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-shared.md#rrsets-values-common-name) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
지리 위치 레코드 그룹의 모든 레코드에 대해 동일 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **CNAME – 정식 이름**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## Location
쿼리를 보낸 위치를 기반으로 하는 DNS 쿼리에 응답하도록 Route 53을 구성할 때는 Route 53이 이 레코드 설정으로 응답하길 원하는 대륙 또는 국가를 선택합니다. Route 53이 미국의 개별 주에 대한 DNS 쿼리에 응답하길 원할 경우 먼저 **위치(Location)**목록에서 **미국(United States)**을 선택한 다음 **하위 위치(Sublocation)** 그룹에서 주를 선택합니다.
프라이빗 호스팅 영역의 경우 리소스가 AWS 리전 있는와 가장 가까운 대륙, 국가 또는 하위 부문을 선택합니다. 예를 들어 리소스가 us-east-1에 있으면 북미, 미국 또는 버지니아를 지정할 수 있습니다.
**중요**
**위치(Location)**에 대한 **기본(Default)** 값을 갖는 하나의 지리적 위치 레코드를 생성하는 것이 좋습니다. 그러면 레코드를 생성하지 않은 지리적 위치와 Route 53이 위치를 식별하지 못하는 IP 주소도 포함됩니다.
**레코드 이름(Record name)** 및 **레코드 유형(Record type)** 값이 지리적 위치 레코드와 같은 값을 갖는 비-지리적 위치 레코드를 생성할 수 없습니다.
자세한 내용은 [지리적 라우팅](routing-policy-geo.md) 단원을 참조하십시오.
다음은 Amazon Route 53이 각 대륙과 연결되는 국가입니다. 국가 코드는 ISO 3166부터 시작합니다. 자세한 내용은 Wikipedia 도움말 [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)를 참조하세요.
**아프리카(AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**남극 대륙(AN)**
AQ, GS, TF
**아시아(AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**유럽(EU)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
일부 공급자는 TR이 아시아에 있다고 간주하며 IP 주소는 이를 반영합니다.
**북아메리카(NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**오세아니아(OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**남아메리카(SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**참고**
Route 53은 다음 국가, 즉 부베 섬(BV), 크리스마스 섬(CX), 서부 사하라(EH), 허드 섬 및 맥도널드 제도(HM)의 지리 위치 레코드 생성을 지원하지 않습니다. 이들 국가의 IP 주소에 관한 데이터가 없습니다.
## 미국 주
Route 53이 쿼리가 발생한 미국 주를 토대로 DNS 쿼리에 응답하도록 구성할 때는 **미국 주(U.S. states)** 목록에서 주를 선택합니다. 미국 영토(예: 푸에르토리코)는 **위치** 목록에 국가로 표시됩니다.
**중요**
일부 IP 주소는 개별 주가 아니라 미국과 관련이 있습니다. 미국 내 모든 주의 레코드를 생성할 경우에는 이러한 무관한 IP 주소의 쿼리를 라우팅할 미국 레코드도 생성하는 것이 좋습니다. 미국의 레코드를 생성하지 않으면 Route 53이 비연관 미국 IP 주소의 DNS 쿼리에 기본 지리 위치 레코드(생성한 경우)의 설정 또는 "응답 없음"으로 응답합니다.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가(Evaluate Target Health)**에서 **예(Yes)**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
지리 위치 레코드에서 엔드포인트가 양호하지 않을 경우 Route 53은 규모가 더 큰 관련 지리적 리전의 레코드를 조회합니다. 예를 들어, 미국 내 주, 미국, 북미 및 전체 위치에 대한 레코드가 있다고 가정합니다(**위치**가 **기본값**임). 주 레코드의 엔드포인트가 양호하지 않을 경우 Route 53은 미국, 북미 및 전체 위치 순으로 엔드포인트가 양호한 레코드를 찾을 때까지 레코드를 확인합니다. 모든 지리적 위치에 대한 레코드를 포함하여 모든 적용 가능한 레코드가 비정상적인 경우 Route 53은 가장 작은 지리적 리전에 대한 레코드 값을 사용하여 DNS 쿼리에 응답합니다.
## 레코드 ID
지리 위치 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 선택합니다.
# 지리 위치 별칭 레코드에 특정한 값
지리 위치 별칭 레코드를 생성할 때 다음과 같은 값을 지정합니다.
자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하십시오.
**Topics**
+ [라우팅 정책](#rrsets-values-geo-alias-routing-policy)
+ [레코드 이름](#rrsets-values-geo-alias-name)
+ [레코드 유형](#rrsets-values-geo-alias-type)
+ [값/트래픽 라우팅 대상](#rrsets-values-geo-alias-alias-target)
+ [Location](#rrsets-values-geo-alias-location)
+ [미국 주](#rrsets-values-geo-alias-sublocation)
+ [상태 확인](#rrsets-values-geo-alias-associate-with-health-check)
+ [대상 상태 평가](#rrsets-values-geo-alias-evaluate-target-health)
+ [레코드 ID](#rrsets-values-geo-alias-set-id)
## 라우팅 정책
**지리적 위치(Geolocation)**를 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름(Record name)** 필드에 값(예: @ 기호)을 입력하지 마세요.
지리 위치 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
트래픽을 라우팅할 AWS 리소스를 기반으로 해당 값을 선택합니다. 지리 위치 레코드 그룹의 모든 레코드에 대해 동일 값을 선택합니다.
**API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**Amazon VPC 인터페이스 엔드포인트**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**CloudFront 배포**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **유형(Type)** 값이 **A - IPv4 주소(A - IPv4 address)**이고 하나는 값이 **AAAA - IPv6 주소(AAAA - IPv6 address)**입니다.
**App Runner 서비스**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**ELB 로드 밸런서**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**Amazon S3 버킷**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**OpenSearch Service**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**호스팅 영역의 또 다른 레코드**
별칭을 생성 중인 레코드 유형을 선택합니다. **NS** 및 **SOA**를 제외한 모든 유형이 지원됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **유형** 값이 **CNAME**인 레코드로 트래픽을 라우팅할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
대상으로 지정할 수 있는 AWS 리소스에 대한 자세한 내용은 섹션을 참조하세요[값/트래픽 라우팅 대상](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
## Location
쿼리를 보낸 위치를 기반으로 하는 DNS 쿼리에 응답하도록 Route 53을 구성할 때는 Route 53이 이 레코드 설정으로 응답하길 원하는 대륙 또는 국가를 선택합니다. Route 53이 미국의 개별 주에 대한 DNS 쿼리에 응답하길 원할 경우 먼저 **위치(Location)** 목록에서 **미국(United States)**을 선택한 다음 **미국 주(U.S. states)** 목록에서 주를 선택합니다.
프라이빗 호스팅 영역의 경우 리소스가 AWS 리전 있는와 가장 가까운 대륙, 국가 또는 하위 부문을 선택합니다. 예를 들어 리소스가 us-east-1에 있으면 북미, 미국 또는 버지니아를 지정할 수 있습니다.
**중요**
**위치(Location)**에 대한 **기본(Default)** 값을 갖는 하나의 지리적 위치 레코드를 생성하는 것이 좋습니다. 그러면 레코드를 생성하지 않은 지리적 위치와 Route 53이 위치를 식별하지 못하는 IP 주소도 포함됩니다.
**레코드 이름(Record name)** 및 **레코드 유형(Record type)** 값이 지리적 위치 레코드와 같은 값을 갖는 비-지리적 위치 레코드를 생성할 수 없습니다.
자세한 내용은 [지리적 라우팅](routing-policy-geo.md) 단원을 참조하십시오.
다음은 Amazon Route 53이 각 대륙과 연결되는 국가입니다. 국가 코드는 ISO 3166부터 시작합니다. 자세한 내용은 Wikipedia 도움말 [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)를 참조하세요.
**아프리카(AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**남극 대륙(AN)**
AQ, GS, TF
**아시아(AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**유럽(EU)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
일부 공급자는 TR이 아시아에 있다고 간주하며 IP 주소는 이를 반영합니다.
**북아메리카(NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**오세아니아(OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**남아메리카(SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**참고**
Route 53은 다음 국가, 즉 부베 섬(BV), 크리스마스 섬(CX), 서부 사하라(EH), 허드 섬 및 맥도널드 제도(HM)의 지리 위치 레코드 생성을 지원하지 않습니다. 이들 국가의 IP 주소에 관한 데이터가 없습니다.
## 미국 주
Route 53이 쿼리가 발생한 미국 주를 토대로 DNS 쿼리에 응답하도록 구성할 때는 **미국 주(U.S. states)** 목록에서 주를 선택합니다. 미국 영토(예: 푸에르토리코)는 **위치** 목록에 국가로 표시됩니다.
**중요**
일부 IP 주소는 개별 주가 아니라 미국과 관련이 있습니다. 미국 내 모든 주의 레코드를 생성할 경우에는 이러한 무관한 IP 주소의 쿼리를 라우팅할 미국 레코드도 생성하는 것이 좋습니다. 미국의 레코드를 생성하지 않으면 Route 53이 비연관 미국 IP 주소의 DNS 쿼리에 기본 지리 위치 레코드(생성한 경우)의 설정 또는 "응답 없음"으로 응답합니다.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가**에서 **예**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
지리 위치 레코드에서 엔드포인트가 양호하지 않을 경우 Route 53은 규모가 더 큰 관련 지리적 리전의 레코드를 조회합니다. 예를 들어, 미국 내 주, 미국, 북미 및 전체 위치에 대한 레코드가 있다고 가정합니다(**위치**가 **기본값**임). 주 레코드의 엔드포인트가 양호하지 않을 경우 Route 53은 미국, 북미 및 전체 위치 순으로 엔드포인트가 양호한 레코드를 찾을 때까지 레코드를 확인합니다. 모든 지리적 위치에 대한 레코드를 포함하여 모든 적용 가능한 레코드가 비정상적인 경우 Route 53은 가장 작은 지리적 리전에 대한 레코드 값을 사용하여 DNS 쿼리에 응답합니다.
## 대상 상태 평가
**엔드포인트**에서 지정된 리소스의 상태를 확인하여 Route 53가 레코드를 사용해 DNS 쿼리에 응답할지 여부를 결정하게 하려는 경우 **예**를 선택합니다.
다음 사항에 유의하세요.
**API Gateway 사용자 지정 리전 API와 엣지 최적화 API**
엔드포인트가 API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API인 경우 **대상 상태 평가**를 **예**로 설정하기 위한 특별한 요구 사항은 없습니다.
**CloudFront 배포**
엔드포인트가 CloudFront 배포인 경우 **대상 상태 평가**를 **예**로 설정할 수 없습니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**엔드포인트(Endpoint)**에 Elastic Beanstalk 환경을 지정하고 환경에 ELB 로드 밸런서가 포함된 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. (하나의 환경에 한 개 이상의 Amazon EC2 인스턴스가 포함된 경우 ELB 로드 밸런서가 자동으로 포함됩니다.) **대상 상태 평가**를 **예**로 설정했는데 정상인 Amazon EC2 인스턴스가 없거나 로드 밸런서 자체가 비정상인 경우 Route 53는 양호한 다른 리소스로 쿼리를 라우팅합니다.
환경에 하나의 Amazon EC2 인스턴스가 포함된 경우에는 특별한 요구 사항이 없습니다.
**ELB 로드 밸런서**
상태 확인 동작은 로드 밸런서의 유형에 따라 달랍니다.
+ **Classic Load Balancer**: **엔드포인트(Endpoint)**에 ELB Classic Load Balancer를 지정한 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. **대상 상태 평가**를 **예**로 설정하고 EC2 인스턴스가 정상 상태가 아니거나 로드 밸런서 자체가 비정상인 경우 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ **Application Load Balancer 및 Network Load Balancer** - ELB Application Load Balancer 또는 Network Load Balancer를 지정하고 **대상 상태 평가**를 **예**로 설정한 경우 Route 53는 로드 밸런서와 연결된 대상 그룹의 상태에 따라 쿼리를 로드 밸런서로 라우팅합니다.
+ Application 또는 Network Load Balancer가 정상 상태로 간주되려면 대상을 포함하는 모든 대상 그룹에 정상 상태 대상이 하나 이상 포함되어야 합니다. 대상 그룹에 정상이 아닌 대상만 포함되는 경우 로드 밸런서는 정상이 아닌 상태로 간주되고 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ 등록된 대상이 없는 대상 그룹은 정상이 아닌 상태로 간주됩니다.
로드 밸런서를 생성할 때 Elastic Load Balancing 상태 확인에 대한 설정을 구성하게 되는데, 이러한 확인은 Route 53 상태 확인은 아니지만 비슷한 기능을 수행합니다. ELB 로드 밸런서에 등록하는 EC2 인스턴스에 대해 Route 53 상태 확인을 생성하지 마십시오.
**S3 버킷**
엔드포인트가 S3 버킷인 경우 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정하는 데 필요한 특정 요건은 없습니다.
**Amazon VPC 인터페이스 엔드포인트**
엔드포인트가 Amazon VPC 인터페이스 엔드포인트인 경우 **대상 상태 평가**를 **예**로 설정하는 데 필요한 특별한 요구 사항이 없습니다.
**동일 호스팅 영역 내 다른 레코드**
**엔드포인트**에서 지정하는 AWS 리소스가 레코드 또는 레코드 그룹(예: 가중치 기반 레코드 그룹)이지만 다른 별칭 레코드가 아닌 경우 상태 확인을 엔드포인트의 모든 레코드와 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 생략하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting) 단원을 참조하십시오.
## 레코드 ID
지리 위치 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 선택합니다.
# 지리 근접성 레코드에 특정된 값
지리 근접성 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**Topics**
+ [라우팅 정책](#rrsets-values-geoprox-routing-policy)
+ [레코드 이름](#rrsets-values-geoprox-name)
+ [레코드 유형](#rrsets-values-geoprox-type)
+ [TTL(초)](#rrsets-values-geoprox-ttl)
+ [값/트래픽 라우팅 대상](#rrsets-values-geoprox-value)
+ [엔드포인트 위치](#rrsets-values-geoprox-endpoint-location)
+ [편향](#rrsets-values-geoprox-bias)
+ [상태 확인](#rrsets-values-geoprox-associate-with-health-check)
+ [레코드 ID](#rrsets-values-geoprox-set-id)
## 라우팅 정책
**지리 근접성**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **이름** 필드에 값(예: @ 기호)을 입력하지 마십시오.
지리 근접성 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-shared.md#rrsets-values-common-name) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
지리 근접성 레코드 그룹의 모든 레코드에 대해 동일한 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **CNAME – 정식 이름**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## 엔드포인트 위치
다음 방법 중 하나를 사용하여 리소스 엔드포인트 위치를 지정할 수 있습니다.
**사용자 지정 좌표**
지리적 영역의 경도와 위도를 지정합니다.
**AWS 리전**
**위치** 목록에서 사용 가능한 리전을 선택합니다.
리전에 대한 자세한 내용은 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요.
**AWS 로컬 영역 그룹**
**위치** 목록에서 사용 가능한 로컬 영역 그룹을 선택합니다.
로컬 영역에 대한 자세하 내용은 *AWS 로컬 영역 사용 설명서*의 [사용 가능한 로컬 영역](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html)을 참조하세요. 로컬 영역 그룹은 일반적으로 종료 문자가 없는 로컬 영역입니다. 예를 들어 로컬 영역이 `us-east-1-bue-1a`인 경우 로컬 영역 그룹은 `us-east-1-bue-1`입니다.
[describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI 명령을 사용하여 특정 로컬 영역에 대한 로컬 영역 그룹을 식별할 수도 있습니다.
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
이 명령은 로컬 영역 `us-west-2-den-1a`가 로컬 영역 그룹 `us-west-2-den-1`에 속하도록 지정하여 `"GroupName": "us-west-2-den-1"`를 반환합니다.
**레코드 이름** 및 **레코드 유형** 값이 지리 근접성 레코드와 같은 값을 갖는 비-지리 근접성 레코드를 생성할 수 없습니다.
동일한 레코드 이름 및 레코드 유형에 대해 동일한 위치를 지정하는 지리 근접성 리소스 레코드 세트 2개를 생성할 수도 없습니다.
## 편향
편향은 Route 53가 트래픽을 리소스로 라우팅하는 지리적 영역의 크기를 확장하거나 축소합니다. 긍정 편향은 영역을 확장하고 부정 편향은 영역을 축소합니다. 자세한 내용은 [Amazon Route 53가 바이어스를 사용하여 트래픽을 라우팅하려면](routing-policy-geoproximity.md#routing-policy-geoproximity-bias) 단원을 참조하십시오.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 지리 근접성 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가**에서 **예**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
지리 근접성 레코드의 경우 엔드포인트가 비정상이면 Route 53는 여전히 정상인 가장 가까운 엔드포인트를 찾습니다.
## 레코드 ID
지리 근접성 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 입력합니다.
# 지리 근접성 별칭 레코드에 특정된 값
지리 근접성 별칭 레코드를 생성할 때 다음과 같은 값을 지정합니다.
자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하십시오.
**Topics**
+ [라우팅 정책](#rrsets-values-geoprox-alias-routing-policy)
+ [레코드 이름](#rrsets-values-geoprox-alias-name)
+ [레코드 유형](#rrsets-values-geoprox-alias-type)
+ [값/트래픽 라우팅 대상](#rrsets-values-geoprox-alias-alias-target)
+ [엔드포인트 위치](#rrsets-values-geoprox-alias-endpoint-location)
+ [편향](#rrsets-values-geoprox-alias-bias)
+ [상태 확인](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [대상 상태 평가](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [레코드 ID](#rrsets-values-geoprox-alias-set-id)
## 라우팅 정책
**지리 근접성**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름** 필드에 값(예: @ 기호)을 입력하지 마세요.
지리 근접성 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
트래픽을 라우팅할 AWS 리소스를 기반으로 해당 값을 선택합니다. 지리 근접성 레코드 그룹의 모든 레코드에 대해 동일한 값을 선택합니다.
**API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**Amazon VPC 인터페이스 엔드포인트**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**CloudFront 배포**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **유형(Type)** 값이 **A - IPv4 주소(A - IPv4 address)**이고 하나는 값이 **AAAA - IPv6 주소(AAAA - IPv6 address)**입니다.
**App Runner 서비스**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**ELB 로드 밸런서**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**Amazon S3 버킷**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**OpenSearch Service**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**호스팅 영역의 또 다른 레코드**
별칭을 생성 중인 레코드 유형을 선택합니다. **NS** 및 **SOA**를 제외한 모든 유형이 지원됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **유형** 값이 **CNAME**인 레코드로 트래픽을 라우팅할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
대상으로 지정할 수 있는 AWS 리소스에 대한 자세한 내용은 섹션을 참조하세요[값/트래픽 라우팅 대상](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
## 엔드포인트 위치
다음 방법 중 하나를 사용하여 리소스 엔드포인트 위치를 지정할 수 있습니다.
**사용자 지정 좌표**
지리적 영역의 경도와 위도를 지정합니다.
**AWS 리전**
**위치** 목록에서 사용 가능한 리전을 선택합니다.
리전에 대한 자세한 내용은 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요.
**AWS 로컬 영역 그룹**
**위치** 목록에서 사용 가능한 로컬 영역 리전을 선택합니다.
로컬 영역에 대한 자세하 내용은 *AWS 로컬 영역 사용 설명서*의 [사용 가능한 로컬 영역](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html)을 참조하세요. 로컬 영역 그룹은 일반적으로 종료 문자가 없는 로컬 영역입니다. 예를 들어 로컬 영역이 `us-east-1-bue-1a`인 경우 로컬 영역 그룹은 `us-east-1-bue-1`입니다.
[describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI 명령을 사용하여 특정 로컬 영역에 대한 로컬 영역 그룹을 식별할 수도 있습니다.
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
이 명령은 로컬 영역 `us-west-2-den-1a`가 로컬 영역 그룹 `us-west-2-den-1`에 속하도록 지정하여 `"GroupName": "us-west-2-den-1"`를 반환합니다.
**레코드 이름** 및 **레코드 유형** 값이 지리 근접성 레코드와 같은 값을 갖는 비-지리 근접성 레코드를 생성할 수 없습니다.
동일한 레코드 이름 및 레코드 유형에 대해 동일한 위치를 지정하는 지리 근접성 리소스 레코드 세트 2개를 생성할 수도 없습니다.
자세한 내용은 available-local-zones.html을 참조하세요.
## 편향
편향은 Route 53가 트래픽을 리소스로 라우팅하는 지리적 영역의 크기를 확장하거나 축소합니다. 긍정 편향은 영역을 확장하고 부정 편향은 영역을 축소합니다. 자세한 내용은 [Amazon Route 53가 바이어스를 사용하여 트래픽을 라우팅하려면](routing-policy-geoproximity.md#routing-policy-geoproximity-bias) 단원을 참조하십시오.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 지리 근접성 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가**에서 **예**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
지리 근접성 레코드의 경우 엔드포인트가 비정상이면 Route 53는 여전히 정상인 가장 가까운 엔드포인트를 찾습니다.
## 대상 상태 평가
**엔드포인트**에서 지정된 리소스의 상태를 확인하여 Route 53가 레코드를 사용해 DNS 쿼리에 응답할지 여부를 결정하게 하려는 경우 **예**를 선택합니다.
다음 사항에 유의하세요.
**API Gateway 사용자 지정 리전 API와 엣지 최적화 API**
엔드포인트가 API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API인 경우 **대상 상태 평가**를 **예**로 설정하기 위한 특별한 요구 사항은 없습니다.
**CloudFront 배포**
엔드포인트가 CloudFront 배포인 경우 **대상 상태 평가**를 **예**로 설정할 수 없습니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**엔드포인트(Endpoint)**에 Elastic Beanstalk 환경을 지정하고 환경에 ELB 로드 밸런서가 포함된 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. (하나의 환경에 한 개 이상의 Amazon EC2 인스턴스가 포함된 경우 ELB 로드 밸런서가 자동으로 포함됩니다.) **대상 상태 평가**를 **예**로 설정했는데 정상인 Amazon EC2 인스턴스가 없거나 로드 밸런서 자체가 비정상인 경우 Route 53는 양호한 다른 리소스로 쿼리를 라우팅합니다.
환경에 하나의 Amazon EC2 인스턴스가 포함된 경우에는 특별한 요구 사항이 없습니다.
**ELB 로드 밸런서**
상태 확인 동작은 로드 밸런서의 유형에 따라 달랍니다.
+ **Classic Load Balancer**: **엔드포인트(Endpoint)**에 ELB Classic Load Balancer를 지정한 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. **대상 상태 평가**를 **예**로 설정하고 EC2 인스턴스가 정상 상태가 아니거나 로드 밸런서 자체가 비정상인 경우 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ **Application Load Balancer 및 Network Load Balancer** - ELB Application Load Balancer 또는 Network Load Balancer를 지정하고 **대상 상태 평가**를 **예**로 설정한 경우 Route 53는 로드 밸런서와 연결된 대상 그룹의 상태에 따라 쿼리를 로드 밸런서로 라우팅합니다.
+ Application 또는 Network Load Balancer가 정상 상태로 간주되려면 대상을 포함하는 모든 대상 그룹에 정상 상태 대상이 하나 이상 포함되어야 합니다. 대상 그룹에 정상이 아닌 대상만 포함되는 경우 로드 밸런서는 정상이 아닌 상태로 간주되고 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ 등록된 대상이 없는 대상 그룹은 정상이 아닌 상태로 간주됩니다.
로드 밸런서를 생성할 때 Elastic Load Balancing 상태 확인에 대한 설정을 구성하게 되는데, 이러한 확인은 Route 53 상태 확인은 아니지만 비슷한 기능을 수행합니다. ELB 로드 밸런서에 등록하는 EC2 인스턴스에 대해 Route 53 상태 확인을 생성하지 마십시오.
**S3 버킷**
엔드포인트가 S3 버킷인 경우 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정하는 데 필요한 특정 요건은 없습니다.
**Amazon VPC 인터페이스 엔드포인트**
엔드포인트가 Amazon VPC 인터페이스 엔드포인트인 경우 **대상 상태 평가**를 **예**로 설정하는 데 필요한 특별한 요구 사항이 없습니다.
**동일 호스팅 영역 내 다른 레코드**
**엔드포인트**에서 지정하는 AWS 리소스가 레코드 또는 레코드 그룹(예: 가중치 기반 레코드 그룹)이지만 다른 별칭 레코드가 아닌 경우 상태 확인을 엔드포인트의 모든 레코드와 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 생략하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting) 단원을 참조하십시오.
## 레코드 ID
지리 근접성 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 입력합니다.
# 지연 시간 레코드에 특정한 값
지연 시간 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**Topics**
+ [라우팅 정책](#rrsets-values-latency-routing-policy)
+ [레코드 이름](#rrsets-values-latency-name)
+ [레코드 유형](#rrsets-values-latency-type)
+ [TTL(초)](#rrsets-values-latency-ttl)
+ [값/트래픽 라우팅 대상](#rrsets-values-latency-value)
+ [리전](#rrsets-values-latency-region)
+ [상태 확인](#rrsets-values-latency-associate-with-health-check)
+ [레코드 ID](#rrsets-values-latency-set-id)
## 라우팅 정책
**지연 시간**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름** 필드에 값(예: @ 기호)을 입력하지 마세요.
지연 시간 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-shared.md#rrsets-values-common-name) 섹션을 참조하십시오.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
Route 53이 DNS 쿼리에 응답하는 방식에 따라 **유형**에 대한 값을 선택합니다.
지연 시간 레코드 그룹의 모든 레코드에 대해 동일 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **CNAME – 정식 이름**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## 리전
이 레코드에 지정된 리소스가 상주하는 Amazon EC2 리전입니다. Route 53는 지정한 다른 값을 기반으로 하는 Amazon EC2 리전을 권장합니다. 이는 프라이빗 호스팅 영역에도 적용됩니다. 이 값을 변경하지 않는 것이 좋습니다.
다음 사항에 유의하세요.
+ 각 Amazon EC2 리전에 대해 지연 시간 레코드 하나만을 생성할 수 있습니다.
+ 모든 Amazon EC2 리전에 대해 지연 시간 레코드를 생성할 필요가 없습니다. Route 53는 지연 시간 레코드를 생성할 리전 중에서 지연 시간이 가장 좋은 리전을 선택합니다.
+ **레코드 이름** 및 **레코드 유형** 값이 지연 시간 레코드와 같은 비-지연 시간 레코드를 생성할 수 없습니다.
+ **cn-north-1** 리전이 붙은 레코드를 생성할 경우 Route 53이 항상 지연 시간과 상관없이 이 레코드를 사용하여 중국 내부에서 보낸 쿼리에 응답합니다.
지연 시간 레코드 사용에 대한 자세한 내용은 [지연 시간 기반 라우팅](routing-policy-latency.md) 단원을 참조하세요.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가**에서 **예**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 레코드 ID
지연 시간 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 선택합니다.
# 지연 시간 별칭 레코드에 특정한 값
지연 시간 별칭 레코드를 생성할 때 다음과 같은 값을 지정합니다.
자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하십시오.
**Topics**
+ [라우팅 정책](#rrsets-values-latency-alias-routing-policy)
+ [레코드 이름](#rrsets-values-latency-alias-name)
+ [레코드 유형](#rrsets-values-latency-alias-type)
+ [값/트래픽 라우팅 대상](#rrsets-values-latency-alias-alias-target)
+ [리전](#rrsets-values-latency-alias-region)
+ [상태 확인](#rrsets-values-latency-alias-associate-with-health-check)
+ [대상 상태 평가](#rrsets-values-latency-alias-evaluate-target-health)
+ [레코드 ID](#rrsets-values-latency-alias-set-id)
## 라우팅 정책
**지연 시간**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름** 필드에 값(예: @ 기호)을 입력하지 마세요.
지연 시간 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
트래픽을 라우팅할 AWS 리소스를 기반으로 해당 값을 선택합니다.
**API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**Amazon VPC 인터페이스 엔드포인트**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**CloudFront 배포**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **유형(Type)** 값이 **A - IPv4 주소(A - IPv4 address)**이고 하나는 값이 **AAAA - IPv6 주소(AAAA - IPv6 address)**입니다.
**App Runner 서비스**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**ELB 로드 밸런서**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**Amazon S3 버킷**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**OpenSearch Service**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**호스팅 영역의 또 다른 레코드**
별칭을 생성 중인 레코드 유형을 선택합니다. **NS** 및 **SOA**를 제외한 모든 유형이 지원됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **유형** 값이 **CNAME**인 레코드로 트래픽을 라우팅할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
지연 시간 레코드 그룹의 모든 레코드에 대해 동일 값을 선택합니다.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
대상으로 지정할 수 있는 AWS 리소스에 대한 자세한 내용은 [값/라우팅 트래픽에 대한 별칭 레코드의 공통 값을 참조하세요](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
## 리전
이 레코드에 지정된 리소스가 상주하는 Amazon EC2 리전입니다. Route 53는 지정한 다른 값을 기반으로 하는 Amazon EC2 리전을 권장합니다. 이는 프라이빗 호스팅 영역에도 적용됩니다. 이 값을 변경하지 않는 것이 좋습니다.
다음 사항에 유의하세요.
+ 각 Amazon EC2 리전에 대해 지연 시간 레코드 하나만을 생성할 수 있습니다.
+ 모든 Amazon EC2 리전에 대해 지연 시간 레코드를 생성할 필요가 없습니다. Route 53는 지연 시간 레코드를 생성할 리전 중에서 지연 시간이 가장 좋은 리전을 선택합니다.
+ **레코드 이름** 및 **레코드 유형** 값이 지연 시간 레코드와 같은 비-지연 시간 레코드를 생성할 수 없습니다.
+ **cn-north-1** 리전이 붙은 레코드를 생성할 경우 Route 53이 항상 지연 시간과 상관없이 이 레코드를 사용하여 중국 내부에서 보낸 쿼리에 응답합니다.
지연 시간 레코드 사용에 대한 자세한 내용은 [지연 시간 기반 라우팅](routing-policy-latency.md) 단원을 참조하세요.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가**에서 **예**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 대상 상태 평가
**엔드포인트**에서 지정된 리소스의 상태를 확인하여 Route 53가 레코드를 사용해 DNS 쿼리에 응답할지 여부를 결정하게 하려는 경우 **예**를 선택합니다.
다음 사항에 유의하세요.
**API Gateway 사용자 지정 리전 API와 엣지 최적화 API**
엔드포인트가 API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API인 경우 **대상 상태 평가(Evaluate target health)**를 **예(Yes)**로 설정하기 위한 특별한 요구 사항은 없습니다.
**CloudFront 배포**
엔드포인트가 CloudFront 배포인 경우 **대상 상태 평가(Evaluate target health)**를 **예(Yes)**로 설정할 수 없습니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**엔드포인트(Endpoint)**에 Elastic Beanstalk 환경을 지정하고 환경에 ELB 로드 밸런서가 포함된 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. (하나의 환경에 한 개 이상의 Amazon EC2 인스턴스가 포함된 경우 ELB 로드 밸런서가 자동으로 포함됩니다.) **대상 상태 평가**를 **예**로 설정했는데 정상인 Amazon EC2 인스턴스가 없거나 로드 밸런서 자체가 비정상인 경우 Route 53는 양호한 다른 리소스로 쿼리를 라우팅합니다.
환경에 하나의 Amazon EC2 인스턴스가 포함된 경우에는 특별한 요구 사항이 없습니다.
**ELB 로드 밸런서**
상태 확인 동작은 로드 밸런서의 유형에 따라 달랍니다.
+ **Classic Load Balancer**: **엔드포인트(Endpoint)**에 ELB Classic Load Balancer를 지정한 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. **대상 상태 평가**를 **예**로 설정하고 EC2 인스턴스가 정상 상태가 아니거나 로드 밸런서 자체가 비정상인 경우 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ **Application Load Balancer 및 Network Load Balancer** - ELB Application Load Balancer 또는 Network Load Balancer를 지정하고 **대상 상태 평가**를 **예**로 설정한 경우 Route 53는 로드 밸런서와 연결된 대상 그룹의 상태에 따라 쿼리를 로드 밸런서로 라우팅합니다.
+ Application 또는 Network Load Balancer가 정상 상태로 간주되려면 대상을 포함하는 모든 대상 그룹에 정상 상태 대상이 하나 이상 포함되어야 합니다. 대상 그룹에 정상이 아닌 대상만 포함되는 경우 로드 밸런서는 정상이 아닌 상태로 간주되고 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ 등록된 대상이 없는 대상 그룹은 정상이 아닌 상태로 간주됩니다.
로드 밸런서를 생성할 때 Elastic Load Balancing 상태 확인에 대한 설정을 구성하게 되는데, 이러한 확인은 Route 53 상태 확인은 아니지만 비슷한 기능을 수행합니다. ELB 로드 밸런서에 등록하는 EC2 인스턴스에 대해 Route 53 상태 확인을 생성하지 마십시오.
**S3 버킷**
엔드포인트가 S3 버킷인 경우 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정하는 데 필요한 특정 요건은 없습니다.
**Amazon VPC 인터페이스 엔드포인트**
엔드포인트가 Amazon VPC 인터페이스 엔드포인트인 경우 **대상 상태 평가**를 **예**로 설정하는 데 필요한 특별한 요구 사항이 없습니다.
**동일 호스팅 영역 내 다른 레코드**
**엔드포인트**에서 지정하는 AWS 리소스가 레코드 또는 레코드 그룹(예: 가중치 기반 레코드 그룹)이지만 다른 별칭 레코드가 아닌 경우 상태 확인을 엔드포인트의 모든 레코드와 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 생략하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting) 단원을 참조하십시오.
## 레코드 ID
지연 시간 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 선택합니다.
# IP 기반 레코드에 특정한 값
IP 기반 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**참고**
프라이빗 호스팅 영역에서 IP 기반 레코드를 생성할 수는 있지만 지원되지 않습니다.
**Topics**
+ [라우팅 정책](#rrsets-values-ipbased-routing-policy)
+ [레코드 이름](#rrsets-values-ibased-name)
+ [레코드 유형](#rrsets-values-ibased-type)
+ [TTL(초)](#rrsets-values-ibased-ttl)
+ [값/트래픽 라우팅 대상](#rrsets-values-ibased-value)
+ [위치](#rrsets-values-ibased-location)
+ [상태 확인](#rrsets-values-ibased-associate-with-health-check)
+ [레코드 ID](#rrsets-values-ipbased-set-id)
## 라우팅 정책
**IP 기반(IP-based)**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름(Record name)** 필드에 값(예: @ 기호)을 입력하지 마세요.
IP 기반 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
**CNAME 레코드**
**레코드 유형(Record type)** 값이 **CNAME**인 레코드를 생성하는 경우 레코드의 이름은 호스팅 영역의 이름과 같을 수 없습니다.
**특수 문자**
a-z, 0-9, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하세요.
**와일드카드 문자**
이름에 별표(\$1) 문자를 사용할 수 있습니다. DNS는 이름에 표시되는 위치에 따라 \$1 문자를 와일드카드 또는 \$1 문자(ASCII 42)로 처리합니다. 자세한 내용은 [호스팅 영역 및 레코드의 이름에 별표(\$1) 사용](DomainNameFormat.md#domain-name-format-asterisk) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 섹션을 참조하세요.
Route 53가 DNS 쿼리에 응답하는 방식에 따라 **유형(Type)**에 대한 값을 선택합니다.
IP 기반 레코드 그룹의 모든 레코드에 대해 동일한 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 섹션을 참조하세요.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값(IP address or another value depending on the record type)**을 선택합니다. **레코드 유형(Record type)** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **CNAME – 정식 이름**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상](resource-record-sets-values-shared.md#rrsets-values-common-value) [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## 위치
이 레코드에서 지정된 리소스가 CIDR 위치 내 CIDR 블록 값으로 지정된 CIDR 위치의 이름입니다.
IP 기반 레코드 사용에 대한 자세한 내용은 [IP 기반 라우팅](routing-policy-ipbased.md)을 참조하세요.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값(Value)** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, IP 기반 별칭, 대기 시간 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가(Evaluate Target Health)**에서 **예(Yes)**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 섹션을 참조하세요.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름(Domain name)**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 [**Domain name**]의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 레코드 ID
IP 기반 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 입력합니다.
# IP 기반 별칭 레코드에 특정한 값
IP 기반 별칭 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**참고**
프라이빗 호스팅 영역에서 IP 기반 별칭 레코드를 생성할 수는 있지만 지원되지 않습니다.
자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하십시오.
**Topics**
+ [라우팅 정책](#rrsets-values-ipbased-alias-routing-policy)
+ [레코드 이름](#rrsets-values-ipbased-alias-name)
+ [레코드 유형](#rrsets-values-ipbased-alias-type)
+ [값/트래픽 라우팅 대상](#rrsets-values-ipbased-alias-alias-target)
+ [Location](#rrsets-values-ipbased-alias-location)
+ [상태 확인](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [대상 상태 평가](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [레코드 ID](#rrsets-values-ipbased-alias-set-id)
## 라우팅 정책
**IP 기반(IP-based)**을 선택합니다.
**참고**
프라이빗 호스팅 영역에서 IP 기반 별칭 레코드를 생성할 수는 있지만 지원되지 않습니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름** 필드에 값(예: @ 기호)을 입력하지 마세요.
IP 기반 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
**CNAME 레코드**
**레코드 유형(Record type)** 값이 **CNAME**인 레코드를 생성하는 경우 레코드의 이름은 호스팅 영역의 이름과 같을 수 없습니다.
**CloudFront 배포 및 Amazon S3 버킷에 대한 별칭**
지정하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 부분적으로 달라집니다.
+ **CloudFront 배포(CloudFront distribution)** – 배포에 레코드 이름과 일치하는 대체 도메인 이름이 포함되어야 합니다. 예를 들어, 레코드 이름이 **acme.example.com**인 경우 CloudFront 배포에 **acme.example.com**이 대체 도메인 이름 중 하나로 포함되어야 합니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*에서 [대체 도메인 이름(CNAME) 사용](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)을 참조하세요.
+ **Amazon S3 버킷** - 레코드 이름은 Amazon S3 버킷 이름과 일치해야 합니다. 예를 들어, 버킷의 이름이 **acme.example.com**이면 이 레코드의 이름도 **acme.example.com**이어야 합니다.
그리고 웹사이트 호스팅용 버킷을 구성해야 합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [웹 사이트 호스팅에 대한 버킷 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html)을 참조하십시오.
**특수 문자**
a\$1z, 0\$19, -(하이픈) 이외의 문자를 지정하는 방법과 국제 도메인 이름을 지정하는 방법은 다음([DNS 도메인 이름 형식](DomainNameFormat.md))을 참조하십시오.
**와일드카드 문자**
이름에 별표(\$1) 문자를 사용할 수 있습니다. DNS는 이름에 표시되는 위치에 따라 \$1 문자를 와일드카드 또는 \$1 문자(ASCII 42)로 처리합니다. 자세한 내용은 [호스팅 영역 및 레코드의 이름에 별표(\$1) 사용](DomainNameFormat.md#domain-name-format-asterisk) 단원을 참조하십시오.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
트래픽을 라우팅할 AWS 리소스를 기반으로 해당 값을 선택합니다. IP 기반 레코드 그룹의 모든 레코드에 대해 동일한 값을 선택합니다.
**API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**Amazon VPC 인터페이스 엔드포인트**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**CloudFront 배포**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **유형(Type)** 값이 **A - IPv4 주소(A - IPv4 address)**이고 하나는 값이 **AAAA - IPv6 주소(AAAA - IPv6 address)**입니다.
**App Runner 서비스**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**ELB 로드 밸런서**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**Amazon S3 버킷**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**OpenSearch Service**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**호스팅 영역의 또 다른 레코드**
별칭을 생성 중인 레코드 유형을 선택합니다. **NS** 및 **SOA**를 제외한 모든 유형이 지원됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **유형** 값이 **CNAME**인 레코드로 트래픽을 라우팅할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
대상으로 지정할 수 있는 AWS 리소스에 대한 자세한 내용은 [값/라우팅 트래픽에 대한 별칭 레코드의 공통 값을 참조하세요](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
## Location
쿼리를 보낸 위치를 기반으로 하는 DNS 쿼리에 응답하도록 Route 53을 구성할 때는 Route 53이 이 레코드 설정으로 응답하길 원하는 CIDR 위치를 선택합니다.
**중요**
**위치(Location)**에 대한 **기본(Default)** 값을 갖는 하나의 IP 기반 레코드를 생성하는 것이 좋습니다. 그러면 레코드를 생성하지 않은 위치와 Route 53이 위치를 식별하지 못하는 IP 주소도 포함됩니다.
**레코드 이름(Record name)** 및 **레코드 유형(Record type)** 값이 IP 기반 레코드와 같은 IP 기반이 아닌 레코드를 생성할 수 없습니다.
자세한 내용은 [IP 기반 라우팅](routing-policy-ipbased.md) 단원을 참조하십시오.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, IP 기반 라우팅 별칭, 대기 시간 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가(Evaluate Target Health)**에서 **예(Yes)**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
IP 기반 별칭 레코드에서 엔드포인트가 비정상적인 경우 Route 53는 더 크고 연관된 위치 내에서 레코드를 찾습니다. 예를 들어, 미국 내 주, 미국, 북미 및 전체 위치에 대한 레코드가 있다고 가정합니다(**위치**가 **기본값**임). 주 레코드의 엔드포인트가 양호하지 않을 경우 Route 53은 미국, 북미 및 전체 위치 순으로 엔드포인트가 양호한 레코드를 찾을 때까지 레코드를 확인합니다. 모든 지리적 위치에 대한 레코드를 포함하여 모든 적용 가능한 레코드가 비정상적인 경우 Route 53은 가장 작은 지리적 리전에 대한 레코드 값을 사용하여 DNS 쿼리에 응답합니다.
## 대상 상태 평가
**엔드포인트**에서 지정된 리소스의 상태를 확인하여 Route 53가 레코드를 사용해 DNS 쿼리에 응답할지 여부를 결정하게 하려는 경우 **예**를 선택합니다.
다음 사항에 유의하세요.
**API Gateway 사용자 지정 리전 API와 엣지 최적화 API**
엔드포인트가 API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API인 경우 **대상 상태 평가(Evaluate target health)**를 **예(Yes)**로 설정하기 위한 특별한 요구 사항은 없습니다.
**CloudFront 배포**
엔드포인트가 CloudFront 배포인 경우 **대상 상태 평가**를 **예**로 설정할 수 없습니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**엔드포인트(Endpoint)**에 Elastic Beanstalk 환경을 지정하고 환경에 ELB 로드 밸런서가 포함된 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. (하나의 환경에 한 개 이상의 Amazon EC2 인스턴스가 포함된 경우 ELB 로드 밸런서가 자동으로 포함됩니다.) **대상 상태 평가**를 **예**로 설정했는데 정상인 Amazon EC2 인스턴스가 없거나 로드 밸런서 자체가 비정상인 경우 Route 53는 양호한 다른 리소스로 쿼리를 라우팅합니다.
환경에 하나의 Amazon EC2 인스턴스가 포함된 경우에는 특별한 요구 사항이 없습니다.
**ELB 로드 밸런서**
상태 확인 동작은 로드 밸런서의 유형에 따라 달랍니다.
+ **Classic Load Balancer**: **엔드포인트(Endpoint)**에 ELB Classic Load Balancer를 지정한 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. **대상 상태 평가**를 **예**로 설정하고 EC2 인스턴스가 정상 상태가 아니거나 로드 밸런서 자체가 비정상인 경우 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ **Application Load Balancer 및 Network Load Balancer** - ELB Application Load Balancer 또는 Network Load Balancer를 지정하고 **대상 상태 평가**를 **예**로 설정한 경우 Route 53는 로드 밸런서와 연결된 대상 그룹의 상태에 따라 쿼리를 로드 밸런서로 라우팅합니다.
+ Application 또는 Network Load Balancer가 정상 상태로 간주되려면 대상을 포함하는 모든 대상 그룹에 정상 상태 대상이 하나 이상 포함되어야 합니다. 대상 그룹에 정상이 아닌 대상만 포함되는 경우 로드 밸런서는 정상이 아닌 상태로 간주되고 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ 등록된 대상이 없는 대상 그룹은 정상이 아닌 상태로 간주됩니다.
로드 밸런서를 생성할 때 Elastic Load Balancing 상태 확인에 대한 설정을 구성하게 되는데, 이러한 확인은 Route 53 상태 확인은 아니지만 비슷한 기능을 수행합니다. ELB 로드 밸런서에 등록하는 EC2 인스턴스에 대해 Route 53 상태 확인을 생성하지 마십시오.
**S3 버킷**
엔드포인트가 S3 버킷인 경우 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정하는 데 필요한 특정 요건은 없습니다.
**Amazon VPC 인터페이스 엔드포인트**
엔드포인트가 Amazon VPC 인터페이스 엔드포인트인 경우 **대상 상태 평가**를 **예**로 설정하는 데 필요한 특별한 요구 사항이 없습니다.
**동일 호스팅 영역 내 다른 레코드**
**엔드포인트**에서 지정하는 AWS 리소스가 레코드 또는 레코드 그룹(예: 가중치 기반 레코드 그룹)이지만 다른 별칭 레코드가 아닌 경우 상태 확인을 엔드포인트의 모든 레코드와 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 생략하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting) 단원을 참조하십시오.
## 레코드 ID
IP 기반 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 입력합니다.
# 다중값 응답 레코드에 특정한 값
다중값 응답 레코드를 생성할 때, 다음과 같은 값을 지정합니다.
**참고**
다중값 응답 별칭 레코드 생성은 지원되지 않습니다.
**Topics**
+ [라우팅 정책](#rrsets-values-multivalue-routing-policy)
+ [레코드 이름](#rrsets-values-multivalue-name)
+ [레코드 유형](#rrsets-values-multivalue-type)
+ [TTL(초)](#rrsets-values-multivalue-ttl)
+ [값/트래픽 라우팅 대상](#rrsets-values-multivalue-value)
+ [상태 확인](#rrsets-values-multivalue-associate-with-health-check)
+ [레코드 ID](#rrsets-values-multivalue-set-identifier)
## 라우팅 정책
**다중값 응답(Multivalue answer)**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름** 필드에 값(예: @ 기호)을 입력하지 마세요.
다중 값 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-shared.md#rrsets-values-common-name) 섹션을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
**NS** 또는 **CNAME**을 제외한 값을 선택합니다.
다중값 응답 레코드 그룹의 모든 레코드에 대해 동일 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
**참고**
이름 및 유형이 동일한 두 개 이상의 다중값 응답 레코드를 생성하며 콘솔을 사용하고 **TTL**에 대해 다른 값을 지정하는 경우, Route 53은 모든 레코드의 **TTL**을 지정한 마지막 값으로 변경합니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형(Record type)** 값에 해당하는 값을 입력합니다. 2개 이상의 값을 입력하는 경우 각 값을 별도의 행에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53은 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭 또는 가중치 기반 별칭의 그룹 레코드에 대한 **대상 상태 평가(Evaluate Target Health)**에 **예(Yes)**를 선택합니다. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 레코드 ID
다중값 응답 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 선택합니다.
# 가중치 기반 레코드에 특정한 값
가중치 기반 레코드를 생성할 때 다음과 같은 값을 지정합니다.
**Topics**
+ [라우팅 정책](#rrsets-values-weighted-routing-policy)
+ [레코드 이름](#rrsets-values-weighted-name)
+ [레코드 유형](#rrsets-values-weighted-type)
+ [TTL(초)](#rrsets-values-weighted-ttl)
+ [값/트래픽 라우팅 대상](#rrsets-values-weighted-value)
+ [가중치](#rrsets-values-weighted-weight)
+ [상태 확인](#rrsets-values-weighted-associate-with-health-check)
+ [레코드 ID](#rrsets-values-weighted-set-identifier)
## 라우팅 정책
**Weighted(가중치)**를 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **레코드 이름(Record name)** 필드에 값(예: @ 기호)을 입력하지 마세요.
가중 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-shared.md#rrsets-values-common-name) 섹션을 참조하십시오.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
가중 레코드 그룹의 모든 레코드에 대해 동일 값을 선택합니다.
## TTL(초)
DNS 재귀 해석기가 이 레코드에 관한 정보를 캐싱할 시간(초)입니다. 더 긴 값(예: 172,800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS 재귀 해석기의 Route 53에 대한 직접 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간을 줄이고 Route 53 서비스 비용을 줄이는 효과가 있습니다. 자세한 내용은 [Amazon Route 53가 도메인의 트래픽을 라우팅하는 방법](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic) 단원을 참조하십시오.
그러나 TTL에 더 긴 값을 지정하면 재귀 해석기가 Route 53에 최신 정보를 요청하기 전에 기간이 더 긴 캐시 값을 사용하므로 레코드(예: 새 IP 주소) 변경이 적용되는 데 걸리는 시간이 길어집니다. 이미 사용 중인 도메인이나 하위 도메인의 설정을 변경하는 경우 처음에는 더 짧은 값(예: 300초)을 지정하고 새 설정이 올바른지 확인한 후 값을 늘리는 것이 좋습니다.
이 레코드를 상태 확인과 연관시킬 경우에는 클라이언트가 상태 변경에 빠르게 응답하도록 TTL을 60초 이하로 지정하는 것이 좋습니다.
이 가중 레코드 그룹의 모든 레코드에 동일한 **TTL** 값을 지정해야 합니다.
**참고**
이름 및 유형이 동일한 두 개 이상의 가중 레코드를 생성하며 **TTL**에 대해 다른 값을 지정하는 경우 Route 53은 모든 레코드의 **TTL**을 지정한 마지막 값으로 변경합니다.
가중 레코드 그룹에 ELB 로드 밸런서로 트래픽을 라우팅하는 가중 별칭 레코드가 하나 이상 포함된 경우에는 이름과 유형이 동일한 모든 비-별칭 가중 레코드에 대해 TTL을 60초로 지정하는 것이 좋습니다. 60초(로드 밸런서의 TTL) 이외의 값을 지정하면 **Weight(가중치)**에 지정하는 값의 효과가 달라집니다.
## 값/트래픽 라우팅 대상
**IP 주소 또는 레코드 유형에 따라 다른 값**을 선택합니다. **레코드 유형** 값에 해당하는 값을 입력합니다. **CNAME**을 제외한 모든 유형은 둘 이상의 값을 입력할 수 있습니다. 각 값을 별도의 라인에 입력합니다.
트래픽을 라우팅하거나 다음 값을 지정할 수 있습니다.
+ **A – IPv4 주소**
+ **AAAA - IPv6 주소**
+ **CAA - 인증 기관 인증**
+ **CNAME – 정식 이름**
+ **MX - 메일 교환**
+ **NAPTR - 이름 권한 포인터**
+ **PTR - 포인터**
+ **SPF - 발신자 정책 프레임워크**
+ **SRV - 서비스 로케이터**
+ **TXT - 텍스트**
위의 값에 대한 자세한 내용은 [값/트래픽 라우팅 대상에 일반적인 값](resource-record-sets-values-shared.md#rrsets-values-common-value)을 참조하세요.
## 가중치
현재 레코드를 사용하여 Route 53가 응답할 DNS 쿼리의 비율을 결정하는 값입니다. Route 53는 DNS 이름과 유형 조합이 동일한 레코드의 가중치 합을 계산합니다. 그런 다음 Route 53는 리소스 가중치와 합계의 비율을 기반으로 쿼리에 응답합니다.
**레코드 이름(Record name)** 및 **레코드 유형(Record type)** 값이 가중 레코드와 같은 비-가중 레코드를 생성할 수 없습니다.
0\$1255 사이의 정수를 입력합니다. 리소스 라우팅을 해제하려면 **Weight(가중치)**를 0으로 설정합니다. 그룹 내 모든 레코드의 **Weight(가중치)**를 0으로 설정하면 확률이 동일한 모든 리소스로 트래픽이 라우팅됩니다. 따라서 가중 레코드 그룹에 대한 라우팅이 우발적으로 해제되는 일이 없습니다.
**Weight(가중치)**를 0으로 설정할 때의 효과는 상태 확인을 레코드와 연관시킬 때와 다릅니다. 자세한 내용은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 단원을 참조하십시오.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가**에서 **예**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 레코드 ID
가중 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 선택합니다.
# 가중치 기반 별칭 레코드에 특정한 값
가중치 기반 별칭 레코드를 생성할 때 다음과 같은 값을 지정합니다. 자세한 내용은 [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 단원을 참조하십시오.
**Topics**
+ [라우팅 정책](#rrsets-values-weighted-alias-routing-policy)
+ [레코드 이름](#rrsets-values-weighted-alias-name)
+ [레코드 유형](#rrsets-values-weighted-alias-type)
+ [값/트래픽 라우팅 대상](#rrsets-values-weighted-alias-alias-target)
+ [가중치](#rrsets-values-weighted-alias-weight)
+ [상태 확인](#rrsets-values-weighted-alias-associate-with-health-check)
+ [대상 상태 평가](#rrsets-values-weighted-alias-evaluate-target-health)
+ [레코드 ID](#rrsets-values-weighted-alias-set-identifier)
## 라우팅 정책
**가중치 기반**을 선택합니다.
## 레코드 이름
트래픽을 라우팅할 도메인 또는 하위 도메인의 이름을 입력합니다. 기본값은 호스팅 영역 이름입니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 **이름** 필드에 값(예: @ 기호)을 입력하지 마십시오.
가중 레코드 그룹의 모든 레코드에 대해 동일한 이름을 입력합니다.
레코드 이름에 대한 자세한 내용은 [레코드 이름](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) 단원을 참조하세요.
## 레코드 유형
DNS 레코드 유형입니다. 자세한 내용은 [지원되는 DNS 레코드 유형](ResourceRecordTypes.md) 단원을 참조하십시오.
트래픽을 라우팅할 AWS 리소스를 기반으로 해당 값을 선택합니다.
**API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**Amazon VPC 인터페이스 엔드포인트**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**CloudFront 배포**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
배포에 대해 IPv6가 활성화되어 있다면 두 개의 레코드를 생성합니다. 하나는 **유형(Type)** 값이 **A - IPv4 주소(A - IPv4 address)**이고 하나는 값이 **AAAA - IPv6 주소(AAAA - IPv6 address)**입니다.
**App Runner 서비스**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**ELB 로드 밸런서**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**Amazon S3 버킷**
**A - IPv4 주소(A - IPv4 address)**를 선택합니다.
**OpenSearch Service**
**A - IPv4 address(A - IPv4 주소)** 또는 **AAAA - IPv6 address(AAAA - IPv6 주소)** 선택
**호스팅 영역의 또 다른 레코드**
별칭을 생성 중인 레코드 유형을 선택합니다. **NS** 및 **SOA**를 제외한 모든 유형이 지원됩니다.
호스팅 영역(*zone apex*라고도 함)과 이름이 같은 별칭 레코드를 생성한다면, **유형** 값이 **CNAME**인 레코드로 트래픽을 라우팅할 수 없습니다. 이는 별칭 레코드가 트래픽이 라우팅되는 레코드와 동일한 형식이어야 하고, zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
가중 레코드 그룹의 모든 레코드에 대해 동일 값을 선택합니다.
## 값/트래픽 라우팅 대상
목록에서 선택하거나 필드에 입력하는 값은 트래픽을 라우팅하는 AWS 리소스에 따라 달라집니다.
대상으로 지정할 수 있는 AWS 리소스에 대한 자세한 내용은 [값/라우팅 트래픽에 대한 별칭 레코드의 공통 값을 참조하세요](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
트래픽을 특정 AWS 리소스로 라우팅하도록 Route 53를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md).
## 가중치
현재 레코드를 사용하여 Route 53가 응답할 DNS 쿼리의 비율을 결정하는 값입니다. Route 53는 DNS 이름과 유형 조합이 동일한 레코드의 가중치 합을 계산합니다. 그런 다음 Route 53는 리소스 가중치와 합계의 비율을 기반으로 쿼리에 응답합니다.
**레코드 이름(Record name)** 및 **레코드 유형(Record type)** 값이 가중 레코드와 같은 비-가중 레코드를 생성할 수 없습니다.
0\$1255 사이의 정수를 입력합니다. 리소스 라우팅을 해제하려면 **Weight(가중치)**를 0으로 설정합니다. 그룹 내 모든 레코드의 **Weight(가중치)**를 0으로 설정하면 확률이 동일한 모든 리소스로 트래픽이 라우팅됩니다. 따라서 가중 레코드 그룹에 대한 라우팅이 우발적으로 해제되는 일이 없습니다.
**Weight(가중치)**를 0으로 설정할 때의 효과는 상태 확인을 레코드와 연관시킬 때와 다릅니다. 자세한 내용은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 단원을 참조하십시오.
## 상태 확인
Route 53가 지정된 엔드포인트 상태를 점검하고 엔드포인트가 정상할 때만 이 레코드를 사용하여 DNS 쿼리에 응답하길 원할 경우 상태 확인을 선택합니다.
Route 53는 레코드에 지정된 엔드포인트, 예를 들어 **값** 필드에서 IP 주소로 지정된 엔드포인트의 상태는 점검하지 않습니다. 레코드의 상태 확인을 선택하면 Route 53가 상태 확인에서 지정한 엔드포인트의 상태를 점검합니다. Route 53가 엔드포인트가 정상인지 여부를 결정하는 방법은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요.
상태 확인과 레코드를 연관시키는 것은 Route 53가 둘 이상의 레코드 사이에서 DNS 쿼리에 응답할 레코드를 선택할 때 그리고 Route 53가 상태 확인 상태를 선택의 기준으로 삼을 때만 유용합니다. 다음 구성에서만 상태 확인을 사용합니다.
+ 이름, 유형 및 라우팅 정책(예: 장애 조치 또는 가중치 레코드)이 동일한 레코드 그룹의 모든 레코드 상태를 확인하고 모든 레코드에 대한 상태 확인 ID를 지정하는 경우. 레코드의 상태 확인에서 양호하지 않은 엔드포인트가 지정될 경우 Route 53는 해당 레코드 값을 사용하는 쿼리에 대한 응답을 중단합니다.
+ 별칭 레코드 또는 장애 조치 별칭, 지리적 위치 별칭, 대기 시간 별칭, IP 기반 별칭 또는 가중치 기반 별칭 그룹에 속한 레코드에 대해 **대상 상태 평가**에서 **예**를 선택하는 경우. 별칭 레코드가 동일한 호스팅 영역의 별칭이 아닌 레코드를 참조하는 경우 참조된 레코드의 상태 확인도 지정해야 합니다. 상태 확인과 별칭 레코드를 연관시키고 **대상 상태 평가**에서 **예**를 선택하는 경우 둘 다 true로 평가되어야 합니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 단원을 참조하십시오.
상태 확인에서 도메인 이름만으로 엔드포인트를 지정할 경우에는 각 엔드포인트마다 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. **도메인 이름**의 값은 레코드의 이름(example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다.
**중요**
이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다.
## 대상 상태 평가
**엔드포인트**에서 지정된 리소스의 상태를 확인하여 Route 53가 레코드를 사용해 DNS 쿼리에 응답할지 여부를 결정하게 하려는 경우 **예**를 선택합니다.
다음 사항에 유의하세요.
**API Gateway 사용자 지정 리전 API와 엣지 최적화 API**
엔드포인트가 API Gateway 사용자 지정 리전 API 또는 엣지 최적화 API인 경우 **대상 상태 평가**를 **예**로 설정하기 위한 특별한 요구 사항은 없습니다.
**CloudFront 배포**
엔드포인트가 CloudFront 배포인 경우 **대상 상태 평가**를 **예**로 설정할 수 없습니다.
**리전별 하위 도메인이 있는 Elastic Beanstalk 환경**
**엔드포인트(Endpoint)**에 Elastic Beanstalk 환경을 지정하고 환경에 ELB 로드 밸런서가 포함된 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. (하나의 환경에 한 개 이상의 Amazon EC2 인스턴스가 포함된 경우 ELB 로드 밸런서가 자동으로 포함됩니다.) **대상 상태 평가**를 **예**로 설정했는데 정상인 Amazon EC2 인스턴스가 없거나 로드 밸런서 자체가 비정상인 경우 Route 53는 양호한 다른 리소스로 쿼리를 라우팅합니다.
환경에 하나의 Amazon EC2 인스턴스가 포함된 경우에는 특별한 요구 사항이 없습니다.
**ELB 로드 밸런서**
상태 확인 동작은 로드 밸런서의 유형에 따라 달랍니다.
+ **Classic Load Balancer**: **엔드포인트(Endpoint)**에 ELB Classic Load Balancer를 지정한 경우, Elastic Load Balancing은 로드 밸런서에 등록된 정상 Amazon EC2 인스턴스로만 쿼리를 라우팅합니다. **대상 상태 평가(Evaluate target health)**를 **예(Yes)**로 설정하고 EC2 인스턴스가 정상 상태가 아니거나 로드 밸런서 자체가 비정상인 경우 Route 53은 쿼리를 다른 리소스로 라우팅합니다.
+ **Application Load Balancer 및 Network Load Balancer** - ELB Application Load Balancer 또는 Network Load Balancer를 지정하고 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정한 경우 Route 53은 로드 밸런서와 연결된 대상 그룹의 상태에 따라 쿼리를 로드 밸런서로 라우팅합니다.
+ Application 또는 Network Load Balancer가 정상 상태로 간주되려면 대상을 포함하는 모든 대상 그룹에 정상 상태 대상이 하나 이상 포함되어야 합니다. 대상 그룹에 정상이 아닌 대상만 포함되는 경우 로드 밸런서는 정상이 아닌 상태로 간주되고 Route 53는 쿼리를 다른 리소스로 라우팅합니다.
+ 등록된 대상이 없는 대상 그룹은 정상이 아닌 상태로 간주됩니다.
로드 밸런서를 생성할 때 Elastic Load Balancing 상태 확인에 대한 설정을 구성하게 되는데, 이러한 확인은 Route 53 상태 확인은 아니지만 비슷한 기능을 수행합니다. ELB 로드 밸런서에 등록하는 EC2 인스턴스에 대해 Route 53 상태 확인을 생성하지 마십시오.
**S3 버킷**
엔드포인트가 S3 버킷인 경우 **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 설정하는 데 필요한 특정 요건은 없습니다.
**Amazon VPC 인터페이스 엔드포인트**
엔드포인트가 Amazon VPC 인터페이스 엔드포인트인 경우 **대상 상태 평가**를 **예**로 설정하는 데 필요한 특별한 요구 사항이 없습니다.
**동일 호스팅 영역 내 다른 레코드**
**엔드포인트**에서 지정하는 AWS 리소스가 레코드 또는 레코드 그룹(예: 가중치 기반 레코드 그룹)이지만 다른 별칭 레코드가 아닌 경우 상태 확인을 엔드포인트의 모든 레코드와 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 생략하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting) 단원을 참조하십시오.
## 레코드 ID
가중 레코드 그룹에 있는 이 레코드를 고유하게 식별하는 값을 선택합니다.
# 영역 파일을 가져와 레코드 생성
다른 DNS 서비스 공급자로부터 마이그레이션하는 경우, 그리고 현재 DNS 서비스 공급자가 현재 DNS 설정을 영역 파일로 내보내는 것을 허용하는 경우에는, 영역 파일을 가져옴으로써 Amazon Route 53 호스팅 영역의 모든 레코드를 빠르게 생성할 수 있습니다.
**참고**
영역 파일은 BIND라는 표준 형식을 사용해 텍스트 형식으로 레코드를 표시합니다. 영역 파일의 형식에 대한 자세한 내용은 [Zone file](https://en.wikipedia.org/wiki/Zone_file) Wikipedia 항목을 참조하십시오. 자세한 내용은 섹션 3.6.1 [RFC 1034, 도메인 이름 - 개념 및 설비](https://datatracker.ietf.org/doc/html/rfc1034) 및 섹션 5 [RFC 1035, 도메인 이름 - 실행 및 사양](https://datatracker.ietf.org/doc/html/rfc1035)에서 확인할 수 있습니다.
영역 파일을 가져와 레코드를 생성하고자 할 경우에는 다음 사항에 유의하십시오.
+ 영역 파일은 반드시 RFC 규약을 준수하는 형식이어야 합니다.
+ 영역 파일에 있는 레코드의 도메인 이름은 호스팅 영역의 이름과 일치해야 합니다.
+ Route 53는 `$ORIGIN` 및 `$TTL` 키워드를 지원합니다. 영역 파일에 `$GENERATE` 또는 `$INCLUDE` 키워드가 포함되어 있으면, 가져오기 작업이 실패하고 Route 53는 오류를 반환합니다.
+ 영역 파일을 가져올 때 Route 53는 해당 영역 파일에 있는 SOA 레코드를 무시합니다. Route 53는 호스팅 영역과 이름이 같은 NS 레코드도 모두 무시합니다.
+ 레코드는 최대 1,000개까지 가져올 수 있습니다.
+ 호스팅 영역에 영역 파일에 나타나는 레코드가 이미 포함되어 있으면 가져오기 프로세스가 실패하고 레코드가 생성되지 않습니다.
+ 백슬래시 문자가 포함된 TXT 레코드의 경우 영역 파일 가져오기 프로세스는 특정 백슬래시 시퀀스를 제어 문자로 해석합니다. TXT 레코드 값에 리터럴 백슬래시 문자를 포함하려면:
+ 영역 파일에서 이중 백슬래시(`\\\\`)를 사용하여 최종 TXT 레코드에서 하나의 리터럴 백슬래시를 나타낼 수 있습니다.
+ 예를 들어 TXT 레코드에 `\\jYTDWqH...`(리터럴 백슬래시 및 j 포함)가 포함되어야 하는 경우 영역 파일에서 `\\\\jYTDWqH...`를 지정합니다.
이는 리터럴 백슬래시 문자가 포함된 ACME 챌린지 레코드 및 기타 TXT 레코드에 특히 중요합니다.
+ 긴 TXT 레코드(예: DKIM 레코드)의 경우 영역 파일 가져오기 프로세스는 콘텐츠를 여러 문자열로 분할하는 기능을 지원합니다. 여러 문자열을 포함한 TXT 레코드를 생성하려면:
+ 영역 파일에서 레코드 이름과 유형이 동일한 별도의 줄을 사용합니다.
**Example**
```
example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC"
example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f"
example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x"
```
가져오기 프로세스는 이를 여러 문자열을 포함한 하나의 TXT 레코드로 자동으로 결합합니다. 각 개별 문자열은 최대 65,535자를 포함할 수 있습니다. 긴 문자열들을 하나의 따옴표로 묶인 값으로 연결하면 안 됩니다.
+ 영역 파일의 내용을 검토하여 레코드 이름 뒤에 점이 적절하게 포함되는지 아니면 제외되는지 확인하는 것이 좋습니다.
+ 영역 파일에 있는 레코드의 이름에 뒤에 오는 점이 포함되어 있으면(`example.com.`), 가져오기 프로세스는 그 이름을 전체 주소 도메인 이름으로 해석해 그 이름으로 Route 53 레코드를 생성합니다.
+ 영역 파일에 있는 레코드의 이름에 뒤에 오는 점이 포함되어 있지 않으면(`www`), 가져오기 프로세스는 그 이름을 영역 파일의 도메인 이름(`example.com`)과 결합하여 결합된 이름(`www.example.com`)으로 Route 53 레코드를 생성합니다.
내보내기 프로세스가 레코드의 전체 주소 도메인 이름 뒤에 점을 추가하지 않는 경우 Route 53 가져오기 프로세스는 레코드의 이름에 도메인 이름을 추가합니다. 예를 들어, 호스팅 영역 `example.com`으로 레코드를 가져오고, 영역 파일에 있는 MX 레코드의 이름이 뒤에 오는 점이 없는`mail.example.com`이라고 가정해봅시다. Route 53 가져오기 프로세스는 `mail.example.com.example.com`이라는 이름의 MX 레코드를 생성합니다.
**중요**
CNAME, MX, PTR, 및 SRV 레코드의 경우에 이러한 작동은 RDATA 값에 포함된 도메인 이름에도 적용됩니다. 예를 들어 `example.com`에 대한 영역 파일이 있다고 가정해봅시다. 영역 파일에 있는 CNAME 레코드(뒤에 오는 점이 없는 `support`)가 `www.example.com`(역시 뒤에 오는 점이 없음)이라는 RDATA 값을 갖고 있다면, 가져오기 프로세스는 트래픽을 `www.example.com.example.com`로 라우팅하는 `support.example.com`이라는 이름의 Route 53 레코드를 생성합니다. 영역 파일을 가져오기 전에 RDATA 값을 검토하고 필요할 경우 업데이트합니다. 백슬래시 문자가 포함된 TXT 레코드의 경우 영역 파일에서 이중 백슬래시(`\\\\`)를 사용하여 리터럴 백슬래시를 나타낼 수 있습니다.
Route 53는 영역 파일로 레코드 내보내기를 지원하지 않습니다.
**참고**
호스팅 영역과 이름이 동일한 레코드를 생성할 경우 이름 필드에 값(예: @ 기호)을 입력하지 마십시오.
**영역 파일을 가져와 레코드를 생성하려면**
1. 현재 도메인을 서비스하는 DNS 서비스 공급자로부터 영역 파일을 가져옵니다. 프로세스와 용어는 서비스 공급자에 따라 다릅니다. 영역 파일 또는 BIND 파일에 레코드를 보내거나 저장하는 작업에 관한 공급자의 인터페이스 및 문서를 참조하십시오.
프로세스가 명확하지 않은 경우에는 현재 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. **Create Hosted Zone(호스팅 영역 생성)**을 선택합니다.
1. 도메인 이름을 입력합니다. 옵션 사항으로 코멘트를 입력할 수 있습니다.
1. **생성(Create)**을 선택합니다.
1. **영역 파일 가져오기(Import Zone File)**를 선택합니다.
1. **영역 파일 가져오기(Import Zone File)** 창에서 영역 파일의 콘텐츠를 **영역 파일(Zone File)** 텍스트 상자로 붙여넣기 합니다.
1. **가져오기**를 선택합니다.
**참고**
영역 파일의 레코드 수에 따라 레코드가 생성될 때까지 몇 분 동안 기다려야 할 수도 있습니다.
1. 도메인을 위해 다른 DNS 서비스를 사용한다면(다른 등록 기관을 통해 도메인을 등록한 경우 이는 흔한 일입니다), DNS 서비스를 Route 53으로 마이그레이션합니다. 그 단계가 완료되면 등록 기관은 도메인에 대한 DNS 쿼리에 반응하여 Route 53를 DNS 서비스로 인식하기 시작하고 쿼리는 Route 53 DNS 서비스로 전송되기 시작할 것입니다 (일반적으로 이전 DNS 서비스에 대한 정보가 DNS 해석기에 캐시되는 하루 또는 이틀이 지나야 DNS 쿼리가 Route 53으로 라우팅되기 시작합니다). 자세한 내용은 [Amazon Route 53를 기존 도메인에 대한 DNS 서비스로 설정Route 53을 기존 도메인에 대한 DNS 서비스로 설정](MigratingDNS.md) 단원을 참조하십시오.
# 레코드 편집
다음 절차는 Amazon Route 53 콘솔을 사용하여 레코드를 편집하는 방법을 설명합니다. Route 53 API를 사용하여 레코드를 편집하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)를 참조하세요.
**참고**
레코드 변경 내용이 Route 53 DNS 서버로 전파되려면 시간이 걸립니다. 현재 변경 사항의 전파 여부를 확인하는 유일한 방법은 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 작업을 사용하는 것입니다. 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름의 서버로 전파됩니다.
**Route 53 콘솔을 사용하여 레코드를 편집하려면**
1. 별칭 레코드를 편집하지 않는 경우에는 2단계로 건너뜁니다.
트래픽을 Elastic Load Balancing Classic Load Balancer, Application Load Balancer 또는 Network Load Balancers로 라우팅하는 별칭 레코드를 편집하는 경우 그리고 서로 다른 계정을 사용하여 Route 53 호스팅 영역 및 로드 밸런서를 생성한 경우에는 [Elastic Load Balancing 로드 밸런서의 DNS 이름 가져오기](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) 절차를 수행하여 로드 밸런서에 대한 DNS 이름을 가져옵니다.
다른 AWS 리소스의 별칭 레코드를 편집하는 경우 2단계로 건너뜁니다.
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. 편집할 레코드의 행을 선택한 다음 **레코드 편집** 창에서 변경 사항을 입력합니다.
1. 관련 값들을 입력합니다. 자세한 내용은 [Amazon Route 53 레코드를 생성 또는 편집할 때 지정하는 값](resource-record-sets-values.md) 단원을 참조하십시오.
1. **변경 사항 저장**을 선택합니다.
1. 레코드를 여러 개 편집하는 경우에는 5\$17단계를 반복합니다.
# 레코드 삭제
다음 절차에서는 Route 53 콘솔을 사용하여 레코드를 삭제하는 방법을 설명합니다. Route 53 API를 사용하여 레코드를 삭제하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)를 참조하세요.
**참고**
레코드 변경 내용이 Route 53 DNS 서버로 전파되려면 시간이 걸립니다. 현재 변경 사항의 전파 여부를 확인하는 유일한 방법은 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 작업을 사용하는 것입니다. 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름의 서버로 전파됩니다.
**레코드를 삭제하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 호스팅 영역 페이지에서 삭제할 레코드가 포함된 호스팅 영역의 행을 선택합니다.
1. 레코드 목록에서 삭제하려는 레코드를 선택합니다.
연속된 여러 레코드를 선택하려면 첫 번째 행을 선택한 다음 **Shift** 키를 누른 상태에서 마지막 행을 선택합니다. 연속되지 않는 여러 레코드를 선택하려면 첫 번째 행을 선택한 다음 **Ctrl** 키를 누른 상태에서 다른 행을 추가로 클릭합니다.
**유형(Type)** 값이 **NS** 또는 **SOA**인 레코드는 삭제할 수 없습니다.
1. **삭제**를 선택합니다.
1. 대화 상자를 닫으려면 **삭제(Delete)**를 선택합니다.
# 레코드 나열
다음 절차는 Amazon Route 53 콘솔을 사용하여 호스팅 영역의 레코드를 나열하는 방법을 설명합니다. Route 53 API를 사용하여 레코드를 나열하는 방법에 대한 자세한 내용은 *Amazon Route 53 API 참조*의 [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)를 참조하세요.
**레코드를 나열하려면**
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. 검색 모드를 변경하려면 페이지의 오른쪽 상단에서 **레코드** 테이블을 선택합니다. 다음 중 하나를 선택합니다.
+ **자동**
이 모드에서 서비스는 레코드 수에 기반한 필터를 사용합니다. 레코드가 2000개 미만인 경우에는 전체 모드를, 레코드가 2000개 이상인 경우에는 빠른 모드를 사용합니다.
+ **전체**
이 모드에서는 모든 검색 필터를 사용할 수 있지만 검색 성능이 느려질 수 있습니다.
+ **빠른**
이 모드에서는 일부 고급 기능을 사용할 수 없지만 검색 성능은 더 빨라집니다.
선택한 레코드만을 표시하려면, 다음과 같이 레코드 목록 위에 해당되는 검색 기준을 입력합니다. 자동 모드에서 검색 동작은 호스팅 영역에 최대 2,000개 또는 2,000개 이상의 레코드를 포함하는지 여부에 따라 다릅니다.
**레코드가 최대 2,000개인 경우 및 전체 모드**
+ 특정 값을 지닌 레코드를 표시하려면, 검색 창에 값을 입력하고 **Enter** 키를 누릅니다. 예를 들어, **192.0**으로 시작하는 IP 주소를 지닌 레코드를 표시하려면, **검색** 필드에 그 값을 입력하고 **입력** 키를 누릅니다.
+ DNS 레코드 유형이 같은 레코드만을 표시하려면, 드롭다운 목록에서 **레코드 유형(Record type)**을 선택한 다음 레코드 유형을 입력합니다.
+ 별칭 레코드만을 표시하려면 드롭다운 목록에서 **별칭(Alias)**을 선택하고 **Yes**를 입력합니다.
+ 가중치 기반 레코드만을 표시하려면 드롭다운 목록에서 **라우팅 정책(Routing policy)**을 선택한 다음 **WEIGHTED**를 입력합니다.
**레코드가 2,000개 이상인 경우 및 빠른 모드**
+ 레코드 값이 아닌 레코드 이름으로만 검색할 수 있습니다. 또한 레코드 유형 또는 별칭이나 가중치 레코드를 기반으로 필터링할 수 없습니다.
이렇게 하려면 **필터** 텍스트 상자에 커서를 놓고 **속성**을 선택한 다음 **레코드 이름**을 선택합니다.
+ 레이블이 3개(점으로 세 부분이 구분됨)인 레코드의 경우 검색 필드에서 값을 입력하고 **Enter**를 누르면 Route 53 콘솔이 레코드 이름에서 오른쪽 세 번째 레이블에서 와일드카드 검색을 자동으로 수행합니다. 예를 들어, 호스팅 영역 example.com에 record1.example.com부터 record100.example.com까지 100개의 레코드가 있습니다. (Record1이 오른쪽에서 세 번째 레이블입니다.) 다음 값으로 검색하면 다음과 같이 진행됩니다.
+ **record1** - Route 53 콘솔이 **record1\$1.example.com**을 검색하고 **record1.example.com**, **record10.example.com**부터 **record19.example.com** 그리고 **record100.example.com**을 반환합니다.
+ **record1.example.com** - 이전 예제처럼 콘솔은 **record1\$1.example.com**을 검색하고 동일한 레코드를 반환합니다.
+ **1** - 콘솔이 **1\$1.example.com**을 검색하고 아무런 레코드도 반환하지 않습니다.
+ **example** - 콘솔이 **example\$1.example.com**을 검색하고 아무런 레코드도 반환하지 않습니다.
+ **example.com** - 이 예제에서 콘솔은 와일드카드 검색을 수행하지 않습니다. 호스팅 영역의 모든 레코드를 반환합니다.
+ **자동 검색 모드** - 이 검색 모드를 사용할 때는 먼저 레코드 이름과 같은 속성을 입력해야 검색할 수 있습니다.
**참고**
오른쪽의 세 번째 레이블에 하나 이상의 하이픈(예: `third-label.example.com`)이 포함되어 있는 경우 세 번째 레이블에서 하이픈(이 예에서는 `third`) 바로 앞 부분을 검색하면 Route 53가 레코드를 반환하지 않습니다. 대신 하이픈을 포함하거나(`third-` 검색) 하이픈 바로 앞의 문자를 생략하십시오(`third` 검색).
+ 레이블이 4개 이상인 레코드의 경우 동일한 레코드 이름을 지정해야 합니다. 와일드카드 검색은 지원되지 않습니다. 예를 들어, 호스팅 영역에 이름이 label4.record1.example.com인 레코드가 포함된 경우 검색 필드에서 **label4.record1.example.com**을 지정한 경우에만 해당 레코드를 찾을 수 있습니다.
# Amazon Route 53에서 DNSSEC 서명 구성
DNSSEC(도메인 이름 시스템 보안 확장) 서명을 사용하면 DNS 해석기가 DNS 응답이 Amazon Route 53에서 왔으며 변조되지 않았는지 검증할 수 있습니다. DNSSEC 서명을 사용하면 호스팅 영역에 대한 모든 응답이 퍼블릭 키 암호화를 사용하여 서명됩니다. DNSSEC에 대한 개요는 [AWS re:Invent 2021 - Amazon Route 53: A year in review](https://www.youtube.com/watch?v=77V23phAaAE)의 DNSSEC 섹션을 참조하세요.
이 장에서는 Route 53에 대해 DNSSEC 서명을 사용하는 방법, KSK(키 서명 키)에서 작업하는 방법 및 문제 해결 방법에 대해 설명합니다. 에서 DNSSEC 서명을 사용하거나 API를 사용하여 AWS Management Console 프로그래밍 방식으로 작업할 수 있습니다. CLI나 SDK를 사용하여 Route 53에서 작업하는 방법에 대한 자세한 내용은 [Amazon Route 53 설정](setting-up-route-53.md) 섹션을 참조하세요.
DNSSEC 서명을 사용하기 전에 다음 사항에 유의하세요.
+ 영역 중단을 방지하고 도메인을 사용할 수 없게 되는 문제를 방지하려면 DNSSEC 오류를 신속하게 대응하고 해결해야 합니다. `DNSSECInternalFailure` 또는 `DNSSECKeySigningKeysNeedingAction` 오류를 감지할 때마다 알림이 전송되도록 CloudWatch 경보를 설정하는 것이 좋습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 호스팅 영역 모니터링](monitoring-hosted-zones-with-cloudwatch.md) 섹션을 참조하세요.
+ DNSSEC에는 KSK(키 서명 키) 와 ZSK(영역 서명 키)라는 두 가지 키가 있습니다. Route 53 DNSSEC 서명에서 각 KSK는 사용자가 소유한 AWS KMS 의 [비대칭 고객 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept)를 기반으로 합니다. 필요한 경우 교체를 포함한 KSK 관리에 대한 책임은 사용자에게 있습니다. ZSK 관리는 Route 53에서 수행합니다.
+ 호스팅 영역에 대해 DNSSEC 서명을 사용하면 Route 53가 TTL을 1주일로 제한합니다. 호스팅 영역의 레코드에 대해 TTL을 1주일보다 긴 기간으로 설정하면 오류가 발생하지 않습니다. 그러나 Route 53는 해당 레코드에 대해 1주일의 TTL을 적용합니다. TTL이 1주일 미만인 레코드와 DNSSEC 서명이 사용되지 않은 다른 호스팅 영역의 레코드는 영향을 받지 않습니다.
+ DNSSEC 서명을 사용하면 다중 공급 업체 구성이 지원되지 않습니다. 화이트 레이블 이름 서버(베니티 이름 서버 또는 프라이빗 이름 서버라고도 함)를 구성한 경우, 이 이름 서버가 단일 DNS 공급자로 제공되는지 확인합니다.
+ 일부 DNS 공급자는 권한 있는 DNS에 DS(Delegation Signer) 레코드를 지원하지 않습니다. DS 쿼리 응답에 AA 플래그를 설정하지 않고 DS 쿼리를 지원하지 않는 DNS 공급자가 상위 영역을 호스팅한다면, 하위 영역에서 DNSSEC를 활성화하는 경우에 하위 영역을 확인할 수 없게 됩니다. DNS 공급자가 DS 레코드를 지원하는지 확인하세요.
+ 영역 소유자 외에 다른 사용자가 해당 영역에 레코드를 추가하거나 제거할 수 있도록 IAM 권한을 설정하는 것이 도움이 될 수 있습니다. 예를 들어 영역 소유자는 KSK를 추가하고 서명을 활성화할 수 있으며 키 교체를 담당할 수도 있습니다. 그러나 다른 사람에게 호스팅 영역에 대한 다른 레코드로 작업할 책임이 있을 수 있습니다. IAM 정책 예제는 [도메인 레코드 소유자에 대한 사용 권한 예제](access-control-managing-permissions.md#example-permissions-record-owner) 단원을 참조하세요.
+ TLD에 DNSSEC 지원이 있는지 확인하려면 [Amazon Route 53에 등록할 수 있는 도메인](registrar-tld-list.md) 섹션을 참조하세요.
**Topics**
+ [DNSSEC 서명 활성화 및 신뢰 체인 설정](dns-configuring-dnssec-enable-signing.md)
+ [DNSSEC 서명 비활성화](dns-configuring-dnssec-disable.md)
+ [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md)
+ [KSK(키 서명 키)로 작업](dns-configuring-dnssec-ksk.md)
+ [Route 53에서의 KMS 키 및 ZSK 관리](dns-configuring-dnssec-zsk-management.md)
+ [Route 53에서 존재하지 않는다는 DNSSEC 증명](dns-configuring-dnssec-proof-of-nonexistence.md)
+ [DNSSEC 서명 문제 해결](dns-configuring-dnssec-troubleshoot.md)
# DNSSEC 서명 활성화 및 신뢰 체인 설정
****
증분 단계는 호스팅 영역 소유자와 상위 영역 유지 관리자에게 적용됩니다. 두 사람은 동일한 사람이 될 수 있지만, 그렇지 않은 경우 영역 소유자는 상위 영역 유지 관리자에게 알리고 협력해야 합니다.
이 문서의 단계를 따라 영역에 서명하고 신뢰 체인에 포함시키는 것이 좋습니다. 다음 단계는 DNSSEC로의 온보딩 시 위험을 최소화해 줍니다.
**참고**
시작하기 전에 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md)에서 사전 조건을 읽어야 합니다.
DNSSEC 서명을 활성화하려면 다음 섹션에 설명된 세 가지 단계를 수행해야 합니다.
**Topics**
+ [1단계: DNSSEC 서명 활성화 준비](#dns-configuring-dnssec-enable-signing-step-1)
+ [2단계: DNSSEC 서명 활성화 및 KSK 생성](#dns-configuring-dnssec-enable)
+ [3단계: 신뢰 체인 설정](#dns-configuring-dnssec-chain-of-trust)
## 1단계: DNSSEC 서명 활성화 준비
준비 단계는 영역 가용성을 모니터링하고 서명 활성화와 DS(Delegation Signer) 레코드 삽입 사이의 대기 시간을 줄여 DNSSEC로의 온보딩 시 위험을 최소화하는 데 도움이 됩니다.
**DNSSEC 서명 활성화를 준비하려면**
1. 영역 가용성을 모니터링합니다.
영역의 도메인 이름 가용성을 모니터링할 수 있습니다. 이것은 DNSSEC 서명을 활성화한 후 한 단계 뒤로 롤백해야 하는 모든 문제를 해결하는 데 도움이 될 수 있습니다. 쿼리 로깅을 사용하여 대부분의 트래픽에서 도메인 이름을 모니터링할 수 있습니다. 쿼리 로깅 역할 설정에 대한 자세한 내용은 [Amazon Route 53 모니터링](monitoring-overview.md) 단원을 참조하세요.
모니터링은 셸 스크립트 또는 서드 파티 서비스를 통해 수행할 수 있습니다. 그러나 이것이 롤백이 필요한지 결정하기 위한 유일한 신호는 아닙니다. 도메인을 사용할 수 없는 문제로 고객으로부터 피드백을 받을 수도 있습니다.
1. 영역의 최대 TTL을 낮춥니다.
영역의 최대 TTL은 영역에서 가장 긴 TTL 레코드입니다. 다음의 영역 예에서 영역의 최대 TTL은 1일(86,400초)입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
영역의 최대 TTL을 낮추면 서명 활성화와 DS(Delegation Signer) 레코드 삽입 사이의 대기 시간을 줄이는 데 도움이 됩니다. 영역의 최대 TTL을 1시간(3,600초)으로 낮추는 것이 좋습니다. 이렇게 하면 해석기가 서명된 레코드를 캐싱하는 데 문제가 있는 경우 단 1시간 후에 롤백할 수 있습니다.
**롤백:** TTL 변경 사항을 실행 취소합니다.
1. SOA TTL 및 SOA 최소 필드를 낮춥니다.
SOA 최소 필드는 SOA 레코드 데이터의 마지막 필드입니다. 다음 SOA 레코드 예제에서 최소 필드는 5분(300초)의 값을 가집니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
SOA TTL 및 SOA 최소 필드는 해석기가 부정 답변을 얼마나 오래 기억할지 결정합니다. 서명을 활성화하면 Route 53 이름 서버가 부정 답변을 위한 NSEC 레코드를 반환하기 시작합니다. NSEC에는 해석기가 부정 답변을 합성하는 데 사용할 수 있는 정보가 포함되어 있습니다. NSEC 정보로 인해 해석기가 이름에 대한 부정 답변을 가정하기 때문에 롤백해야 하는 경우, 해석기가 가정을 중지하게 하려면 SOA TTL 및 SOA 최소 필드의 최댓값을 기다리기만 하면 됩니다.
**롤백:** SOA 변경 사항을 실행 취소합니다.
1. TTL 및 SOA 최소 필드 변경의 효과가 적용되었는지 확인합니다.
[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)를 사용하여 지금까지의 변경 사항이 모든 Route 53 DNS 서버에 전파되었는지 확인합니다.
## 2단계: DNSSEC 서명 활성화 및 KSK 생성
Route 53 콘솔에서 AWS CLI 또는를 사용하여 DNSSEC 서명을 활성화하고 KSK(키 서명 키)를 생성할 수 있습니다.
+ [CLI](#dnssec_CLI)
+ [콘솔](#dnssec_console)
KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 단원을 참조하십시오.
------
#### [ CLI ]
이미 보유하고 있는 키를 사용하거나, 고유한 요청을 만들기 위해 `hostedzone_id`, `cmk_arn`, `ksk_name` 및 `unique_string`에 대한 자체 값을 사용하는 다음과 같은 AWS CLI 명령을 실행하여 키를 생성할 수 있습니다.
```
aws --region us-east-1 route53 create-key-signing-key \
--hosted-zone-id $hostedzone_id \
--key-management-service-arn $cmk_arn --name $ksk_name \
--status ACTIVE \
--caller-reference $unique_string
```
사용자 지정 고객 관리형 키에 대한 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 단원을 참조하세요. [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)도 참조하세요.
DNSSEC 서명을 활성화하려면에 대한 자체 값을 사용하여 `hostedzone_id`다음과 같은 AWS CLI 명령을 실행합니다.
```
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
자세한 내용은 [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html) 및 [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)을 참조하세요.
------
#### [ Console ]
**DNSSEC 서명 활성화 및 KSK 생성**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택한 후 DNSSEC 서명을 활성화할 호스팅 영역을 선택합니다.
1. **DNSSEC 서명** 탭에서 **DNSSEC 서명 활성화**를 선택합니다.
**참고**
이 섹션의 옵션이 **DNSSEC 서명 비활성화**인 경우 DNSSEC 서명 활성화의 첫 단계를 이미 완료한 것입니다. DNSSEC의 호스팅 영역에 대한 신뢰 체인을 설정하거나 이미 존재하는지 확인하세요. 그러면 완료됩니다. 자세한 내용은 [3단계: 신뢰 체인 설정](#dns-configuring-dnssec-chain-of-trust) 단원을 참조하십시오.
1. **KSK(키 서명 키) 생성(Key-signing key (KSK) creation)** 섹션에서 **새 KSK 생성(Create new KSK)**을 선택하고 **KSK 이름 제공(Provide KSK name)**에 Route 53가 생성할 KSK의 이름을 입력합니다. 이름에는 숫자, 문자, 밑줄(\$1)이 포함될 수 있습니다. 이름은 고유해야 합니다.
1. **고객 관리형 CMK**에서 Route 53에서 KSK를 생성할 때 사용할 고객 관리형 키를 선택합니다. DNSSEC 서명에 적용되는 기존 고객 관리형 키를 사용하거나 새 고객 관리형 키를 생성할 수 있습니다.
고객 관리형 KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 섹션을 참조하세요.
1. 기존 고객 관리형 키의 별칭을 입력합니다. 새 고객 관리형 키를 사용하려면 고객 관리형 키의 별칭을 입력합니다. 그러면 Route 53에서 키를 생성합니다.
**참고**
Route 53에서 고객 관리형 키를 만들도록 선택한 경우 고객 관리형 키마다 별도의 요금이 부과됩니다. 자세한 내용은 [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing/)을 참조하세요.
1. **DNSSEC 서명 활성화**를 선택합니다.
------
**영역 서명을 활성화한 후 다음 단계를 완료합니다**(콘솔 또는 CLI를 사용했는지 여부에 상관 없음).
1. 영역 서명의 효과가 적용되었는지 확인합니다.
를 사용한 경우 `EnableHostedZoneDNSSEC()` 호출 출력의 작업 ID를 사용하여 [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) 또는 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)를 실행하여 모든 Route 53 DNS 서버가 응답에 서명하는지 확인할 AWS CLI수 있습니다(상태 = `INSYNC`).
1. 적어도 이전 영역의 최대 TTL 동안 기다립니다.
해석기가 서명되지 않은 모든 레코드를 캐시에서 비울 때까지 기다립니다. 이를 위해서는 적어도 이전 영역의 최대 TTL 동안 기다려야 합니다. 위의 `example.com` 영역에서는 대기 시간이 1일입니다.
1. 고객 문제에 대한 보고서를 모니터링합니다.
영역 서명을 활성화한 후에는 고객에게 네트워크 디바이스 및 해석기와 관련된 문제가 표시되기 시작할 수 있습니다. 권장되는 모니터링 기간은 2주입니다.
다음은 표시될 수 있는 문제의 예제니다.
+ 일부 네트워크 디바이스는 DNS 응답 크기를 512바이트 미만으로 제한할 수 있으며 이는 일부 서명된 응답에 사용하기에 너무 작은 크기입니다. 이러한 네트워크 디바이스는 더 큰 DNS 응답 크기를 허용하도록 재구성되어야 합니다.
+ 일부 네트워크 디바이스는 DNS 응답에 대한 세부적인 검사를 수행하여 DNSSEC에 사용된 것과 같이 디바이스가 이해하지 못하는 특정 레코드를 제거합니다. 이러한 디바이스는 재구성해야 합니다.
+ 일부 고객의 해석기는 네트워크가 지원하는 것보다 더 큰 UDP 응답을 받아들일 수 있다고 주장합니다. 네트워크 역량을 테스트하고 해석기를 적절하게 구성할 수 있습니다. 자세한 내용은 [DNS 응답 크기 테스트 서버](https://www.dns-oarc.net/oarc/services/replysizetest/)를 참조하세요.
**롤백:** [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)를 직접 호출한 다음 [1단계: DNSSEC 서명 활성화 준비](#dns-configuring-dnssec-enable-signing-step-1)의 단계를 롤백합니다.
## 3단계: 신뢰 체인 설정
Route 53에서 호스팅 영역에 대해 DNSSEC 서명을 활성화한 후 호스팅 영역에 대한 신뢰 체인을 설정하여 DNSSEC 서명 설정을 완료합니다. 이렇게 하려면 Route 53에서 제공하는 정보를 사용하여 호스팅 영역에 대한 *상위* 호스팅 영역에서 DS(Delegation Signer) 레코드를 생성하면 됩니다. 도메인이 등록된 위치에 따라 Route 53의 상위 호스팅 영역 또는 다른 도메인 등록 기관에 레코드를 추가합니다.
**DNSSEC 서명에 대한 신뢰 체인을 설정하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택한 후 DNSSEC 신뢰 체인을 설정할 호스팅 영역을 선택합니다. *먼저 DNSSEC 서명을 활성화해야 합니다.*
1. **DNSSEC 서명**의 **DNSSEC 서명** 탭에서 **DS 레코드를 만들기 위한 정보 보기**를 선택합니다.
**참고**
이 섹션에 **DS 레코드를 만들기 위한 정보 보기**가 표시되지 않는 경우 신뢰 체인을 설정하기 전에 DNSSEC 서명을 활성화해야 합니다. **DNSSEC 서명 활성화(Enable DNSSEC signing)**를 선택하고 [2단계: DNSSEC 서명 활성화 및 KSK 생성](#dns-configuring-dnssec-enable)에 설명된 단계를 완료한 다음 이 단계로 돌아와 신뢰 체인을 설정합니다.
1. **신뢰 체인 설정**에서 도메인이 등록된 위치에 따라 **Route 53 등록 기관** 또는 **다른 도메인 등록 기관** 중 하나를 선택합니다.
1. 3단계에서 제공된 값을 사용하여 Route 53의 상위 호스팅 영역에 대한 DS 레코드를 생성합니다. 도메인이 Route 53에서 호스팅되지 않는 경우, 제공된 값을 사용하여 도메인 등록 기관 웹 사이트에 DS 레코드를 생성합니다.
상위 영역에 대한 신뢰 체인을 설정합니다.
+ 도메인이 Route 53를 통해 관리되는 경우 다음 단계를 따릅니다.
올바른 서명 알고리즘(ECDSAP256SHA256 및 유형 13) 및 다이제스트 알고리즘(SHA-256 및 유형 2)을 구성했는지 확인합니다.
Route 53가 등록 기관인 경우 Route 53 콘솔에서 다음을 수행합니다.
1. **키 유형**, **서명 알고리즘** 및 **퍼블릭 키** 값을 참고합니다. 탐색 창에서 **등록된 도메인**을 선택합니다.
1. 도메인을 선택한 후 **DNSSEC 키** 탭에서 **키 추가**를 선택합니다.
1. **DNSSEC 키 관리** 대화 상자의 드롭다운 메뉴에서 **Route 53 등록 기관**의 적절한 **키 유형** 및 **알고리즘**을 선택합니다.
1. Route 53 등록 기관의 **퍼블릭 키**를 복사합니다. **DNSSEC 키 관리(Manage DNSSEC keys)** 대화 상자에서 값을 **퍼블릭 키(Public key)** 입력란에 붙여넣습니다.
1. **추가**를 선택합니다.
Route 53는 공개 키의 상위 영역에 DS 레코드를 추가합니다. 예를 들어 도메인이 `example.com`인 경우 DS 레코드는 .com DNS 영역에 추가됩니다.
+ 도메인이 다른 레지스트리에서 관리되는 경우 **다른 도메인 등록 기관** 섹션의 지침을 따릅니다.
다음 단계가 원활하게 진행될 수 있도록 상위 영역에 낮은 DS TTL을 도입합니다. 변경 사항을 롤백해야 하는 경우 빠르게 복구할 수 있도록 DS TTL을 5분(300초)으로 설정하는 것이 좋습니다.
+ 하위 영역에 대한 신뢰 체인을 설정합니다.
상위 영역을 다른 레지스트리에서 관리하는 경우 등록 기관에 연락하여 해당 영역에 대한 DS 레코드를 도입하도록 합니다. 일반적으로 DS 레코드의 TTL은 조정할 수 없습니다.
+ 상위 영역이 Route 53에서 호스팅되는 경우 상위 영역 소유자에게 연락하여 해당 영역에 대한 DS 레코드를 도입하도록 합니다.
상위 영역 소유자에게 `$ds_record_value`를 제공합니다. 이 값은 콘솔의 **DS 레코드를 생성하기 위한 정보 보기(View Information to create DS record)**를 클릭하고 **DS 레코드(DS record)** 필드를 복사하거나 [GetDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API를 호출하고 'DSRecord' 필드의 값을 검색하여 얻을 수 있습니다.
```
aws --region us-east-1 route53 get-dnssec
--hosted-zone-id $hostedzone_id
```
상위 영역 소유자는 Route 53 콘솔 또는 CLI를 통해 레코드를 삽입할 수 있습니다.
+ 를 사용하여 DS 레코드 AWS CLI를 삽입하기 위해 상위 영역 소유자는 다음 예제와 유사한 JSON 파일을 생성하고 이름을 지정합니다. 상위 영역 소유자는 파일의 이름을 `inserting_ds.json`과 같이 지정할 수 있습니다.
```
{
"HostedZoneId": "$parent_zone_id",
"ChangeBatch": {
"Comment": "Inserting DS for zone $zone_name",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "$zone_name",
"Type": "DS",
"TTL": 300,
"ResourceRecords": [
{
"Value": "$ds_record_value"
}
]
}
}
]
}
}
```
그런 다음, 다음 명령을 실행합니다.
```
aws --region us-east-1 route53 change-resource-record-sets
--cli-input-json file://inserting_ds.json
```
+ 콘솔을 사용하여 DS 레코드를 삽입하려면
[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.
탐색 창의 **호스팅 영역(Hosted zones)**에서 호스팅 영역의 이름을 선택한 다음 **레코드 생성(Create record)** 버튼을 선택합니다. **라우팅 정책(Routing policy)**에 단순 라우팅을 선택했는지 확인합니다.
**레코드 이름** 필드에 `$zone_name`과 같은 이름을 입력하고, **레코드 유형** 드룹 다운에서 DS를 선택하고, **값** 필드에 `$ds_record_value`의 값을 입력한 다음 **레코드 생성**을 선택합니다.
**롤백:** 상위 영역에서 DS를 제거하고 DS TTL 동안 기다린 다음 신뢰를 설정하는 단계를 롤백합니다. 상위 영역이 Route 53에서 호스팅되는 경우, 상위 영역 소유자는 JSON 파일의 `Action`을 `UPSERT`에서 `DELETE`로 변경하고 위의 예제 CLI를 다시 실행할 수 있습니다.
1. 도메인 레코드의 TTL을 기반으로 업데이트가 전파될 때까지 기다립니다.
상위 영역이 Route 53 DNS 서비스에 있는 경우, 상위 영역 소유자는 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API를 통해 전파 완료를 확인할 수 있습니다.
그렇지 않으면 DS 레코드의 상위 영역을 주기적으로 조사한 다음 DS 레코드 삽입이 완전히 전파될 확률을 높일 수 있도록 10분 더 기다릴 수 있습니다. 일부 등록 기관은 일정(예: 하루에 한 번)에 따라 DS 삽입을 수행합니다.
상위 영역에 DS(Delegation Signer) 레코드를 도입하면 DS를 선택한 검증된 해석기가 해당 영역에서 응답의 유효성을 검사하기 시작합니다.
신뢰 설정 단계가 원활하게 진행되도록 하려면 다음을 완료합니다.
1. 최대 NS TTL을 찾습니다.
영역과 관련된 NS 레코드에는 2가지 세트가 있습니다.
+ 위임 NS 레코드 - 상위 영역이 보유한 영역에 대한 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다(영역이 example.com인 경우 상위 영역은 com).
`dig -t NS com`
NS 레코드 중 하나를 선택한 후 다음을 실행합니다.
`dig @one of the NS records of your parent zone -t NS example.com`
예:
`dig @b.gtld-servers.net. -t NS example.com`
+ 영역 내 NS 레코드 - 이것은 영역에 있는 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다.
`dig @one of the NS records of your zone -t NS example.com`
예:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
두 영역 모두에 대한 최대 TTL을 확인합니다.
1. 최대 NS TTL 동안 기다립니다.
DS 삽입 전에 해석기는 서명된 응답을 받지만 서명을 검증하지는 않습니다. DS 레코드가 삽입되면 영역의 NS 레코드가 만료되기 전까지는 해석기가 해당 레코드를 볼 수 없습니다. 해석기가 NS 레코드를 다시 가져오면 DS 레코드도 반환됩니다.
고객이 동기화되지 않은 클럭이 있는 호스트에서 해석기를 실행하는 경우 시계가 올바른 시간에서 1시간 이내인지 확인하십시오.
이 단계를 완료하면 모든 DNSSEC 인식 해석기가 영역을 검증합니다.
1. 이름 확인을 관찰합니다.
해석기의 영역 검증에 문제가 없음을 확인해야 합니다. 고객이 문제를 보고하는 데 필요한 시간도 고려해야 합니다.
최대 2주 동안 모니터링하는 것이 좋습니다.
1. (선택 사항) DS 및 NS TTL을 늘립니다.
설정에 만족하면 TTL 및 SOA 변경 사항을 저장할 수 있습니다. Route 53는 서명된 영역에 대해 TTL을 1주로 제한합니다. 자세한 내용은 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md) 섹션을 참조하세요.
DS TTL을 변경할 수 있는 경우, 1시간으로 설정하는 것이 좋습니다.
# DNSSEC 서명 비활성화
Route 53에서 DNSSEC 서명을 비활성화하는 단계는 호스팅 영역이 속한 신뢰 체인에 따라 다릅니다.
예를 들어 호스팅 영역에 신뢰 체인의 일부로 DS(Delegation Signer) 레코드가 있는 상위 영역이 있을 수 있습니다. 호스팅 영역 자체가 신뢰 체인의 또 다른 부분인 DNSSEC 서명을 활성화한 하위 영역의 상위 영역일 수도 있습니다. DNSSEC 서명을 사용하지 않는 단계를 수행하기 전에 호스팅 영역에 대한 전체 신뢰 체인을 조사하고 확인합니다.
서명을 사용하지 않는 경우 DNSSEC 서명을 활성화하는 호스팅 영역에 대한 신뢰 체인은 주의해서 실행 취소해야 합니다. 신뢰 체인에서 호스팅 영역을 제거하려면 이 호스팅 영역을 포함하는 신뢰 체인의 위치에 있는 모든 DS 레코드를 제거합니다. 즉, 순서대로 다음을 수행해야 합니다.
1. 이 호스팅 영역에 신뢰 체인의 일부인 하위 영역으로 있는 DS 레코드를 모두 제거합니다.
1. 상위 영역에서 DS 레코드를 제거합니다. 신뢰 영역이 있는 경우(상위 영역에 DS 레코드가 없고 이 영역의 하위 영역에 대한 DS 레코드가 없는 경우) 이 단계를 건너뜁니다.
1. DS 레코드를 제거할 수 없는 경우, 신뢰 체인에서 영역을 제거하려면 상위 영역에서 NS 레코드를 제거합니다. 자세한 내용은 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 단원을 참조하십시오.
다음 증분 단계를 통해 개별 단계의 효과를 모니터링하여 영역의 DNS 가용성 문제를 방지할 수 있습니다.
**DNSSEC 서명을 비활성화하려면**
1. 영역 가용성을 모니터링합니다.
영역의 도메인 이름 가용성을 모니터링할 수 있습니다. 이것은 DNSSEC 서명을 활성화한 후 한 단계 뒤로 롤백해야 하는 모든 문제를 해결하는 데 도움이 될 수 있습니다. 쿼리 로깅을 사용하여 대부분의 트래픽에서 도메인 이름을 모니터링할 수 있습니다. 쿼리 로깅 역할 설정에 대한 자세한 내용은 [Amazon Route 53 모니터링](monitoring-overview.md) 단원을 참조하세요.
모니터링은 셸 스크립트 또는 유료 서비스를 통해 수행할 수 있습니다. 그러나 이것이 롤백이 필요한지 결정하기 위한 유일한 신호는 아닙니다. 도메인을 사용할 수 없는 문제로 고객으로부터 피드백을 받을 수도 있습니다.
1. 현재 DS TTL을 찾습니다.
DS TTL은 다음 Unix 명령을 실행하여 찾을 수 있습니다.
`dig -t DS example.com example.com`
1. 최대 NS TTL을 찾습니다.
영역과 관련된 NS 레코드에는 2가지 세트가 있습니다.
+ 위임 NS 레코드 - 상위 영역이 보유한 영역에 대한 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다.
먼저 상위 영역의 NS를 찾습니다(영역이 example.com인 경우 상위 영역은 com).
`dig -t NS com`
NS 레코드 중 하나를 선택한 후 다음을 실행합니다.
`dig @one of the NS records of your parent zone -t NS example.com`
예:
`dig @b.gtld-servers.net. -t NS example.com`
+ 영역 내 NS 레코드 - 이것은 영역에 있는 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다.
`dig @one of the NS records of your zone -t NS example.com`
예:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
두 영역 모두에 대한 최대 TTL을 확인합니다.
1. 상위 영역에서 DS 레코드를 제거합니다.
상위 영역 소유자에게 연락하여 DS 레코드를 제거하도록 합니다.
**롤백:** DS 레코드를 다시 삽입하고 DS 삽입이 효과가 있는지 확인한 다음 모든 해석기가 다시 검증을 시작할 때까지 최대 NS(DS가 아님) TTL 동안 기다립니다.
1. DS 제거의 효과가 적용되었는지 확인합니다.
상위 영역이 Route 53 DNS 서비스에 있는 경우, 상위 영역 소유자는 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API를 통해 전파 완료를 확인할 수 있습니다.
그렇지 않으면 DS 레코드의 상위 영역을 주기적으로 조사한 다음 DS 레코드 제거가 완전히 전파될 확률을 높일 수 있도록 10분 더 기다릴 수 있습니다. 일부 등록 기관은 일정(예: 하루에 한 번)에 따라 DS 제거를 수행합니다.
1. DS TTL 동안 기다립니다.
모든 해석기의 캐시에서 DS 레코드가 만료될 때까지 기다립니다.
1. DNSSEC 서명을 비활성화하고 KSK(키 서명 키)를 비활성화합니다.
+ [CLI](#CLI_dnssec_disable)
+ [콘솔](#console_dnssec_disable)
------
#### [ CLI ]
[DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) 및 [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) API를 호출합니다.
예:
```
aws --region us-east-1 route53 disable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
aws --region us-east-1 route53 deactivate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
```
------
#### [ Console ]
**DNSSEC 서명을 비활성화하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택한 후 DNSSEC 서명을 비활성화할 호스팅 영역을 선택합니다.
1. **DNSSEC 서명(DNSSEC signing)** 탭에서 **DNSSEC 서명 비활성화(Disable DNSSEC signing)**를 선택합니다.
1. **DNSSEC 서명 비활성화(Disable DNSSEC signing)** 페이지에서 DNSSEC 서명을 비활성화하려는 영역의 시나리오에 따라 다음 옵션 중 하나를 선택합니다.
+ **상위 영역만(Parent zone only)** - 이 영역에는 DS 레코드가 있는 상위 영역이 있습니다. 이 시나리오에서는 상위 영역의 DS 레코드를 제거해야 합니다.
+ **하위 영역만(Child zones only)** - 이 영역에는 하나 이상의 하위 영역이 있는 신뢰 체인에 대한 DS 레코드가 있습니다. 이 시나리오에서는 해당 영역의 DS 레코드를 제거해야 합니다.
+ **상위 및 하위 영역(Parent and child zones)** - 이 영역에는 하나 이상의 하위 영역이 있는 신뢰 체인에 대한 DS 레코드 *및* DS 레코드가 있는 상위 영역 모두 다 있습니다. 이 시나리오의 경우 다음을 순서대로 수행합니다.
1. 해당 영역의 DS 레코드를 제거합니다.
1. 상위 영역의 DS 레코드를 제거합니다.
신뢰 영역이 있는 경우 이 단계를 건너뛰어도 됩니다.
1. 4단계에서 제거한 각 DS 레코드에 대해 TTL이 무엇인지 확인하고, 가장 긴 TTL 기간이 만료되었는지 확인합니다.
1. 단계를 순서대로 수행했음을 확인하는 확인란을 선택합니다.
1. 표시된 대로 필드에 *disable*을 입력한 다음 **비활성화(Disable)**를 선택합니다.
**KSK(키 서명 키)를 비활성화하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택한 후 KSK(키 서명 키)를 비활성화할 호스팅 영역을 선택합니다.
1. **KSK(키 서명 키)(Key-signing keys (KSKs))** 섹션에서 비활성화할 KSK를 선택한 다음 **작업(Actions)**에서 **KSK 편집(Edit KSK)**을 선택하고 **KSK 상태(KSK status)**를 **비활성(Inactive)**로 설정한 다음 **KSK 저장(Save KSK)**을 선택합니다.
------
**롤백:** [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) 및 [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) API를 호출합니다.
예:
```
aws --region us-east-1 route53 activate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
1. 영역 서명 비활성화의 효과가 적용되었는지 확인합니다.
[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) 실행을 위한 `EnableHostedZoneDNSSEC()` 호출의 ID를 사용하여 모든 Route 53 DNS 서버가 응답 서명을 중지했는지 확인합니다(상태 =`INSYNC`).
1. 이름 확인을 관찰합니다.
해석기가 영역의 유효성을 검사하는 데 문제가 없음을 확인해야 합니다. 고객이 문제를 보고하는 데 필요한 시간도 고려하도록 1\$12주의 시간을 허용합니다.
1. (선택 사항) 정리.
서명을 다시 활성화하지 않을 것이라면 [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)를 통해 KSK를 정리하고 해당 고객 관리형 키를 삭제하여 비용을 절감할 수 있습니다.
# DNSSEC용 고객 관리형 키 작업
Amazon Route 53에서 DNSSEC 서명을 활성화하면 Route 53에서 키 서명 키(KSK)를 생성합니다. KSK를 생성하려면 Route 53가 DNSSEC를 지원하는의 고객 관리 AWS Key Management Service 형 키를 사용해야 합니다. 이 섹션에서는 DNSSEC로 작업할 때 도움이 되는 고객 관리형 키의 세부 사항 및 요구 사항에 대해 설명합니다.
DNSSEC에 대한 고객 관리형 키로 작업하는 경우 다음 사항에 유의하세요.
+ DNSSEC 서명에서 사용하는 고객 관리형 키는 미국 동부 (버지니아 북부) 리전에 있어야 합니다.
+ 고객 관리형 키는 [ECC\$1NIST\$1P256 키 사양](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc)의 [비대칭 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks)여야 합니다. 이러한 고객 관리형 키는 서명 및 확인에만 사용됩니다. 비대칭 고객 관리형 키를 생성하는 데 도움이 필요하면 AWS Key Management Service 개발자 안내서의 [비대칭 고객 관리형 키 생성을](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) 참조하세요. 기존 고객 관리형 키의 암호화 구성을 찾는 데 도움이 필요하면 AWS Key Management Service 개발자 안내서의 [고객 관리형 키의 암호화 구성 보기를](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) 참조하세요.
+ Route 53에서 DNSSEC와 함께 사용할 고객 관리형 키를 직접 생성하는 경우 Route 53에 필요한 권한을 부여하는 특정 키 정책 설명을 포함해야 합니다. Route 53는 고객 관리형 키에 액세스할 수 있어야 KSK를 생성할 수 있습니다. 자세한 내용은 [DNSSEC 서명에 필요한 Route 53 고객 관리형 키 권한](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC) 단원을 참조하십시오.
+ Route 53는에서 추가 AWS KMS 권한 없이 DNSSEC 서명과 함께 사용할 수 AWS KMS 있는 고객 관리형 키를 생성할 수 있습니다. 그러나 키를 만든 후 편집하려면 특정 권한이 있어야 합니다. 필요한 특정 사용 권한은 `kms:UpdateKeyDescription`, `kms:UpdateAlias` 및 `kms:PutKeyPolicy`와 같습니다.
+ 고객 관리형 키를 직접 생성하든 Route 53에서 생성하든 관계없이 보유한 각 고객 관리형 키에 대해 별도의 요금이 부과됩니다. 자세한 내용은 [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing/)을 참조하십시오.
# KSK(키 서명 키)로 작업
DNSSEC 서명을 활성화하면 Route 53에서 KSK(키 서명 키)를 생성합니다. Route 53에는 호스팅 영역당 최대 2개의 KSK가 있을 수 있습니다. DNSSEC 서명을 활성화한 후 KSK를 추가, 제거 또는 편집할 수 있습니다.
KSK로 작업할 때는 다음 사항에 유의하세요.
+ KSK를 삭제하려면 먼저 KSK를 편집하여 KSK 상태를 **비활성**으로 설정해야 합니다.
+ 호스팅 영역에 대해 DNSSEC 서명을 사용하면 Route 53가 TTL을 1주일로 제한합니다. 호스팅 영역의 레코드에 대해 TTL을 1주일 이상으로 설정하면 오류가 발생하지 않지만 Route 53에서는 TTL을 1주일로 실행합니다.
+ 영역 중단을 방지하고 도메인을 사용할 수 없게 되는 문제를 방지하려면 DNSSEC 오류에 신속하게 대응하고 해결해야 합니다. `DNSSECInternalFailure` 또는 `DNSSECKeySigningKeysNeedingAction` 오류를 감지할 때마다 알림이 전송되도록 CloudWatch 경보를 설정하는 것이 좋습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 호스팅 영역 모니터링](monitoring-hosted-zones-with-cloudwatch.md) 섹션을 참조하세요.
+ 이 섹션에서 설명하는 KSK 작업을 통해 영역의 KSK를 대체할 수 있습니다. 자세한 내용 및 단계별 예제에 대해서는 블로그 게시물 [Amazon Route 53로 DNSSEC 서명 및 유효성 검사 구성](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/)에서 *DNSSEC 키 교체*를 참조하세요.
에서 KSKs를 사용하려면 다음 섹션의 지침을 AWS Management Console따르세요.
## KSK(키 서명 키) 추가
DNSSEC 서명을 활성화하면 Route 53에서 KSK(키 서명 키)를 생성합니다. KSK를 별도로 추가할 수도 있습니다. Route 53에는 호스팅 영역당 최대 2개의 KSK가 있을 수 있습니다.
KSK를 생성하는 경우 KSK와 함께 사용할 고객 관리형 키를 생성하려면 Route 53를 제공하거나 요청해야 합니다. 고객 관리형 KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 단원을 참조하십시오.
AWS Management Console에 KSK를 추가하려면 다음 단계를 따르세요.
**KSK를 추가하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택한 후 호스팅 영역을 선택합니다.
1. **KSK(키 서명 키)(Key-signing keys (KSKs))**의 **DNSSEC 서명(DNSSEC signing)** 탭에서 **고급 보기로 전환(Switch to advanced view)**을 선택한 다음 **작업(Actions)**에서 **KSK 추가(Add KSK)**를 선택합니다.
1. **KSK**에 Route 53에서 생성할 KSK의 이름을 입력합니다. 이름에는 숫자, 문자, 밑줄(\$1)이 포함될 수 있습니다. 이름은 고유해야 합니다.
1. DNSSEC 서명에 적용되는 고객 관리형 키의 별칭을 입력하거나 Route 53에서 생성할 새 고객 관리형 키의 별칭을 입력합니다.
**참고**
Route 53에서 고객 관리형 키를 만들도록 선택한 경우 고객 관리형 키마다 별도의 요금이 부과됩니다. 자세한 내용은 [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing/)을 참조하십시오.
1. **KSK 생성**을 선택합니다.
## KSK(키 서명 키) 편집
KSK의 상태를 **활성** 또는 **비활성**으로 편집할 수 있습니다. KSK가 활성화되면 Route 53에서는 DNSSEC 서명에 해당 KSK를 사용합니다. KSK를 삭제하려면 먼저 KSK를 편집하여 KSK 상태를 **비활성**으로 설정해야 합니다.
AWS Management Console에 KSK를 추가하려면 다음 단계를 따르세요.
**태그를 편집하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택한 후 호스팅 영역을 선택합니다.
1. **DNSSEC 서명(DNSSEC signing)** 탭의 **KSK(키 서명 키)(Key-signing keys (KSKs))**에서 **고급 보기로 전환(Switch to advanced view)**을 선택한 다음, **작업(Actions)**에서 **KSK 편집(Edit KSK)**을 선택합니다.
1. KSK를 원하는 대로 업데이트한 다음 **저장**을 선택합니다.
## KSK(키 서명 키) 삭제
KSK를 삭제하려면 먼저 KSK를 편집하여 KSK 상태를 **비활성**으로 설정해야 합니다.
KSK를 삭제할 수 있는 이유 중 하나는 일상적인 키 교체의 일부이기 때문입니다. 암호화 키를 주기적으로 교체하는 것이 가장 좋습니다. 조직에 키를 교체하는 빈도에 대한 표준 지침이 있을 수 있습니다.
AWS Management Console에서 KSK를 삭제하려면 다음 단계를 따르세요.
**KSK를 삭제하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다.
1. 탐색 창에서 **호스팅 영역**을 선택한 후 호스팅 영역을 선택합니다.
1. **KSK(키 서명 키)(Key-signing keys (KSKs))**의 **DNSSEC 서명(DNSSEC signing)** 탭에서 **고급 보기로 전환(Switch to advanced view)**을 선택한 다음, **작업(Actions)**에서 **KSK 삭제(Delete KSK)**을 선택합니다.
1. 지침에 따라 KSK 삭제를 확인합니다.
# Route 53에서의 KMS 키 및 ZSK 관리
이 섹션에서는 DNSSEC 서명 활성화 영역에 대해 Route 53가 사용하는 현재 방법을 설명합니다.
**참고**
Route 53는 변경될 수 있는 다음 규칙을 사용합니다. 향후 변경으로 인해 영역 또는 Route 53의 보안 태세가 줄어들지 않습니다.
**Route 53가 KSK와 AWS KMS 연결된를 사용하는 방법**
DNSSEC에서 KSK는 DNSSKEY 리소스 레코드 세트에 대한 리소스 레코드 서명(RRSIG)을 생성하는 데 사용됩니다. 모든 `ACTIVE` KSK는 RRSIG 세대에서 사용됩니다. Route 53는 연결된 KMS 키에서 `Sign` AWS KMS API를 호출하여 RRSIG를 생성합니다. 자세한 내용은 *AWS KMS API 가이드*의 [서명](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html)을 참조하세요. 이러한 RRSIG는 영역의 리소스 레코드 세트 제한에 포함되지 않습니다.
RRSIG가 만료되었습니다. RRSIG가 만료되는 것을 방지하기 위해 RRSIG를 1일에서 7일마다 다시 생성하여 정기적으로 새로 고칩니다.
또한 다음 API를 호출할 때마다 RRSIG가 새로 고쳐집니다.
+ [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)
+ [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)
+ [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)
+ [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)
+ [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
+ [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
Route 53가 새로 고침을 수행할 때마다 관련 KMS 키에 액세스할 수 없게 되는 경우를 대비하여 향후 며칠을 처리하기 위해 15개의 RRSIG를 생성합니다. KMS 키 비용 추정을 위해 하루에 한 번 정기적으로 새로 고침한다고 가정할 수 있습니다. KMS 키 정책을 실수로 변경하면 KMS 키에 액세스하는 것이 어려울 수 있습니다. 액세스할 수 없는 KMS 키는 연결된 KSK의 상태를 `ACTION_NEEDED`로 설정합니다. 마지막 RRSIG가 만료된 후 검증 확인자가 조회에 실패하기 때문에 `DNSSECKeySigningKeysNeedingAction` 오류가 감지될 때에는 CloudWatch 경보를 설정하여 이 상태를 모니터링하는 것이 좋습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 호스팅 영역 모니터링](monitoring-hosted-zones-with-cloudwatch.md) 단원을 참조하십시오.
**Route 53가 영역의 ZSK를 관리하는 방법**
DNSSEC 서명이 활성화된 각 새 호스팅 영역에는 하나의 `ACTIVE` 영역 서명 키(ZSK)가 있습니다. ZSK는 각 호스팅 영역에 대해 별도로 생성되며 Route 53가 소유합니다. 현재 키 알고리즘은 ECDSAP256SHA256입니다.
서명 시작 후 7\$130일 이내에 영역에서 정기적으로 ZSK 회전을 수행하기 시작합니다. 현재 Route 53는 사전 게시 키 롤오버 방법을 사용합니다. 자세한 내용은 [사전 게시 영역 서명 키 롤오버](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1) 단원을 참조하세요. 이 방법은 영역에 다른 ZSK를 도입합니다. 회전은 7\$130일마다 반복됩니다.
Route 53는 영역의 ZSK의 변경 사항을 설명하기 위해 DNSKEY 리소스 레코드 세트에 대한 RRSIG를 다시 생성할 수 없기 때문에 영역의 KSK가 `ACTION_NEEDED` 상태인 경우 Route 53는 ZSK 회전을 일시 중단합니다. 조건이 지워지면 ZSK 회전이 자동으로 재개됩니다.
# Route 53에서 존재하지 않는다는 DNSSEC 증명
**참고**
Route 53는 변경될 수 있는 다음 규칙을 사용합니다. 향후 변경으로 인해 영역 또는 Route 53의 보안 태세가 줄어들지 않습니다.
DNSSEC에는 세 가지 종류의 존재하지 않는다는 증거가 있습니다.
+ 쿼리 이름과 일치하는 레코드가 존재하지 않는다는 증거.
+ 쿼리 유형과 일치하는 유형이 존재하지 않는다는 증거.
+ 응답으로 레코드를 생성하는 데 사용되는 와일드카드 레코드가 존재하지 않는다는 증거.
Route 53는 BL 메서드를 사용하여 쿼리 이름과 일치하는 레코드가 존재하지 않는다는 증거를 구현합니다. 자세한 내용은 [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00) 단원을 참조하세요. 이는 증거를 컴팩트하게 표현하고 영역 둘러보기를 방지하는 방법입니다.
쿼리 유형이 아닌 쿼리 이름과 일치하는 레코드가 있는 경우(예: web.example.com/AAAA에 대해 쿼리하지만 web.example.com/A만 있는 경우) 지원되는 모든 리소스 레코드 유형을 포함하는 최소 NSEC(다음 보안) 레코드를 반환합니다.
Route 53가 와일드카드 레코드의 응답을 합성할 경우, 응답은 다음 보안 레코드인 와일드카드에 대한 NSEC 레코드와 함께 제공되지 않습니다. 이러한 NSEC 레코드는 응답의 리소스 레코드 서명(RRSIG)이 다른 응답을 스푸핑하는 데 재사용되는 것을 방지하기 위해 일반적으로 오프라인 서명을 수행하는 일부 구현에서 사용됩니다. Route 53는 non-DNSKEY 레코드의 온라인 서명을 사용하여 다른 응답에 재사용할 수 없는 응답으로 특정된 RRSIG를 생성합니다.
# DNSSEC 서명 문제 해결
이 섹션의 정보는 활성화, 비활성화, KSK(키 서명 키)를 포함하여 DNSSEC 서명 문제를 해결하는 데 도움이 될 수 있습니다.
DNSSEC 활성화
DNSSEC 서명을 활성화하기 전에 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md)에서 사전 조건을 읽어야 합니다.
DNSSEC 비활성화
DNSSEC를 안전하게 비활성화하기 위해 Route 53는 대상 영역이 신뢰 체인에 속하는지 확인합니다. 대상 영역의 상위 영역에 대상 영역의 NS 레코드와 대상 영역의 DS 레코드가 있는지 확인합니다. 대상 영역을 공개적으로 확인할 수 없는 경우(예: NS 및 DS를 쿼리할 때 SERVFAIL 응답을 받음) Route 53는 DNSSEC를 비활성화해도 안전한지 여부를 판단할 수 없습니다. 상위 영역에 확인하여 해결한 다음에 DNSSEC를 다시 비활성화해 볼 수 있습니다.
KSK 상태가 **Action needed(작업 필요)**인 경우
Route 53 DNSSEC가 해당 `ACTION_NEEDED`에 대한 액세스 권한을 상실하면(권한 변경 또는 AWS KMS key 삭제로 인해) KSK가 상태를 **필요한 작업** AWS KMS key (또는 [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) 상태)으로 변경할 수 있습니다.
KSK의 상태가 **작업 필요(Action needed)**인 경우는 DNSSEC 검증 해석기를 사용하는 클라이언트에 영역 가동 중단이 발생함을 의미하므로 프로덕션 영역을 확인되지 않는 상황을 방지할 수 있도록 신속하게 조치를 취해야 합니다.
이 문제를 해결하려면 KSK가 기반으로 하는 고객 관리형 키가 활성화되었으며 올바른 권한이 있는지 확인하세요. 필요한 권한에 대한 자세한 정보는 [DNSSEC 서명에 필요한 Route 53 고객 관리형 키 권한](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC) 섹션을 참조하세요.
KSK를 수정한 후에 설명된 AWS CLI대로 콘솔 또는를 사용하여 다시 활성화합니다[2단계: DNSSEC 서명 활성화 및 KSK 생성](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable).
향후이 문제를 방지하려면 Amazon CloudWatch 에 제안된 대로 KSK의 상태를 추적하는 지표를 추가하는 것이 좋습니다[Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md).
KSK 상태가 **내부 오류(Internal failure)**인 경우
KSK의 상태가 **내부 오류(Internal failure)**(또는 [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) 상태가 `INTERNAL_FAILURE`)인 경우, 문제가 해결될 때까지 다른 DNSSEC 엔터티에서 작업할 수 없습니다. 이 KSK 또는 다른 KSK로 작업하는 것을 포함하여 DNSSEC 서명으로 작업하려면 먼저 조치를 취해야 합니다.
문제를 해결하려면 KSK를 다시 활성화하거나 비활성화합니다.
문제를 해결하려면 API로 작업할 때 서명 활성화([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) 또는 서명 비활성화([DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html))를 시도합니다.
**내부 오류(Internal failure)** 문제는 신속하게 해결해야 합니다. 문제를 해결하기 전까지는 호스팅 영역을 변경할 수 없습니다. 단, **내부 오류(Internal failure)** 수정 작업은 예외로 합니다.
# AWS Cloud Map을 사용하여 레코드 및 상태 확인 생성
인터넷 트래픽이나 Amazon VPC 내부의 트래픽을 애플리케이션 구성 요소 또는 마이크로서비스로 라우팅하려면 AWS Cloud Map을 사용하여 레코드를 자동으로 생성하고 선택적으로 상태 확인을 생성할 수 있습니다. 자세한 내용은 [AWS Cloud Map 개발자 안내서](https://docs.aws.amazon.com/cloud-map/latest/dg/)를 참조하세요.
# DNS 제한 및 동작
DNS 메시징은 호스팅 영역 및 레코드를 생성하고 사용하는 방식에 영향을 미치는 요인들에 의해 제한을 받습니다. 이 섹션에서는 이러한 요인들에 대해 알아봅니다.
## 최대 응답 크기
DNS 표준을 따르기 위해, UDP를 거쳐 전송되는 응답의 크기는 512바이트를 넘지 않습니다. 512바이트를 초과하는 응답들은 중간에 잘리게 되므로 해석기가 반드시 TCP를 거쳐 요청을 재발행해야 합니다. [RFC 2671](https://tools.ietf.org/html/rfc2671)에 정의된 대로 Resolver가 EDNS0을 지원하고 EDNS0 옵션을 Amazon Route 53에 알린다면, Route 53는 잘림 없이 UDP를 거쳐 4,096바이트까지 응답을 허용합니다.
## 권한 섹션 처리
성공적인 쿼리를 위해 Route 53는 DNS 응답의 권한 섹션에 해당 호스팅 영역에 대한 이름 서버(NS) 레코드를 추가합니다. 찾을 수 없는 이름(NXDOMAIN 응답)의 경우 Route 53는 DNS 응답의 권한 섹션에 해당 호스팅 영역에 대한 권한 시작(SOA) 레코드([RFC 1035](https://tools.ietf.org/html/rfc1035)에 정의됨)를 추가합니다.
## 추가 섹션 처리
Route 53는 추가 섹션에 레코드를 추가합니다. 레코드가 알려져 있고 적절하다면, 서비스는 응답 섹션에 인용된 MX, CNAME, NS, 또는 SRV 레코드의 어떤 대상에 대해서라도 A 또는 AAAA 레코드를 추가합니다. 이 DNS 레코드 유형에 대한 자세한 내용은 다음([지원되는 DNS 레코드 유형](ResourceRecordTypes.md))을 참조하십시오.
# 관련 주제
DNS 호스팅 외에 도메인 등록도 Route 53로 이전하는 방법에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [도메인 이전을 위한 이전 전 체크리스트](domain-transfer-checklist.md) - 일반적인 이전 실패를 방지하기 위해 도메인 등록을 이전하기 전에 이 체크리스트를 완료합니다.
+ [도메인 등록을 Amazon Route 53으로 이전하기](domain-transfer-to-route-53.md) - 도메인 등록을 다른 등록 기관에서 Route 53로 이전하기 위한 단계별 프로세스입니다.
+ [도메인 이전](domain-transfer.md) - AWS 계정 간 이전을 포함한 모든 도메인 이전 옵션을 소개하는 개요입니다.