기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 라우팅 정책 선택 레코드를 생성할 때 라우팅 정책을 선택하게 되는데, 이는 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)를 참조하세요.