기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 레코드 작업
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**을 지정한 경우에만 해당 레코드를 찾을 수 있습니다.