아래 섹션을 확장하면 카테고리별 FAQ를 볼 수 있습니다. 

무료로 AWS 시작하기

무료 계정 생성
또는 콘솔에 로그인

12개월 동안 AWS 프리 티어에 액세스하여 연중무휴 24시간 고객 서비스, 지원 포럼 등을 비롯한 AWS Basic Support의 기능을 사용해 보십시오.

현재 Amazon Route 53은 AWS 프리 티어에서 제공되지 않는다는 점에 유의하십시오.


Q: Domain Name System(DNS) 서비스란 무엇입니까?

DNSwww.example.com과 같이 사람이 읽을 수 있는 이름을 컴퓨터 간 연결을 위해 컴퓨터에서 사용하는 192.0.2.1과 같은 숫자 IP 주소로 변환하는 서비스로 전 세계에서 사용하고 있습니다. 인터넷의 DNS 시스템은 이름과 숫자 간의 매핑을 관리하여 마치 전화번호부와 같은 기능을 합니다. DNS에서 이름은 사람이 기억하기 쉬운 도메인 이름(www.example.com)이며 숫자는 인터넷 상에서 컴퓨터의 위치를 명시하는 IP 주소(192.0.2.1)입니다. DNS 서버는 이름에 대한 요청을 IP 주소로 변환하여 최종 사용자가 도메인 이름을 웹 브라우저에 입력할 때 해당 사용자를 어떤 서버에 연결할 것인지를 제어합니다. 이 요청을 “쿼리”라고 부릅니다.

Q: Amazon Route 53는 무엇입니까?

Amazon Route 53는 가용성과 확장성이 우수한 도메인 이름 시스템(DNS), 도메인 이름 등록, 상태 확인 웹 서비스입니다. 이 서비스는 최종 사용자를 인터넷 애플리케이션으로 라우팅할 수 있는 매우 안정적이고 비용 효율적인 방법을 개발자와 기업에 제공하기 위해 설계되었습니다. 이 서비스에서는 example.com과 같은 이름을 192.0.2.1과 같은 컴퓨터 간 연결에 사용되는 숫자 IP 주소로 변환합니다. DNS를 상태 확인 서비스와 결합하여 정상적인 엔드포인트로 트래픽을 라우팅하거나 개별적으로 엔드포인트에 대한 모니터링 또는 경보를 설정할 수 있습니다. example.com과 같은 도메인 이름을 구매 및 관리하고 도메인에 대한 DNS 설정을 자동으로 구성할 수도 있습니다. Route 53는 사용자 요청을 Amazon EC2 인스턴스, Elastic Load Balancing 로드 밸런서, Amazon S3 버킷과 같이 AWS에서 실행되는 인프라에 효과적으로 연결합니다. 사용자를 AWS 외부의 인프라로 라우팅하는 데 Route 53를 사용할 수도 있습니다.

Q: Amazon Route 53로 할 수 있는 작업은 무엇입니까?

Amazon Route 53를 사용하면 공개 DNS 레코드를 생성하고 관리할 수 있습니다. 전화번호부와 마찬가지로, Route 53는 인터넷의 DNS 전화번호부에 있는 도메인 이름의 IP 주소를 관리할 수 있게 해 줍니다. 또한, Route 53은 특정 도메인 이름을 192.0.2.1과 같이 그에 상응하는 IP 주소로 변환하라는 요청에 응답합니다. Route 53를 사용하여 새로운 도메인에 대한 DNS 레코드를 생성하거나 기존 도메인에 대해 DNS 레코드를 전송할 수 있습니다. 간단하며 표준 기반인 Route 53의 REST API를 사용하면 DNS 레코드를 쉽게 생성하고, 업데이트하고, 관리할 수 있습니다. Route 53는 애플리케이션은 물론 웹 서버 및 기타 리소스의 상태와 성능을 모니터링할 수 있는 상태 확인도 추가적으로 제공합니다. 또한 새 도메인 이름을 등록하거나 기존의 도메인 이름을 Route 53이 관리하도록 이전할 수 있습니다.

Q: Amazon Route 53을 시작하려면 어떻게 해야 합니까? 

Amazon Route 53는 몇 분 안에 시작할 수 있는 간편한 웹 서비스 인터페이스 입니다. DNS 레코드는 AWS Management Console 또는 Route 53의 API로 "호스팅 영역" 내에 구성됩니다. Route 53을 사용하려면 다음과 같이 하면 됩니다.

  • 서비스 페이지에서 가입 버튼을 클릭하면 서비스에 가입할 수 있습니다.
  • 이미 도메인 이름이 있는 경우:
    • AWS Management Console 또는 CreateHostedZone API를 사용하여 도메인에 대해 DNS 레코드를 저장할 수 있는 호스팅 영역을 생성할 수 있습니다. 호스팅 영역을 생성하면, 높은 가용성을 위해 4개의 TLD(최상위 도메인)에서 4개의 Route 53 이름 서버를 받게 됩니다.
    • 또한 Route 53에서 도메인 이름을 관리하도록 AWS Management Console 또는 API를 사용하여 도메인 이름을 전송할 수 있습니다.
  • 보유한 도메인 이름이 없는 경우:
    • AWS Management Console 또는 API를 사용하여 새로운 도메인 이름을 등록하십시오.
    • Route 53에서 도메인에 대한 DNS 레코드를 저장할 호스팅 영역을 자동으로 생성합니다. 또한 높은 가용성을 보장하기 위해 4개의 최상위 도메인(TLD)에서 4개의 Route 53 이름 서버를 받게 됩니다.
  • 처음에 호스팅 영역은 기본 DNS 레코드 세트로 채워지며, 여기에는 도메인의 쿼리에 응답하는 4개의 가상 이름 서버도 포함됩니다. AWS Management Console을 사용하거나 ChangeResourceRecordSet를 호출하여 이 집합 내에 있는 레코드를 추가, 삭제, 또는 변경할 수 있습니다. API . 지원되는 DNS 레코드 목록은 여기를 참조하십시오.
  • 도메인 이름을 Route 53에서 관리하지 않는 경우 도메인에 대한 이름 서버를 호스팅 영역과 연결된 이름 서버로 업데이트할 수 있도록 도메인 이름을 등록한 등록 기관에 알려야 합니다. 도메인 이름을 이미 Route 53에서 관리하는 경우 도메인 이름이 사용자 영역을 호스팅하는 이름 서버로 자동 연결됩니다.

Q: Amazon Route 53의 높은 가용성과 짧은 대기 시간은 어떤 방식으로 제공되는 것입니까?

Route 53는 AWS의 가용성이 높고 신뢰할 수 있는 인프라를 사용하여 개발하였습니다. DNS 서버는 전 세계적으로 분산되어 있어 인터넷 및 네트워크 문제를 우회할 수 있으며 최종 사용자가 애플리케이션에 안정적으로 라우팅될 수 있도록 합니다. Route 53는 중요한 애플리케이션에서 필요한 수준의 신뢰도를 제공할 수 있도록 설계되었습니다. 전 세계적인 규모의 DNS 서버 애니캐스트 네트워크를 사용하는 Route 53는 네트워크 상태에 따라 최적의 위치에서 쿼리에 자동으로 응답하도록 설계되었습니다. 그 결과 서비스가 최종 사용자에 대해 낮은 쿼리 지연 시간을 구현할 수 있습니다.

Q: Amazon Route 53 서비스의 DNS 서버 이름은 무엇입니까?

가용성이 높은 서비스를 제공할 수 있도록 각각의 Amazon Route 53 호스팅 영역은 고유의 가상 DNS 서버 집합을 가집니다. 따라서 각각의 호스팅 영역에 대한 DNS 서버 이름은 호스팅 영역이 생성될 때 시스템에서 할당됩니다.

Q: 도메인과 호스팅 영역의 차이는 무엇입니까?

도메인은 일반적인 DNS 개념입니다. 도메인 이름은 주소를 숫자로 표현하는 인터넷 리소스를 쉽게 인지할 수 있게 하는 이름입니다. 예를 들어, amazon.com은 도메인입니다. 호스팅 영역은 Amazon Route 53의 개념입니다. 호스팅 영역은 일반적인 DNS 영역 파일과 유사합니다. 단일의 상위 도메인 이름에 속하면서 함께 관리할 수 있는 레코드 세트를 말합니다. 호스팅 영역 내에 있는 모든 리소스 레코드 세트는 반드시 호스팅 영역의 도메인 이름을 접미사로 포함하고 있어야 합니다. 예를 들면 amazon.com 호스팅 영역에는 www.amazon.comwww.aws.amazon.com이라는 레코드를 포함할 수 있으나 www.amazon.ca라는 이름의 레코드는 포함할 수 없습니다. 호스팅 영역을 생성, 점검, 변경 및 삭제하려면 Route 53 Management Console 또는 API를 사용해야 합니다. 또한 Management Console 또는 API를 사용하여 새로운 도메인 이름을 등록하고 Route 53에서 관리하도록 기존 도메인 이름을 전송할 수 있습니다.

Q: Amazon Route 53의 이용 요금은 얼마입니까?

Amazon Route 53에서는 호스팅 영역, 쿼리, 상태 확인, 도메인 이름에 대한 실제 서비스 사용을 기반으로 비용을 청구합니다. 자세한 내용은 Amazon Route 53 요금 페이지를 참조하십시오.

사용 요금은 종량 과금제입니다. 최소 요금, 의무 사용량, 초과 요금이 없습니다. AWS 월 사용량 계산기를 사용해 월별 청구액을 추산할 수 있습니다.

Q: Amazon Route 53에서 도메인 관리를 위해 어떤 유형의 액세스 제어를 설정할 수 있습니까?

AWS Identity and Access Management(IAM) 서비스를 사용하여 Amazon Route 53 호스팅 영역에 대한 관리 액세스를 제어할 수 있습니다. AWS IAM을 사용하면 여러 사용자를 생성하고 AWS 계정 내에 사용자 개개인에 대한 승인 내역을 관리할 수 있어 조직 내에서 누가 DNS 레코드를 변경했는지 제어할 수 있습니다. AWS IAM에 대한 자세한 정보는 여기를 참조하십시오.

Q: Amazon Route 53에 가입하였으나, 서비스를 사용하려고 하면 "The AWS Access Key ID needs a subscription for the service"라는 메시지가 표시됩니다.

새로 AWS 서비스에 가입하면 활성화되기까지 최대 24시간이 걸리는 경우도 있으며 이 시간 동안에는 서비스에 로그인할 수 없습니다. 활성화가 되었다는 이메일을 받지 못한 채 24시간 이상이 경과한 경우 지불 정보 인증이나 계정에 문제가 있는 것일 수 있습니다. AWS 고객 서비스 팀에 연락하셔서 도움을 받으시기 바랍니다.

Q: Amazon Route 53는 서비스 수준 협약(SLA)을 제공합니까?

예. Amazon Route 53 SLA는 고객의 월간 가동률이 당사가 요금 청구 주기에 약속한 서비스보다 낮은 경우 서비스 수준 계약을 제공합니다. 자세한 내용은 여기에서 확인할 수 있습니다.

Q: 내 호스팅 영역에 대한 요금은 언제 부과됩니까?

요금은 호스팅 영역이 생성되었을 때 한 번 청구되고 그 후에는 매월 1일에 청구됩니다.  

Q: 같은 달에 같은 호스팅 영역에 대해 2건의 요금이 청구되는 이유는 무엇입니까?

호스팅 영역에는 12시간의 유예 기간이 적용됩니다. 호스팅 영역을 생성하고 12시간 이내에 이를 삭제하면 해당 호스팅 영역에 대한 요금이 부과되지 않습니다. 이러한 유예 기간이 종료된 후에는 호스팅 영역에 표준 월별 요금이 즉시 부과됩니다. 달의 마지막 날(예: 1월 31일)에 호스팅 영역을 생성하면, 1월 요금이 2월 요금과 함께 2월 인보이스에 표시될 수 있습니다.

Q. Amazon Route 53이 쿼리 로깅 기능을 제공합니까?

날짜-시간 스탬프, 도메인 이름, 쿼리 유형, 위치 등을 포함하여 Amazon Route 53이 수신하는 쿼리에 대한 정보를 로깅하도록 Amazon Route 53을 구성할 수 있습니다. 쿼리 로깅을 구성하면 Amazon Route 53은 CloudWatch Logs에 로그를 보내기 시작합니다. 쿼리 로그에 액세스하려면 CloudWatch Logs 도구를 사용하면 됩니다. 자세한 내용은 설명서를 참조하십시오.


Q: Amazon Route 53는 애니캐스트 네트워크를 사용합니까?

예. 애니캐스트는 네트워킹 및 라우팅 기술로, 최종 사용자의 DNS 쿼리가 주어진 네트워크 조건에서 최적의 Route 53 위치로부터 응답을 얻을 수 있습니다. 그 결과 사용자는 Route 53를 통해 높은 가용성과 개선된 성능을 경험하게 됩니다.

Q: Amazon Route 53를 사용하여 관리할 수 있는 호스팅 영역 수에는 제한이 있습니까?

각각의 Amazon Route 53 계정은 최대 500개의 호스팅 영역과 호스팅 영역당 10,000개의 리소스 레코드 세트로 제한되어 있습니다. 한도를 높이려면 이 요청서를 작성해 주십시오. 업무일 기준 2일 이내에 답변해 드리겠습니다.

Q: 영역을 Route 53으로 가져오기 하려면 어떻게 해야 합니까?

Route 53은 많은 DNS 공급자 및 BIND 같은 표준 DNS 서버 소프트웨어에서 내보내는 표준 DNS 영역 파일을 가져올 수 있습니다. 기본 NS 및 SOA 레코드를 제외하고 비어있는 기존 호스팅 영역뿐 아니라 새로 생성된 호스팅 영역에서 영역 파일을 직접 Route 53 콘솔에 붙여 넣을 수 있고 Route 53은 호스팅 영역에 자동으로 레코드를 생성합니다. 영역 파일 가져오기를 시작하려면 Amazon Route 53 Developer Guide를 참조하십시오.

Q: 동일한 도메인 이름에 대해 여러 개의 호스팅 영역을 생성할 수 있습니까? 

예. 여러 개의 호스팅 영역을 생성하면 "테스트" 환경에서 DNS 설정 값을 확인할 수 있으며, "생산" 호스팅 영역에서 해당 설정 값을 복제할 수 있습니다. 예를 들어, 호스팅 영역 Z1234가 example.com의 테스트 버전인 경우 이름 서버 ns-1, ns-2, ns-3, 및 ns-4에 호스팅합니다. 마찬가지로 호스팅 영역 Z5678이 example.com의 테스트 버전이라면 ns-5, ns-6, ns-7, 및 ns-8에 호스팅 합니다. 각각의 호스팅 영역에는 해당 영역과 관련된 가상의 이름 서버 세트가 있으므로, Route 53는 어떤 이름 서버로 DNS 쿼리를 전송할 것인지에 따라 example.com에 대한 DNS 쿼리에 응답합니다.

Q: Amazon Route 53은 웹 사이트 호스팅도 제공합니까? 

아니요. Amazon Route 53는 신뢰할 수 있는 DNS 서비스로서, 웹 사이트 호스팅은 제공하지 않습니다. 하지만 Amazon Simple Storage Service(S3)를 사용하면 정적 웹 사이트를 호스팅할 수 있습니다. 동적 웹 사이트 또는 기타 웹 애플리케이션을 호스팅할 경우, 기존의 웹 호스팅 솔루션에 비해 유동성, 제어 및 상당한 비용 절감 효과를 제공하는 Amazon Elastic Compute Cloud(EC2)를 사용할 수 있습니다. Amazon EC2에 대한 자세한 정보는 여기를 참조하십시오. 정적 웹 사이트 및 동적 웹 사이트 모두에 대해 Amazon CloudFront를 사용하여 전 세계 최종 사용자에게 짧은 지연 시간을 제공할 수 있습니다. Amazon CloudFront에 대한 자세한 정보는 여기를 참조하십시오.

Q: Amazon Route 53은 어떤 DNS 레코드 유형을 지원합니까? 

Amazon Route 53는 현재 다음과 같은 DNS 레코드 유형을 지원합니다.

  • A(주소 레코드)
  • AAAA(IPv6 주소 레코드)
  • CNAME(정식 이름 레코드)
  • CAA(인증 기관 인증)
  • MX(메일 교환 레코드)
  • NAPTR(이름 권한 포인터 레코드)
  • NS(이름 서버 레코드)
  • PTR(포인터 레코드)
  • SOA(권한 시작 레코드)
  • SPF(Sender Policy Framework)
  • SRV(서비스 로케이터)
  • TXT(텍스트 레코드)
  • 부가적으로 Amazon Route 53은 ‘별칭’ 레코드도 제공합니다. 이는 Amazon Route 53을 위한 가상 레코드입니다. 별칭 레코드는 사용자의 호스팅 영역에 있는 리소스 레코드 세트를 웹 사이트로 구성된 Amazon Elastic Load Balancing 로드 밸런서, Amazon CloudFront 배포, AWS Elastic Beanstalk 환경 또는 Amazon S3 버킷에 매핑합니다. 별칭 레코드는 CNAME 레코드처럼 기능하여 하나의 DNS 이름(example.com)을 다른 '대상' DNS 이름(elb1234.elb.amazonaws.com)으로 매핑할 수 있습니다. 확인자에게 보이지 않는다는 점이 CNAME 레코드와 다른 점입니다. 확인자는 A 레코드와 대상 레코드의 IP 주소만 볼 수 있습니다.

향후 다른 레코드 유형도 추가할 예정입니다.

Q: Amazon Route 53는 와일드카드 입력을 지원합니까? 지원하는 경우 어떤 레코드 유형이 이를 지원합니까?

예. 도메인에 대한 DNS 설정을 더 쉽게 구성할 수 있도록 Amazon Route 53은 NS 레코드를 제외한 모든 레코드 유형에 대해 와일드카드 입력을 지원합니다. 와일드카드 입력은 설정한 구성에 따라 도메인 이름의 요청에 맞게 일치시키는 DNS 영역 내의 레코드입니다. 예를 들어 *.example.com과 같은 와일드카드 DNS 레코드는 www.example.comsubdomain.example.com의 쿼리에 부합합니다.

Q: 다양한 레코드 유형에 대한 기본 TTL은 무엇이며, 이 값을 변경할 수 있습니까?

DNS 확인자가 응답을 캐시하는 시간은 레코드마다 TTL이라는 값에 의해 설정됩니다. Amazon Route 53는 레코드 유형에 기본값을 가지고 있지는 않습니다. 그러므로 레코드마다 TTL을 항상 명시하여 캐시 DNS 확인자가 TTL에서 명시한 길이에 맞게 DNS 레코드를 캐시할 수 있게 해야 합니다.

Q: 별칭 레코드를 하위 도메인과 함께 사용할 수 있습니까?

예. 또한, 별칭 레코드를 사용하여 하위 도메인(www.example.com, pictures.example.com 등)을 ELB 로드 밸런서, CloudFront 배포 또는 S3 웹 사이트 버킷에 매핑할 수 있습니다.

Q: 리소스 레코드 세트에 대한 변경 사항이 트랜잭션으로 처리됩니까?

예. 트랜잭션에 대한 변경 사항은 일관적이고 신뢰할 수 있으며 다른 변경과는 무관합니다. Amazon Route 53는 변경 내용이 모든 개별 DNS 서버에 적용되거나, 아니면 전혀 적용되지 않도록 설계되었습니다. 이로써 DNS 쿼리는 항상 일관되게 응답을 받을 수 있으며 이는 대상 서버 간 플리핑과 같은 변경이 있을 때 특히 중요합니다. API를 사용할 때 ChangeResourceRecordSet에 대한 각각의 호출은 변경 상태를 추적하는 데 사용할 수 있는 식별자를 반환합니다. 일단 상태가 INSYNC로 보고되면 변경 내용은 모든 Route 53 DNS 서버에서 수행된 것입니다.

Q: 단일 레코드와 여러 개의 IP 주소를 연결할 수 있습니까?

예. 단일 레코드와 여러 개의 IP 주소를 연결하는 것은 보통 지역적으로 배포되어 있는 웹 서버의 부하량을 분산하기 위해 사용되는 것입니다. Amazon Route 53는 A 레코드에 대한 여러 IP 주소를 열거할 수 있게 하며 모든 구성된 IP 주소로 DNS 요청에 응답합니다.

Q: Amazon Route 53에서 내 DNS 설정을 변경하는 경우 변경 사항이 전체적으로 적용되는 데 시간이 얼마나 걸립니까? 

Amazon Route 53은 DNS 레코드에 대한 업데이트를 일반적인 조건에서라면 60초 이내에 권한 DNS 서버의 전 세계 네트워크에 적용하도록 설계되었습니다. API 호출이 INSYNC 상태 목록을 반환하면 변경 사항이 전 세계에 성공적으로 적용된 것입니다.

DNS 해석기를 캐싱하는 것은 Amazon Route 53 서비스의 제어 대상이 아니며, TTL(Time to Live)에 따라 리소스 레코드 세트를 캐시합니다. 변경에 대한 INSYNC 또는 PENDING 상태는 Route 53의 권한 DNS 서버 상태만을 나타냅니다.

Q: Route 53 리소스에서 변경 사항 및 다른 작업의 내역을 볼 수 있습니까?

예, AWS CloudTrail을 통해 Route 53의 API 호출 내역을 기록할 수 있습니다. 시작하려면 CloudTrail product page를 참조하십시오.

Q: 변경 사항을 호스팅 영역으로 롤백하는 데 AWS CloudTrail 로그를 사용할 수 있습니까? 

아니요. 변경 사항을 호스팅 영역으로 롤백하기 위해 CloudTrail 로그를 사용하지 않는 것이 좋습니다. CloudTrail 로그를 사용하여 영역 변경 내역을 재구성하는 작업이 완전하지 않을 수 있기 때문입니다.

AWS CloudTrail 로그는 보안 분석, 리소스 변경 추적 및 규정 준수 감사를 위해 사용할 수 있습니다.

Q: Amazon Route 53은 DNSSEC를 지원합니까?

Amazon Route 53은 현재 DNS에 대해 DNSSEC를 지원하지 않습니다. 하지만 Amazon Route 53에서는 도메인 등록에 DNSSEC를 적용할 수 있습니다.  

Q: Amazon Route 53은 IPv6를 지원합니까?

예. Amazon Route 53은 정방향(AAAA) 및 역방향(PTR) IPv6 레코드 모두를 지원합니다. Amazon Route 53 서비스 자체에서도 IPv6를 사용할 수 있습니다. IPv6 네트워크의 재귀적 DNS 해석기는 Amazon Route 53을 통해 DNS 쿼리를 제출할 때 IPv4 또는 IPv6 전송 중 어느 것이나 활용할 수 있습니다. 또한, Amazon Route 53 상태 확인은 IPv6 프로토콜을 사용한 엔드포인트 모니터링을 지원합니다.

Q: 루트 도메인(mydomain.com vs. www.mydomain.com)을 Elastic Load Balancer에 지정할 수 있습니까?

예. Amazon Route 53은 ‘별칭’ 레코드라고 불리는 특수한 유형의 레코드를 제공하므로, Zone Apex(example.com) DNS 이름을 ELB DNS 이름(예: elb1234.elb.amazonaws.com)에 매핑할 수 있습니다. Amazon Elastic Load Balancer와 연관된 IP 주소는 언제든 규모 확장 또는 소프트웨어 업데이트에 맞게 변경할 수 있습니다. Route 53는 로드 밸런서에 대한 하나 이상의 IP 주소를 사용하여 각 별칭 레코드 요청에 응답합니다. ELB 로드 밸런서에 매핑된 별칭 레코드에 대한 쿼리는 무료입니다. 이 쿼리는 Amazon Route 53 사용 보고서에 “Intra-AWS-DNS-Queries”로 기재되어 있습니다.

Q: Zone Apex(example.com versus www.example.com)가 Amazon S3에 호스팅된 내 웹 사이트를 가리키도록 할 수 있습니까? 

예. Amazon Route 53은 ‘별칭’ 레코드라는 특수한 유형의 레코드를 제공하므로, Zone Apex(example.com) DNS 이름을 Amazon S3 웹 사이트 버킷(예: example.com.s3-website-us-west-2.amazonaws.com)에 매핑할 수 있습니다. Amazon S3 웹 사이트 엔드포인트와 연결된 IP 주소는 언제든 규모 확장 또는 소프트웨어 업데이트에 맞게 변경할 수 있습니다. Route 53는 버킷에 대한 IP 주소를 사용하여 각 별칭 레코드 요청에 응답합니다. Route 53는 웹 사이트로 구성된 S3 버킷에 매핑된 별칭 레코드에 대한 쿼리에는 요금을 부과하지 않습니다. 이 쿼리는 Amazon Route 53 사용 보고서에 “Intra-AWS-DNS-Queries”로 기재되어 있습니다.

Q: 내 Zone Apex(example.com versus www.example.com)가 Amazon CloudFront 배포를 가리키도록 할 수 있습니까? 

예. Amazon Route 53은 ‘별칭’ 레코드라는 특수한 유형의 레코드를 제공하므로, Zone Apex(example.com) DNS 이름을 Amazon CloudFront 배포(예: d123.cloudfront.net)에 매핑할 수 있습니다. Amazon CloudFront 엔드포인트와 연결된 IP 주소는 최종 사용자를 가장 가까운 CloudFront 엣지로 유도하기 위해 최종 사용자의 위치에 따라 변경되며 확장, 축소 또는 소프트웨어 업데이트로 인해서도 언제든지 변경될 수 있습니다. Route 53은 각 별칭 레코드에 대한 각 요청에 대해 해당 배포의 IP 주소로 응답합니다. Route 53은 CloudFront 배포에 매핑되어 있는 별칭 레코드에 대한 쿼리에 대해서는 비용을 청구하지 않습니다. 이 쿼리는 Amazon Route 53 사용 보고서에 “Intra-AWS-DNS-Queries”로 기재되어 있습니다.

Q: Zone Apex(example.com versus www.example.com)가 AWS Elastic Beanstalk 환경을 가리키도록 할 수 있습니까? 

예. Amazon Route 53은 ‘별칭’ 레코드라고 불리는 특수한 유형의 레코드를 제공하므로, Zone Apex(example.com) DNS 이름을 AWS Elastic Beanstalk DNS 이름(예: example.elasticbeanstalk.com)에 매핑할 수 있습니다. AWS Elastic Beanstalk 환경과 연결된 IP 주소는 언제든 규모 확장, 규모 축소 또는 소프트웨어 업데이트에 맞게 변경할 수 있습니다. Route 53은 환경에 대한 하나 이상의 IP 주소를 사용하여 각 별칭 레코드 요청에 응답합니다. AWS Elastic Beanstalk 환경에 매핑된 별칭 레코드에 대한 쿼리는 무료입니다. 이 쿼리는 Amazon Route 53 사용 보고서에 “Intra-AWS-DNS-Queries”로 기재되어 있습니다.

Q: Amazon Route 53을 Amazon Simple Storage Service(S3) 및 Amazon CloudFront와 함께 사용하려면 어떻게 해야 합니까? 

Amazon CloudFront를 통해 제공되는 웹 사이트나 Amazon S3에서 호스팅되는 정적 웹 사이트의 경우 Amazon Route 53 서비스를 사용하여 CloudFront 배포 및 Amazon S3 웹 사이트 버킷을 가리키는 도메인에 대한 별칭 레코드를 생성할 수 있습니다. 정적 웹 사이트를 호스팅하도록 구성되지 않은 Amazon S3 버킷의 경우 도메인 및 해당 Amazon S3 버킷 이름에 대한 CNAME 레코드를 생성할 수 있습니다. 또한 모든 경우에 다른 도메인 이름에 Amazon S3 버킷이나 CloudFront 배포를 각각 구성하여, 버킷 또는 배포에 대해 도메인 이름과 AWS 도메인 이름 간의 별칭을 확정할 수도 있습니다.

정적 웹 사이트를 호스팅하도록 구성한 CloudFront 배포 및 Amazon S3 버킷의 경우 CNAME을 사용하는 대신 CloudFront 배포 또는 Amazon S3 웹 사이트 버킷에 매핑되는 '별칭' 레코드를 생성하는 것이 좋습니다. 별칭 레코드를 사용하면 두 가지 장점이 있습니다. 첫째, CNAME과 달리 루트 도메인(예: www.example.com 대신 www.example.com)에 대한 별칭 레코드를 만들 수 있으며 둘째, 별칭 레코드에 대한 쿼리가 무료로 제공됩니다.

Q: DNS 쿼리 테스트 도구가 dig 또는 nslookup 명령과는 다른 응답을 반환하는 이유는 무엇입니까?

Amazon Route 53에서 리소스 레코드 세트가 변경되는 경우 이 서비스는 DNS 레코드에 수행된 업데이트를 전 세계의 권한 DNS 서버 네트워크로 전파합니다. 전파가 완료되기 전에 레코드를 테스트하면 dig 또는 nslookup 유틸리티를 사용할 때 이전 값을 보게 될 수도 있습니다. 또한, 인터넷상의 DNS 해석기는 Amazon Route 53 서비스에서 제어할 수 없으며 TTL(Time To Live)에 따라 리소스 레코드 집합을 캐시합니다. 즉, dig/nslookup 명령에서 캐시된 값을 반환할 수도 있습니다. 도메인 이름 등록 대행자가 Amazon Route 53 호스팅 영역에 있는 이름 서버를 사용하도록 해야 합니다. 그렇지 않은 경우 Amazon Route 53은 도메인에 대한 쿼리의 신뢰성을 보장하지 않습니다.


Q: Amazon Route 53는 WRR(가중치 기반 라운드 로빈)을 지원합니까?

예. Weighted Round Robin에서는 각 응답이 처리되는 빈도를 지정할 수 있도록 리소스 레코드 세트에 가중치를 할당할 수 있습니다. 이 기능을 사용하면 A/B 테스트를 수행하거나, 소프트웨어의 변경이 이루어진 서버로 소규모 트래픽을 전송할 수 있습니다. 예를 들어 하나의 DNS 이름에 연결된 2개의 레코드 세트가 있다고 가정해 보겠습니다(하나는 가중치 3이고 다른 하나는 가중치 1). 이때 해당 시간의 75%는 Route 53가 가중치 3의 레코드 세트를 반환하며, 25%는 가중치 1의 레코드 세트를 반환합니다. 가중치는 0부터 255 사이의 숫자로 지정할 수 있습니다.

Q: Amazon Route 53의 지연 시간 기반 라우팅(LBR) 기능은 무엇입니까?

LBR(지연 시간 기반 라우팅)은 Amazon Route 53의 새 기능으로서, 전 세계 사용자를 위해 애플리케이션 성능을 개선할 수 있는 기능입니다. 여러 AWS 리전과 Amazon Route 53에서 애플리케이션을 실행할 수 있으며, 전 세계 수십 개의 다른 엣지를 검색하여 최종 사용자를 지연 시간이 가장 낮은 AWS 리전으로 라우팅합니다.

Q: Amazon Route 53의 지연 시간 기반 라우팅(LBR) 기능을 사용하려면 어떻게 해야 합니까?

AWS Management Console 또는 간편한 API를 사용하여 Amazon Route 53의 새로운 LBR 기능을 빠르고 쉽게 시작하실 수 있습니다. 여러 개의 AWS IP 주소 또는 AWS 엔드포인트의 이름을 포함하는 레코드 세트를 간편하게 생성할 수 있습니다. 또한 레코드를 Weighted Record Set로 표시하는 것처럼, LBR-enabled Record Set로 표시할 수 있습니다. 이후에는 Amazon Route 53에서 처리합니다. 즉, 각각의 요청에 대한 최적의 엔드포인트를 결정하고 그에 따라 최종 사용자의 경로를 지정합니다. 이는 Amazon의 전 세계적인 콘텐츠 전송 서비스인 Amazon CloudFront와 흡사합니다. LBR(지연 시간 기반 라우팅) 사용 방법은 Amazon Route 53 Developer Guide에서 자세히 알아볼 수 있습니다.

Q: Amazon Route 53의 지연 시간 기반 라우팅(LBR) 이용 요금은 얼마입니까?

모든 AWS 서비스와 마찬가지로 Amazon Route 53 및 LBR을 사용하기 위한 선결제 금액이나 장기 약정은 없습니다. 실제로 사용한 호스팅 영역과 쿼리에 대해서만 비용을 지불하면 됩니다. 지연 시간 기반 라우팅 쿼리 요금에 대한 자세한 내용은 Amazon Route 53 요금 페이지를 참조하십시오.

Q: Amazon Route 53의 지역 DNS 기능이란 무엇입니까?

Route 53 지역 DNS를 사용하면 지리적 위치를 기반으로 한 특정 엔드포인트로 요청을 보내 로드의 균형을 맞출 수 있습니다. 지역 DNS를 사용하면 올바른 언어로 된 세부 정보 페이지 표시나 라이선스가 있는 마켓으로 콘텐츠 배포를 제한하는 등 지역화된 콘텐츠를 사용자 지정할 수 있습니다. 또한 지역 DNS를 통해 예측 가능하고 관리가 쉬운 방법으로 엔드포인트 간 균형 있게 로드를 분배하여 각 최종 사용자 로케이션이 지속적으로 동일한 엔드포인트로 라우팅되도록 보장합니다. 지역 DNS는 대륙, 국가, 주라는 세 가지 수준의 지역 단위를 제공합니다. 지역 DNS는 최종 사용자의 로케이션이 사용자가 생성한 특정 지역 DNS 레코드와 일치하지 않은 경우를 위한 글로벌 레코드도 제공합니다. 지연 시간이 짧고 내결함성이 있는 다양한 아키텍처를 위해 지역 DNS를 지연 시간 기반 라우팅, DNS 장애 조치 같은 다른 라우팅 유형과 결합할 수도 있습니다. 다양한 라우팅 유형을 구성하는 방법에 대한 자세한 내용은 Amazon Route 53 설명서를 참조하십시오.

Q: Amazon Route 53의 지역 DNS 기능을 사용하려면 어떻게 해야 합니까?

AWS Management Console 또는 Route 53 API를 사용하여 Amazon Route 53의 새로운 지역 DNS 기능을 빠르고 쉽게 시작할 수 있습니다. 레코드 세트를 생성하고 레코드 세트의 유형에 맞는 값을 지정하고, 해당 레코드 세트를 지역 DNS 사용 레코드 세트로 표시한 다음, 레코드를 적용할 지리적 리전(글로벌, 대륙, 국가 또는 주)을 선택하기만 하면 됩니다. 지역 DNS 사용 방법을 자세히 알아보려면 Amazon Route 53 개발자 안내서를 참조하십시오.

Q: 지역 DNS를 사용할 경우 '글로벌' 레코드가 있어야 합니까? Route 53에서는 언제 이 레코드를 반환합니까?

예. 최종 사용자가 있을 것이라 기대하는 각 대륙, 국가, 주에 대한 특정 레코드를 생성했더라도 Route 53가 사용 가능한 모든 로케이션에서 DNS 쿼리에 응답할 수 있도록 글로벌 레코드를 구성하기를 적극 권장합니다. Route 53에서는 다음과 같은 경우 글로벌 레코드 내 포함된 값을 반환합니다.

  • Route 53의 지역 IP 데이터베이스에서 인식하지 못하는 IP 주소로부터 DNS 쿼리가 수신되는 경우
  • 사용자가 생성한 특정 지역 DNS 레코드에 포함되어 있지 않은 로케이션에서 DNS 쿼리가 수신되는 경우

Q: 하나의 대륙에 대한 지역 DNS 레코드와 해당 대륙 내에 있는 국가에 대한 또 다른 지역 DNS 레코드를 함께 보유할 수 있습니까? 또는 국가에 대한 지역 DNS 레코드와 해당 국가 내 주에 대한 또 다른 지역 DNS 레코드를 함께 보유할 수 있습니까?

예. 중복되는 지리적 리전에 대한 지역 DNS 레코드를 보유할 수 있습니다(예: 대륙에 대한 DNS 레코드와 대륙 내 국가에 대한 DNS 레코드 또는 국가에 대한 DNS 레코드와 해당 국가 내 주에 대한 DNS 레코드). Route 53는 각 최종 사용자 로케이션을 포함하는 가장 명확한 지역 DNS 레코드를 반환합니다. 즉, 각 최종 사용자의 위치에 따라 Route 53는 먼저 주 레코드를 반환합니다. 주 레코드를 찾지 못한 경우 국가 레코드를 반환하고 국가 레코드도 찾지 못한 경우 대륙 레코드를 반환합니다. 마지막으로 대륙 레코드도 없는 경우 글로벌 레코드를 반환하게 됩니다.

Q: Route 53의 지역 DNS 기능 사용 요금은 얼마입니까?

모든 AWS 서비스와 마찬가지로 Amazon Route 53 및 지역 DNS를 사용하기 위한 선결제 금액이나 장기 약정은 없습니다. 실제로 사용한 호스팅 영역과 쿼리에 대해서만 비용을 지불하면 됩니다. 지역 DNS 쿼리 요금에 대한 자세한 내용은 Amazon Route 53 요금 페이지를 참조하십시오.

Q: 지연 시간 기반 라우팅과 지역 DNS의 차이점은 무엇입니까? 

지역 DNS는 요청이 발생한 지리적 위치에 따라 라우팅을 결정합니다. 일부의 경우 지리적 위치가 지연 시간에 대한 좋은 프록시가 되지만 물론 그렇지 않은 경우도 있습니다. 지연 시간 기반 라우팅은 최종 사용자 네트워크와 AWS 데이터 센터 간의 지연 시간 측정값을 활용합니다. 이러한 측정값은 사용자를 어느 엔드포인트로 안내할 것인지 결정하는 데 사용됩니다.

최종 사용자 지연 시간을 최소화하는 것이 목표인 경우에는 지연 시간 기반 라우팅을 사용하는 것이 좋습니다. 그리고 규정 준수, 현지화 요구 사항 또는 특정 지리적 위치에서 특정 엔드포인트까지 안정적인 라우팅이 필요한 사용 사례의 경우에는 지역 DNS를 사용하는 것이 좋습니다.

Q: Amazon Route 53은 DNS 쿼리에 대한 응답에서 여러 개의 값을 지원합니까?

이제 Route 53은 DNS 쿼리에 대한 응답에서 여러 개의 답을 지원합니다. 로드 밸런서를 대체하지는 않지만, DNS 쿼리에 대한 응답에서 여러 개의 상태 확인 가능한 IP 주소를 반환하는 기능은 DNS를 사용하여 가용성과 로드 밸런싱을 개선할 수 있는 방법이 됩니다. 트래픽을 임의로 웹 서버와 같은 여러 리소스로 라우팅하려는 경우, 각 리소스에 대해 하나의 다중값 대답 레코드를 생성하고 Amazon Route 53 상태 확인을 각 레코드에 연결하면 됩니다. Amazon Route 53은 각 DNS 쿼리에 대한 응답에서 최대 8개의 정상 레코드를 지원합니다.


Q: Amazon Route 53 트래픽 흐름이란 무엇입니까?

Amazon Route 53 트래픽 흐름은 사용이 간편하고 비용 효율적인 글로벌 트래픽 관리 서비스입니다. Amazon Route 53 트래픽 흐름에서는 전 세계에 걸쳐 여러 엔드포인트를 실행함으로써 최종 사용자를 위해 애플리케이션의 성능 및 가용성을 향상할 수 있습니다. Amazon Route 53 트래픽 흐름을 사용하면 지연 시간, 지리적 위치 및 엔드포인트 상태를 기반으로 최적의 엔드포인트로 사용자를 연결할 수 있습니다. Amazon Route 53 트래픽 흐름은 지연 시간, 엔드포인트 상태, 로드, 지역 근접성 및 지리적 위치 등 개발자가 가장 중요하게 생각하는 제약 조건을 기준으로 트래픽을 라우팅하는 정책을 손쉽게 생성할 수 있게 해줍니다. 고객은 이러한 템플릿을 사용자 정의하거나 AWS Management Console에서 간단한 시각 정책 작성기를 사용하여 처음부터 정책을 구축할 수 있습니다.

Q: 트래픽 정책과 정책 레코드는 어떻게 다릅니까?

트래픽 정책은 최종 사용자의 요청을 애플리케이션 엔드포인트 중 하나로 라우팅하기 위해 정의한 규칙 집합입니다. 트래픽 정책은 Amazon Route 53 콘솔의 Amazon Route 53 트래픽 흐름 섹션에서 시각 정책 작성기를 사용하여 생성할 수 있습니다. 또한, JSON 형식의 텍스트 파일로 트래픽 정책을 작성하고 Route 53 API, AWS CLI 또는 다양한 AWS SDK를 사용하여 해당 정책을 업로드할 수 있습니다.

트래픽 정책은 애플리케이션의 DNS 이름(예: www.example.com)에 아직 연결되어 있지 않으므로 그 자체로는 최종 사용자가 애플리케이션에 라우팅되는 방법에 영향을 주지 못합니다. 생성한 트래픽 정책을 사용하여 Amazon Route 53 트래픽 흐름에서 트래픽을 애플리케이션으로 라우팅하기 시작하려면, 트래픽 정책을 자체 Amazon Route 53 호스팅 영역 내의 적절한 DNS 이름과 연결하는 정책 레코드를 생성합니다. 예를 들어 my-first-traffic-policy라고 명명한 트래픽 정책을 사용하여 www.example.com에서 애플리케이션의 트래픽을 관리하려는 경우, 호스팅 영역 example.com 내에서 www.example.com에 대한 정책 레코드를 생성하고 my-first-traffic-policy를 트래픽 정책으로 선택합니다.

정책 레코드는 Amazon Route 53 콘솔의 Amazon Route 53 트래픽 흐름과 Amazon Route 53 호스팅 영역 섹션에서 모두 확인할 수 있습니다.

Q. DNS 이름이 하나 이상일 때도 동일한 라우팅 정책을 사용하여 관리할 수 있습니까?

예. 정책을 재사용하여 하나 이상의 DNS 이름을 관리할 수 있으며, 다음과 같은 두 가지 방법 중 하나를 사용하면 됩니다. 첫 번째 방법은 정책을 사용하여 추가 정책 레코드를 생성하는 것입니다. 이 방법을 사용하려면 추가 비용이 발생합니다. 정책 레코드를 생성할 때마다 비용이 청구되기 때문입니다.

두 번째 방법은 정책을 사용하는 하나의 정책 레코드를 생성한 다음, 정책을 사용하여 관리하려는 추가 DNS 이름마다 표준 CNAME 레코드를 생성하는 것입니다. 이때 표준 CNAME 레코드는 생성한 정책 레코드의 DNS 이름을 가리키도록 합니다. 예를 들어 example.com에 대한 정책 레코드를 생성하려는 경우, 각 레코드에 대한 example.com의 CNAME 값을 사용하여 www.example.com, blog.example.comwww.example.net용 DNS 레코드를 각각 생성할 수 있습니다. 이러한 방법은 example.net, example.org 또는 example.co.uk와 같은 Zone Apex(www이 없거나 도메인 이름 앞에 다른 하위 도메인 있는 경우)의 레코드에는 사용할 수 없습니다. Zone Apex의 레코드의 경우, 트래픽 정책을 사용하여 정책 레코드를 생성해야 합니다.

Q: 트래픽 정책에서 관리하는 DNS 이름을 가리키는 별칭 레코드를 생성할 수 있습니까?

아니요. 트래픽 정책에서 관리하고 있는 DNS 이름을 가리키는 별칭 레코드는 생성할 수 없습니다.

Q: 트래픽 정책에 정책 레코드가 없는 경우에도 비용이 청구됩니까?

아니요. 요금은 정책 레코드에 대해서만 부과되며, 트래픽 정책 생성만으로는 요금이 부과되지 않습니다.

Q: Amazon Route 53 트래픽 흐름의 사용료는 어떻게 청구됩니까?

정책 레코드당 요금이 부과됩니다. 정책 레코드는 특정 DNS 이름(예: www.example.com)에 대한 트래픽 흐름 정책의 적용을 나타내며, 트래픽 정책을 사용하여 해당 DNS 이름에 대한 요청이 응답되는 방법을 관리하는 데 필요합니다. 월별로 청구되며, 한 달을 모두 채우지 못한 달에는 비례 할당으로 계산됩니다. 정책 레코드를 통해 DNS 이름과 연결된 트래픽 정책에 대해서는 요금이 부과되지 않습니다. 요금에 대한 세부 정보는 Amazon Route 53 요금 페이지를 참조하십시오.

Q. Amazon Route 53 트래픽 흐름에서 지원되는 고급 쿼리 유형은 무엇입니까?

트래픽 흐름은 지연 시간, 엔드포인트 상태, 다중값 답변, 가중치 기반 라운드 로빈 및 지리적 위치 등 모든 Amazon Route 53 DNS 라우팅 정책을 지원합니다 . 이 밖에도 트래픽 흐름은 트래픽 바이어싱을 이용하여 지역 근접성 기반 라우팅도 지원합니다. 

 Q: 지역 근접성 규칙을 사용하는 트래픽 정책은 DNS 트래픽을 어떻게 라우팅합니까? 

트래픽 흐름 정책을 생성할 때는 AWS 리전(AWS 리소스를 사용하는 경우) 또는 각 엔드포인트의 위도와 경도를 지정할 수 있습니다. 예를 들어 AWS 미국 동부(오하이오) 리전과 미국 서부(오레곤) 리전에 EC2 인스턴스가 있다고 가정하겠습니다. 이때 시애틀의 사용자가 웹사이트를 방문하면 지역 근접성 라우팅이 DNS 쿼리를 미국 서부(오레곤) 리전의 EC2 인스턴스로 라우팅합니다. 지리적으로 더욱 가깝기 때문입니다. 자세한 내용은 지역 근접성에 대한 문서를 참조하십시오. 라우팅.

Q. 엔드포인트의 지역 근접성 바이어스는 다른   앤드포인트에 대한 DNS 트래픽 라우팅에 어떤 영향을 미칩니까?

엔드포인트에 대해 변화하는 지역 근접성 바이어스 값은 다른 엔드포인트에 대해 계산된 거리의 값을 높이거나 낮춥니다. 하지만 바이어스는 부하 요인을 정확히 예측하지 못하고 오히려 영향 범위를 변경합니다. 트래픽 이동량은 엔드포인트의 지리적 영향 범위 내에서 생성되는 쿼리 수에 따라 달라집니다. 자세한 내용은 설명서를 참조하십시오.

 Q. 다른 트래픽 흐름 규칙에 바이어스를 사용할 수 있습니까?

지금부터는 바이어스가 지역 근접성 규칙에만 적용됩니다.


Q: 프라이빗 DNS란 무엇입니까?

Route 53의 기능인 Private DNS를 사용하면 리소스 이름 및 리소스 IP 주소와 같은 DNS 레코드를 인터넷에 공개하지 않아도 VPC 내에 신뢰할 수 있는 DNS를 설정할 수 있습니다.

Q: Amazon Route 53을 사용하여 조직의 프라이빗 IP 주소를 관리할 수 있습니까?

예, Amazon Route 53의 프라이빗 DNS 기능을 사용하면 Virtual Private Cloud(VPC) 내에서 프라이빗 IP 주소를 관리할 수 있습니다. 이 기능을 통해 사용자는 프라이빗 호스팅 영역을 생성할 수 있으며, Route 53는 사용자가 프라이빗 호스팅 영역과 연결한 VPC 내에서 쿼리가 발생할 경우에만 이 레코드를 반환합니다. 자세한 내용은 Amazon Route 53 설명서를 참조하십시오.

Q: 어떻게 하면 프라이빗 DNS를 설정할 수 있습니까?

Route 53에 호스팅 영역을 생성하여 호스팅 영역을 '프라이빗'으로 지정하는 옵션을 선택하고 VPC 중 하나와 호스팅 영역을 연결하면 프라이빗 DNS를 설정할 수 있습니다. 호스팅 영역을 생성한 후에는 추가적으로 다른 VPC와 연결할 수 있습니다. 자세한 프라이빗 DNS 구성 방법은 Amazon Route 53 설명서를 참조하십시오.

Q: 프라이빗 DNS를 사용하려면 외부 인터넷 연결이 필요합니까?

인터넷에 연결되지 않은 VPC 내의 리소스에서 내부 DNS 이름을 확인할 수 있습니다. 하지만 프라이빗 DNS 호스팅 영역에 대한 구성을 업데이트하려면 인터넷에 연결하여 VPC 외부에 있는 Route 53 API 엔드포인트에 액세스해야 합니다.

Q: VPC를 사용하지 않아도 프라이빗 DNS를 사용할 수 있습니까?

아니요. Route 53 프라이빗 DNS는 VPC를 사용해 프라이빗 DNS 호스팅 영역에 대한 DNS 확인을 제공하고 가시성을 관리합니다. Route 53 프라이빗 DNS의 이점을 활용하려면 VPC를 구성하여 리소스를 해당 VPC로 마이그레이션해야 합니다.

Q: 여러 개의 VPC에서 동일한 프라이빗 Route 53 호스팅 영역을 사용할 수 있습니까?

예, 하나의 호스팅 영역에 여러 개의 VPC를 연결할 수 있습니다. 

Q: 서로 다른 AWS 계정으로 생성한 VPC와 프라이빗 호스팅 영역을 연결할 수 있습니까?

예. 다른 계정에 속한 VPC를 단일 호스팅 영역에 연결할 수 있습니다. 자세한 내용은 여기를 참조하십시오.

Q: 프라이빗 DNS가 다른 AWS 리전에서도 작동됩니까?

예. DNS 응답은 프라이빗 호스팅 영역에 연결된 각각의 VPC 내에 존재합니다. 단, 각 리전의 VPC들이 서로 연결되어 있어야만 한 리전의 리소스가 다른 리전의 리소스에 도달할 수 있다는 점에 유의하십시오. Route 53 프라이빗 DNS는 현재 미국 동부(버지니아 북부), 미국 서부(캘리포니아 북부), 미국 서부(오레곤), 아시아 태평양(뭄바이), 아시아 태평양(서울), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), EU(프랑크푸르트), EU(아일랜드) 및 남아메리카(상파울루) 리전에서 지원됩니다.

Q: 프라이빗 DNS 호스팅 영역에 대한 DNS 장애 조치를 구성할 수 있습니까?

예. 상태 확인을 프라이빗 DNS 호스팅 영역 내 리소스 레코드 세트와 연결함으로써 DNS 장애 조치를 구성할 수 있습니다. 엔드포인트가 Virtual Private Cloud(VPC) 내에 있는 경우, 몇 가지 옵션을 사용하여 해당 엔드포인트에 대한 상태 확인을 구성할 수 있습니다. 엔드포인트에 퍼블릭 IP 주소가 있는 경우, 각 엔드포인트의 퍼블릭 IP 주소에 대한 표준 상태 확인을 생성할 수 있습니다. 엔드포인트에 프라이빗 IP 주소만 있는 경우에는 해당 엔드포인트에 대한 표준 상태 확인을 생성할 수 없습니다. 하지만 지표 기반 상태 확인을 생성할 수 있습니다. 이 경우 외부 위치에서 엔드포인트에 대한 요청을 하는 대신 Amazon CloudWatch 지표를 엔드포인트 상태 정보의 소스로 사용한다는 점이 다르며, 그 외에는 표준 Amazon Route 53 상태 확인과 동일하게 작동합니다.

Q: 프라이빗 DNS를 사용해 내 VPC 안에서 접근을 원치 않는 도메인과 DNS 이름을 차단할 수 있습니까?

예, 도메인과 특정 DNS 이름을 차단하려면 하나 이상의 프라이빗 DNS 호스팅 영역에 해당 이름을 생성하고, 이 이름이 사용자 자체 서버 (또는 사용자가 관리하는 다른 장소)를 가리키게 하면 됩니다.


Q: DNS 장애 조치는 무엇입니까?

DNS 장애 조치는 상태 확인 및 장애 조치라는 두 가지 구성 요소로 이루어져 있습니다. 상태 확인은 인터넷을 통해 애플리케이션에 자동화된 요청을 보내 애플리케이션이 연결되어 사용 가능하며 정상적으로 작동되는지 확인합니다. 사용자가 수행하는 일반 요청과 유사하게 특정 URL에서 웹 페이지를 요청하는 것처럼 상태 확인을 구성할 수 있습니다. Route 53는 DNS 장애 조치를 사용하여 상태가 양호하고 외부에서 도달할 수 있는 리소스에 대해서만 응답을 반환하므로 오류가 발생했거나 상태가 양호하지 않은 애플리케이션에서는 최종 사용자가 라우팅되지 않습니다.

Q: DNS 장애 조치를 시작하려면 어떻게 해야 합니까?

시작 세부 정보는 Amazon Route 53 Developer Guide를 참조하십시오. 또한 Route 53 Console에서 DNS 장애 조치를 구성할 수 있습니다.

Q: DNS 장애 조치가 엔드포인트로 Elastic Load Balancer(ELB)를 지원합니까?

예, Elastic Load Balancer(ELB)에 대해 DNS 장애 조치를 구성할 수 있습니다. ELB 엔드포인트에 대해 DNS 장애 조치를 활성화하려면 ELB를 가리키는 별칭 레코드를 생성하고 'Evaluate Target Health' 파라미터를 true로 설정합니다. Route 53은 ELB에 대한 상태 확인을 자동으로 생성하고 관리합니다. ELB에 대해 자체 Route 53 상태 확인을 만들 필요가 없습니다. Route 53이 사용자를 대신하여 관리하는 상태 확인과 ELB에 대한 리소스 레코드 세트를 자동 연결하므로 리소스 레코드 세트도 자체 상태 확인과 연결할 필요가 없습니다. 또한 ELB 상태 확인은 ELB에서 사용되는 백엔드 인스턴스의 상태를 상속합니다. ELB 엔드포인트를 사용한 DNS 장애 조치에 대한 자세한 내용은 Route 53 Developer Guide를 참조하십시오.

Q: 상태 확인이 실패할 때만 사용되는 백업 사이트를 구성할 수 있습니까?

예. DNS 장애 조치를 사용하여 백업 사이트(예: Amazon S3 웹 사이트 버킷에서 실행 중인 정적 사이트)를 관리하고 기본 사이트에 접속할 수 없는 이벤트가 발생했을 때 이 사이트로 장애 조치를 할 수 있습니다.

Q: 어떤 DNS 레코드 유형을 Route 53 상태 확인과 연결할 수 있습니까?

Route 53에서 지원하는 모든 레코드 유형(SOA 및 NS 레코드 제외)을 연결할 수 있습니다.

Q: IP 주소를 모르는 경우에도 엔드포인트의 상태를 확인할 수 있습니까?

예. 자체 상태 확인을 만들지 않아도 Amazon Route 53 콘솔을 통해 Elastic Load Balancer 및 Amazon S3 웹 사이트 버킷을 위한 DNS 장애 조치를 구성할 수 있습니다. 이러한 엔드포인트 유형의 경우, 사용자가 ELB 또는 S3 웹 사이트 버킷을 가리키는 별칭 레코드를 생성하고 별칭 레코드에 'Evaluate Target Health' 파라미터를 활성화할 때 사용되는 상태 확인을 Route 53에서 사용자 대신 자동으로 생성하고 관리합니다.

다른 모든 엔드포인트의 경우 사용자가 해당 엔드포인트의 상태 확인을 생성할 때 DNS 이름(예: www.example.com) 또는 엔드포인트의 IP 주소를 지정할 수 있습니다.

Q: 엔드포인트 중 하나가 AWS 외부에 있습니다. 이 엔드포인트에 DNS 장애 조치를 설정할 수 있습니까?

예. AWS 외부에 있는 주소를 가리키는 Route 53 리소스 레코드를 만들 수 있는 것처럼 AWS 외부에서 실행 중인 애플리케이션의 일부에 대해 상태 확인을 설정할 수 있고 위치에 상관없이 선택한 엔드포인트로 장애 조치를 할 수 있습니다. 예를 들어 AWS 외부의 데이터센터에서 실행 중인 기존 애플리케이션과 AWS 내부에서 실행 중인 해당 애플리케이션의 백업 인스턴스를 보유할 수 있습니다. AWS 외부에서 실행 중인 기존 애플리케이션의 상태 확인을 설정할 수 있고 애플리케이션의 상태 확인이 실패할 경우 자동으로 AWS 내의 백업 인스턴스로 장애 조치를 할 수 있습니다.

Q: 장애 조치가 발생하고 상태가 양호한 엔드포인트가 여러 개 남아 있는 경우, Route 53가 실패한 엔드포인트에서 트래픽을 보낼 위치를 결정할 때 상태가 양호한 엔드포인트 로드를 고려합니까?

아니요, Route 53는 엔드포인트의 로드나 사용 가능한 트래픽 용량을 기준으로 라우팅을 결정하지는 않습니다. 실패한 엔드포인트로 보내진 트래픽을 처리하려면 다른 엔드포인트에 사용 가능한 용량이 있는지 또는 해당 엔드포인트에 확장 기능이 있는지 확인해야 합니다.

Q: 엔드포인트가 "실패"한 상태로 간주되려면 상태 확인 관찰이 연속 몇 번 실패해야 합니까?

기본 임계값은 세 번의 상태 확인 관찰입니다. 엔드포인트가 세 번 연속으로 관찰에 실패하는 경우 Route 53는 이를 실패로 간주합니다. 하지만 Route 53는 계속해서 엔드포인트의 상태 확인 관찰을 수행하여 엔드포인트에 관찰이 세 번 연속 전달되면 트래픽을 다시 전송합니다. 관찰에 대한 이러한 임계값을 1~10 사이 중 원하는 값으로 변경할 수 있습니다. 자세한 내용은 Amazon Route 53 개발자 안내서를 참조하십시오.

Q: 실패한 엔드포인트가 다시 양호한 상태가 되면 어떻게 DNS 장애 조치가 취소됩니까?

실패한 엔드포인트가 상태 확인을 생성할 때 사용자가 지정한 상태 확인 관찰 횟수(기본 임계값은 관찰 3회)를 통과하면 Route 53는 해당 DNS 레코드를 자동으로 복원하며 해당 엔드포인트로의 트래픽이 재개됩니다. 이때 사용자가 수행해야 할 작업은 없습니다.

Q: 상태 확인 관찰 간격은 얼마나 됩니까?

기본적으로 상태 확인 관찰은 30초 간격으로 수행됩니다. 관찰 간격을 이보다 빠른 10초로 선택할 수 있는 옵션도 있습니다.

3배 더 많이 수행되는 빠른 간격 상태 확인을 통해 Route 53는 엔드포인트가 실패했는지 더욱 신속하게 확인할 수 있으므로, 엔드포인트의 실패에 응답하는 트래픽을 리디렉션하여 DNS 장애 조치에 필요한 시간을 줄입니다.

빠른 간격 상태 확인은 엔드포인트로 3배 더 많은 요청을 생성합니다. 그러므로 엔드포인트에 웹 트래픽을 처리할 용량이 제한되어 있는지 고려해야 할 수 있습니다. 빠른 간격 상태 확인 및 기타 상태 확인 기능 옵션의 요금에 대한 세부 정보는 Route 53 요금 페이지를 방문하십시오. 자세한 내용은 Amazon Route 53 개발자 안내서를 참조하십시오.

Q: 내 엔드포인트(예: 웹 서버)의 부하가 어느 정도여야 상태 확인이 생성됩니까?

각 상태 확인은 전 세계 여러 지역에서 수행됩니다. 위치의 수와 세트는 구성 가능합니다. Amazon Route 53 콘솔이나 API를 사용하여 각 상태 확인이 수행되는 위치의 수를 변경할 수 있습니다. 각 위치에서는 개별적으로 사용자가 선택한 간격에 따라 엔드포인트를 확인합니다. 기본 간격은 30초이며 옵션으로 선택할 수 있는 빠른 간격은 10초입니다. 현재 상태 확인을 수행 중인 위치의 기본 수에 따라 엔드포인트에 수신되는 요청 수가 달라집니다. 표준 간격의 상태 확인의 경우 2~3초마다 1개의 요청이 수신되며, 빠른 간격의 상태 확인의 경우 초당 1개 이상의 요청이 수신됩니다.

Q: Route 53에서는 HTTP 리디렉션 후 상태 확인을 합니까?

아니요. Route 53 상태 확인은 HTTP 3xx 코드를 정상적인 응답으로 간주하기 때문에 리디렉션 후 다시 상태 확인이 이루어지지 않습니다. 이로 인해 문자열 일치 상태 확인 시 예기치 않은 결과가 초래될 수 있습니다. 상태 확인은 리디렉션 본문에서 지정된 문자열을 찾습니다. 리디렉션 후 상태 확인이 이루어지지 않으므로, 리디렉션 위치로 전송되는 요청이 없으며 해당 위치로부터의 응답 또한 없습니다. 그러므로 문자열 일치 상태 확인의 경우 HTTP 리디렉션을 반환하는 위치의 상태 확인을 지정하지 않는 것이 좋습니다.

Q: 어떤 이벤트 순서로 장애 조치가 발생합니까?

간단히 설명하면 상태 확인에 실패하여 장애 조치가 수행되는 경우 다음 이벤트가 발생합니다.

  1. Route 53는 애플리케이션의 상태 확인을 수행합니다. 이 예에서 애플리케이션이 3회 연속으로 상태 확인에 실패하면 다음 이벤트가 트리거됩니다.
  2. Route 53는 실패한 엔드포인트의 리소스 레코드를 비활성화하고 더 이상 해당 레코드를 제공하지 않습니다. 이 장애 조치 단계에서 실패한 엔드포인트 대신 상태가 양호한 엔드포인트로 트래픽을 라우팅하기 시작합니다.

Q: DNS 장애 조치를 사용하려면 내 레코드의 TTL을 조정해야 합니까?

DNS 확인자가 응답을 캐시하는 시간은 레코드마다 TTL이라는 값에 의해 설정됩니다. DNS 장애 조치를 사용할 때, 실패한 엔드포인트로의 트래픽 라우팅이 중단될 때까지 소요되는 시간을 최소화하기 위해 TTL을 60초 이하로 조정하는 것이 좋습니다. ELB 및 S3 웹 사이트 끝점에 대해 DNS 장애 조치를 구성하려면 고정 TTL이 60초인 별칭 레코드를 사용해야 합니다. 이러한 엔드포인트 유형의 경우 TTL을 조정하지 않고도 DNS 장애 조치를 사용할 수 있습니다.

Q: 모든 엔드포인트의 상태가 양호하지 않은 경우 어떻게 됩니까?

Route 53는 상태가 양호한 엔드포인트로만 장애 조치를 할 수 있습니다. 리소스 레코드에 상태가 양호하지 않은 엔드포인트가 남아 있는 경우 Route 53는 모든 상태 확인이 통과된 것처럼 동작합니다.

Q: LBR(지연 시간 기반 라우팅)을 사용하지 않고 DNS 장애 조치를 사용할 수 있습니까?

예. LBR을 사용하지 않고 DNS 장애 조치를 구성할 수 있습니다. 특히 DNS 장애 조치를 사용하여, Route 53가 기본 웹 사이트를 모니터링하고 기본 사이트를 사용할 수 없는 이벤트가 발생하는 경우 백업 사이트로 장애 조치되는 간단한 장애 조치 시나리오를 구성할 수 있습니다.

Q: HTTPS를 통해서만 접근할 수 있는 사이트에 상태 확인을 구성할 수 있습니까?

예. Route 53는 HTTPS, HTTP 또는 TCP를 통한 상태 확인 기능을 지원합니다.

Q: HTTPS 상태 확인은 엔드포인트의 SSL 인증서에 대한 유효성을 확인합니까?

아니요. HTTPS 상태 확인은 SSL을 통해 엔드포인트와 연결할 수 있는지, 엔드포인트가 유효한 HTTP 응답 코드를 반환할 수 있는지를 테스트합니다. 그러나 엔드포인트에서 반환되는 SSL 인증서의 유효성을 확인하지는 않습니다.

Q: HTTPS 상태 확인은 SNI(서버 이름 표시)를 지원합니까?

예. HTTPS 상태 확인에서는 SNI를 지원합니다.

Q: 상태 확인 기능을 사용해 내 웹 서버가 올바른 콘텐츠를 반환하고 있는지 확인하려면 어떻게 해야 합니까?

Route 53에서 "Enable String Matching" 옵션을 선택하면 상태 확인 기능을 통해 지정된 문자열이 서버 응답에 포함되어 있는지 확인할 수 있습니다. 이 옵션은 웹 서버가 제공하는 HTML에 원래 있어야 하는 문자열이 포함되어 있는지 확인하는 데 사용할 수 있습니다. 또는, 전용 상태 페이지를 만들어 내부적인 관점 또는 운영적인 관점에서 서버의 상태를 확인하는 데 사용할 수 있습니다. 자세한 내용은 Amazon Route 53 Developer Guide를 참조하십시오.

Q: 내가 생성한 상태 확인 상태를 보려면 어떻게 해야 합니까?

상태 확인의 현재 상태 및 장애 원인에 대한 세부 정보는 Amazon Route 53 콘솔에서 확인하거나 Route 53 API를 사용하여 확인할 수 있습니다.

또한, 각 상태 확인 결과는 Amazon CloudWatch 지표로 게시되어 엔드포인트의 상태를 보여줍니다. 엔드포인트의 응답 지연 시간을 표시하도록 선택할 수도 있습니다. Amazon Route 53 콘솔의 health checks 탭에서 Amazon CloudWatch 지표 그래프를 보면 현재 및 이전 상태 확인의 상황을 알 수 있습니다. 아울러 상태 확인 상황에 변동이 발생하는 경우 알림을 보내도록 측정 지표에 Amazon CloudWatch 경보를 생성할 수도 있습니다.

모든 Amazon Route 53 상태 확인에 대한 Amazon CloudWatch 지표는 Amazon CloudWatch 콘솔에서도 볼 수 있습니다. 각 Amazon CloudWatch 지표에는 상태 확인 ID가 포함되며(예: 01beb6a3-e1c2-4a2b-a0b7-7031e9060a6a), 이를 사용해 지표가 어떤 상태 확인을 추적 중인지 확인할 수 있습니다.

Q: Amazon Route 53을 사용하여 애플리케이션 엔드포인트의 성능을 측정하려면 어떻게 해야 합니까?

Amazon Route 53 상태 확인에는 선택 사항으로 지연 시간 측정 기능이 포함되어 있어 엔드포인트가 요청에 응답하는 데 걸리는 시간에 대한 데이터를 제공할 수 있습니다. 지연 시간 측정 기능을 활성화하면, Amazon Route 53 상태 확인에서 추가 Amazon CloudWatch 지표를 생성합니다. 이 지표는 Amazon Route 53의 상태 확인 프로그램이 연결을 구성하고 데이터를 수신하기 시작하는 데 필요한 시간을 보여줍니다. Amazon Route 53은 Amazon Route 53 상태 확인이 수행되는 AWS 리전별로 별도의 지연 시간 지표 세트를 제공합니다.

Q: 엔드포인트 중 하나의 상태 확인에 실패하는 경우 어떻게 알림을 받을 수 있습니까?

각 Route 53 상태 확인이 진단 결과를 CloudWatch 지표로 게시하므로 사용자가 지정한 임계값 밖으로 상태 확인 값이 변경될 때 트리거할 수 있는 모든 범위의 CloudWatch 알림과 자동 동작 기능을 구성할 수 있습니다. 우선 Route 53나 CloudWatch 콘솔에서 해당 상태 확인 지표의 CloudWatch 경보를 구성합니다. 그런 다음 알림 동작을 추가하고 알림을 게시할 이메일이나 SNS 주제를 지정합니다. 완전한 설명은 Route 53 Developer Guide를 참조하십시오.

Q: 상태 확인에 대한 경보를 생성했으나 경보의 SNS 주제에 대한 확인 이메일을 다시 전송해야 합니다. 이 이메일을 다시 전송하려면 어떻게 해야 합니까?

확인 이메일은 SNS 콘솔에서 다시 전송할 수 있습니다. 해당 경보와 연관된 SNS 주제 이름을 찾으려면 Route 53 콘솔에서 경보 이름을 클릭한 다음 "Send notification to"라는 레이블이 지정된 상자에서 찾으십시오.

SNS 콘솔에서 주제 목록을 확장한 다음, 경보에서 주제를 선택합니다. "Create Subscription" 상자를 연 다음 프로토콜에 대한 이메일을 선택하고 원하는 이메일 주소를 입력합니다. "Subscribe"를 클릭하면 확인 이메일이 다시 전송됩니다.

Q: DNS 장애 조치를 Elastic Load Balancer(ELB)의 엔드포인트로 사용하고 있습니다. 이 엔드포인트의 상태는 어떻게 볼 수 있나요?

ELB 엔드포인트를 사용하여 DNS 장애 조치를 설정하는 경우 권장되는 방법은 별칭 레코드에 'Evaluate Target Health' 옵션을 함께 사용하는 것입니다. 이 옵션을 사용하면 ELB 엔드포인트에 대해 자체 상태 확인을 만들지 않으므로 이러한 엔드포인트에 대해서는 Route 53에서 구체적인 CloudWatch 측정치는 생성하지 않습니다.

로드 밸런서의 상태에 대한 측정치는 다음 두 가지 방법으로 얻을 수 있습니다. 첫 번째로, Elastic Load Balancing은 로드 밸런서의 상태와 그 이면의 정상 인스턴스 수를 나타내는 측정치를 표시합니다. ELB의 CloudWatch 지표를 구성하는 방법에 관한 자세한 정보를 확인하려면 ELB 개발자 안내서를 참조하십시오. 두 번째로, ELB에서 제공하는 CNAME에 대해 자체 상태 확인을 만들 수 있습니다(예: elb-example-123456678.us-west-2.elb.amazonaws.com). 'Evaluate Target Health' 옵션을 사용하면 DNS 장애 조치가 제공되므로 이 상태 확인을 DNS 장애 조치 자체에 사용할 수는 없지만, 이 상태 확인의 CloudWatch 측정치를 확인하여 상태 확인 실패 시 알림을 보내는 경보를 생성할 수 있습니다.

ELB 엔드포인트에서 DNS 장애 조치 사용에 대한 자세한 내용은 Route 53 Developer Guide를 참조하십시오.

Q: 별칭 레코드가 Amazon S3 웹 사이트 버킷을 가리키는 경우, Evaluate Target Health 값을 "true"로 설정 시 상태를 확인하는 대상은 무엇입니까?

Amazon Route 53은 각 AWS 리전의 Amazon S3 서비스 자체에 대한 상태 확인을 수행합니다. Amazon S3 웹 사이트 버킷을 가리키는 별칭 레코드의 Evaluate Target Health를 활성화한 경우, Amazon Route 53은 버킷이 위치한 AWS 리전의 Amazon S3 서비스의 상태를 확인합니다. Amazon Route 53은 특정 버킷이 존재하는지 또는 유효한 웹 사이트 콘텐츠를 포함하는지는 확인하지 않습니다. Amazon Route 53은 버킷이 위치한 AWS 리전에서 Amazon S3 서비스 자체를 사용할 수 없는 경우에 다른 위치로 장애 조치를 수행할 뿐입니다.

Q: Route 53 상태 확인의 CloudWatch 지표를 사용하는 데 드는 비용은 얼마나 됩니까?

Route 53 상태 확인의 CloudWatch 지표는 무료로 제공됩니다.

Q: CPU 로드, 네트워크 또는 메모리와 같은 내부 상태 지표를 기반으로 DNS 장애 조치를 구성할 수 있습니까?

예. Amazon Route 53의 지표 기반 상태 확인을 사용하면 Amazon CloudWatch에서 제공되는 지표(AWS 제공 지표와 자체 애플리케이션의 사용자 정의 지표 포함)를 기반으로 DNS 장애 조치를 수행할 수 있습니다. Amazon Route 53 내에 지표 기반 상태 확인을 생성하면, 이와 연결된 Amazon CloudWatch 지표가 경보 상태가 될 때마다 상태 확인이 비정상으로 변합니다.

지표 기반 상태 확인은 프라이빗 IP 주소만 있는 Virtual Private Cloud(VPC) 내 인스턴스와 같이 표준 Amazon Route 53 상태 확인으로는 접근할 수 없는 엔드포인트에 대한 DNS 장애 조치를 활성화하는 데 유용합니다. Amazon Route 53의 계산된 상태 확인 기능을 사용하면, 지표 기반 상태 확인의 결과와 전 세계의 상태 확인 프로그램 네트워크에서 엔드포인트에 대한 요청을 하는 표준 Amazon Route 53 상태 확인의 결과를 조합하여 좀 더 정교한 장애 조치 시나리오를 실현할 수 있습니다. 예를 들어 퍼블릭 웹 페이지를 사용할 수 없거나, CPU 로드, 네트워크 수신/송신, 디스크 읽기 등과 같은 내부 지표가 서버 자체가 비정상임을 보여주는 경우, 엔드포인트가 장애 조치되도록 구성을 생성할 수 있습니다.

Q: 웹 서버가 Route 53 상태 확인에서 내가 생성하지 않은 요청을 수신하고 있습니다. 이러한 요청을 중지시키려면 어떻게 해야 합니까?

가끔 Amazon Route 53 고객이 본인과 관련 없는 IP 주소 또는 도메인 이름을 지정하여 상태 확인을 생성할 때가 있습니다. 웹 서버에서 원하지 않는 HTTP 요청을 수신하고 있으며 Amazon Route 53 상태 확인까지 이를 추적한 경우 이 양식을 사용하여 원하지 않는 상태 확인에 대한 정보를 제공해주시면, 고객과 협력하여 문제를 해결하도록 하겠습니다.

Q: 도메인 이름을 내 상태 확인 대상으로 지정하면 Amazon Route 53에서 확인할 때 IPv4 또는 IPv6 중 어느 것을 사용합니까?

도메인 이름을 Amazon Route 53 상태 확인의 엔드포인트로 지정하면 Amazon Route 53에서 해당 도메인 이름의 IPv4 주소를 조회하고 IPv4를 사용하여 엔드포인트에 연결합니다. Amazon Route 53은 도메인 이름으로 지정된 엔드포인트에 대해서는 IPv6 주소를 조회하지 않습니다. IPv4 대신 IPv6를 통해 상태 확인을 수행하려는 경우 "domain name"이 아니라 "IP address"를 엔드포인트 유형으로 선택하고 "IP address" 필드에 IPv6 주소를 입력하십시오.

Q: Amazon Route 53의 DNS 서버 및 상태 확인 프로그램용 IPv6 주소 범위는 어디에서 확인할 수 있습니까?

이제 AWS에서는 현재 IP 주소 범위를 JSON 형식으로 게시합니다. 현재 범위를 보려면 다음 링크를 사용해 .json 파일을 다운로드하십시오. 이 파일에 프로그래밍 방식으로 액세스하는 경우 애플리케이션이 AWS 서버에서 반환하는 TLS 인증서를 성공적으로 확인한 후에 파일을 다운로드해야 합니다.

다운로드: ip-ranges.json

Route 53 서버용 IP 범위를 찾으려면 "service" 필드에서 다음 값을 검색하십시오.

  • Route 53 DNS 서버: "ROUTE53" 검색
  • Route 53 DNS 상태 확인 프로그램: "ROUTE53_HEALTHCHECKS" 검색

자세한 내용은 Amazon Web Services General Reference에서 AWS IP Address Ranges를 참조하십시오.

IPv6 범위는 이 파일에 없을 수도 있습니다. 참고로 Amazon Route 53 상태 확인 프로그램용 IP 범위는 다음과 같습니다.

2600:1f1c:7ff:f800::/53
2a05:d018:fff:f800::/53
2600:1f1e:7ff:f800::/53
2600:1f1c:fff:f800::/53
2600:1f18:3fff:f800::/53
2600:1f14:7ff:f800::/53
2600:1f14:fff:f800::/53
2406:da14:7ff:f800::/53
2406:da14:fff:f800::/53
2406:da18:7ff:f800::/53
2406:da1c:7ff:f800::/53
2406:da1c:fff:f800::/53
2406:da18:fff:f800::/53
2600:1f18:7fff:f800::/53
2a05:d018:7ff:f800::/53
2600:1f1e:fff:f800::/53
2620:107:300f::36b7:ff80/122
2a01:578:3::36e4:1000/122
2804:800:ff00::36e8:2840/122
2620:107:300f::36f1:2040/122
2406:da00:ff00::36f3:1fc0/122
2620:108:700f::36f4:34c0/122
2620:108:700f::36f5:a800/122
2400:6700:ff00::36f8:dc00/122
2400:6700:ff00::36fa:fdc0/122
2400:6500:ff00::36fb:1f80/122
2403:b300:ff00::36fc:4f80/122
2403:b300:ff00::36fc:fec0/122
2400:6500:ff00::36ff:fec0/122
2406:da00:ff00::6b17:ff00/122
2a01:578:3::b022:9fc0/122
2804:800:ff00::b147:cf80/122


Q: 도메인 이름을 Amazon Route 53에 등록할 수 있습니까?

예. AWS Management Console 또는 API를 사용하여 Route 53에서 새로운 도메인 이름을 등록할 수 있습니다. 다른 등록 기관의 기존 도메인 이름을 전송하여 Route 53에서 관리하도록 요청할 수도 있습니다. 도메인 이름 등록 서비스는 Amazon의 도메인 이름 등록 계약이 적용됩니다.

Q: Amazon에서는 어떤 최상위 도메인(TLD)을 제공합니까?

Route 53는 일반적인 최상위 도메인('gTLD': 예를 들면 example.com 및 .net)과 국가 코드 최상위 도메인('ccTLD': 예를 들면 .de와 .fr) 모두에 대한 광범위한 선택 사항을 제공합니다. 전체 목록을 보려면 Route 53 도메인 등록 요금 목록을 참조하십시오.

Q: Route 53로 도메인 이름을 등록하려면 어떻게 해야 합니까?

시작하려면 계정에 로그인한 다음 'Domains'를 클릭합니다. 그런 다음 커다랗고 파란 'Register Domain' 버튼을 클릭하여 등록 절차를 완료합니다.

Q: 도메인 이름을 등록하는 데는 얼마나 걸립니까?

선택한 TLD에 따라 등록은 몇 분에서 몇 시간까지 소요될 수 있습니다. 도메인이 등록되면 계정에 표시됩니다.

Q: 도메인 이름 등록 기간은 어떻게 됩니까?

일부 최상위 도메인(TLD) 등록 기관의 등록 기간은 더 길지만, 첫 등록 기간은 보통 1년입니다. Amazon Route 53에 도메인을 등록하거나 도메인 등록을 Amazon Route 53으로 이전할 때 도메인이 자동 갱신되도록 구성합니다. 더 자세한 내용은 Amazon Route 53 Developer Guide의 도메인 등록 갱신을 참조하십시오.

Q: 도메인 이름을 등록하기 위해 제공해야 하는 정보는 무엇입니까?

도메인 이름을 등록하려면 이름, 주소, 전화번호, 이메일 번호를 비롯해 등록자에 대한 연락처 정보를 제공해야 합니다. 관리 문의처와 기술 문의처가 다른 경우 각각의 연락처 정보도 제공해 주셔야 합니다.

Q: 도메인을 등록하기 위해 개인 정보를 제공해야 하는 이유는 무엇입니까?

도메인 등록을 관리하는 조직인 ICANN에서는 모든 도메인 이름 등록에 대해 등록 기관이 이름, 주소, 전화번호를 비롯한 연락처 정보를 제공하고 이러한 정보를 Whois 데이터베이스를 통해 공개하도록 요구합니다. 개인으로 등록하는 도메인 이름의 경우(예: 회사 또는 조직이 아님) 개인 전화번호, 이메일 주소, 실제 주소를 볼 수 없도록 하는 개인 정보 보호를 Route 53에서 무료로 제공합니다. 하지만 Whois에는 등록 기관의 이름과 우편 주소와 함께 등록 기관에서 생성한 전달 이메일 주소가 포함되어 있어 타사에서 이를 사용해 사용자에게 연락할 수도 있습니다.

Q: Route 53은 내가 등록한 도메인 이름에 대한 개인 정보 보호를 제공합니까?

예. Route 53은 추가 요금 없이 개인 정보 보호를 제공합니다. 개인 정보 보호 기능은 등록자의 전화번호, 이메일 주소 및 물리적 주소를 숨깁니다. TLD 등록 및 등록 기관에서 허용하는 경우, 성과 이름도 숨기게 됩니다. 개인 정보 보호를 활성화하면, 도메인용 Whois 쿼리는 등록자의 물리적 주소 대신 등록 기관의 이메일 주소를 그리고 등록자의 이름 대신 등록 기관의 이름을 포함하게 됩니다(허용되는 경우). 등록자의 이메일 주소는 등록 기관에서 생성한 전달 이메일 주소로 대체되어 타사에서 이를 사용해 등록자에게 연락할 수도 있습니다. TLD 등록 및 등록 기관에서 허용하는 경우, 기업 또는 조직에서 등록한 도메인 이름도 개인 정보 보호의 대상이 됩니다.

Q: 특정 TLD에 대한 요구 사항은 어디에서 찾아볼 수 있습니까?

TLD 목록은 요금 목록을 참조하십시오. 각 TLD에 대한 특정 등록 요구 사항은 Amazon Route 53 Developer Guide와 Amazon의 도메인 이름 등록 계약을 참조하십시오.

Q: 도메인 이름을 등록하는 데 사용되는 이름 서버는 무엇입니까?

도메인 이름이 생성되면 Amazon에서는 위임 세트로 알려진 네 개의 고유 Route 53 이름 서버로 해당 도메인을 자동으로 연결합니다. 도메인에 대한 위임 세트는 Amazon Route 53 콘솔에서 확인할 수 있습니다. 해당 위임 세트는 사용자가 도메인을 등록할 때 Amazon에서 자동으로 생성한 호스팅 영역에 나열되어 있습니다.

Route 53는 생성한 호스팅 영역별로 서로 다른 새로운 위임 세트를 할당하도록 기본 설정되어 있습니다. '재사용이 가능한 위임 세트'는 Route 53 API를 사용해서도 생성이 가능하며, 사용자가 생성한 여러 개의 호스팅 영역에 적용할 수 있습니다. 도메인 이름이 많은 고객의 경우, 재사용이 가능한 위임 세트를 사용하면 도메인 이름 등록업체에게 Route 53에서 관리하는 모든 도메인에 대해 동일한 위임 세트를 사용하라고 지시할 수 있으므로 Route 53로 간단하게 마이그레이션할 수 있습니다. 이 기능을 사용하면 ns1.example.com, ns2.example.com 등의 '화이트 레이블' 이름 서버 주소를 생성하여 Route 53 이름 서버로 연결되도록 할 수 있습니다. 그런 다음에는 수에 상관없이 도메인 이름에 대해 '화이트 레이블' 이름 서버 주소를 신뢰할 수 있는 이름 서버로 사용할 수 있습니다. 자세한 내용은 Amazon Route 53 설명서를 참조하십시오.

Q: 이름 서버에 대한 비용이 청구됩니까?

도메인 이름에 대해 Route 53가 생성한 호스팅 영역과 이 호스팅 영역에 대해 Route 53가 대신 처리한 DNS 쿼리에 대한 요금이 청구됩니다. Route 53의 DNS 서비스에 대한 요금 청구를 원하지 않는 경우 Route 53 호스팅 영역을 삭제할 수 있습니다. 일부 TLD는 도메인 이름 등록의 일환으로 유효한 이름 서버를 보유하도록 요청할 수 있다는 점에 유의하십시오. 이러한 TLD에 포함된 도메인 이름의 경우 다른 공급자를 통해 DNS 서비스를 조달하고, 해당 공급자의 이름 서버 주소를 입력해야 해당 도메인 이름에 대한 Route 53 호스팅 영역을 안전하게 삭제할 수 있습니다.

Q: Amazon Registrar, Inc.는 무엇이며 등록 대행자란 무엇입니까?

AWS는 ICANN 인증 등록 기관에 등록된 도메인 이름을 재판매하고 있습니다. Amazon Registrar, Inc.는 ICANN이 도메인을 등록하도록 인증한 Amazon 회사입니다. 등록 대행자란 귀사의 도메인이 어느 등록 기관에 등록되어 있는지 표시하기 위해 도메인의 WHOIS 레코드에 나열된 “스폰서 등록 기관”입니다.

Q: Gandi는 누구입니까?

Amazon은 등록 기관 Gandi의 대리점입니다. Gandi는 레코드의 등록 기관으로, ICANN의 요구 사항에 따라 초기 등록 시 등록자에게 연락하여 해당 연락처 정보를 확인합니다. Gandi가 요청하는 경우 등록 후 처음 15일 이내에 연락처 정보를 반드시 확인해야 도메인 이름 사용이 중단되지 않습니다. Gandi는 도메인 갱신 전 이를 미리 알려주는 공지도 전송합니다.

Q: Amazon Route 53가 Amazon Registrar를 통해 등록하는 최상위 도메인은 무엇이고, Gandi를 통해 등록하는 최상위 도메인은 무엇입니까?

현재 Amazon Route 53를 사용해 등록할 수 있는 도메인의 목록은 설명서를 참조하십시오. 이 목록에는 어느 등록 기관이 AWS에서 판매하는 각 TLD의 현재 등록 대행자인지에 관한 정보가 포함되어 있습니다.

Q: .com 및 .net 도메인 등록을 Gandi에서 Amazon으로 이전할 수 있습니까?

아니요. 이 기능은 조만간 추가할 예정입니다.

Q: Whois란 무엇입니까? 왜 내 정보가 Whois에 표시됩니까?

Whois는 공개적으로 사용 가능한 도메인 이름 데이터베이스로, 각 도메인 이름과 연관된 연락처 정보와 이름 서버가 기재되어 있습니다. 널리 사용되고 있는 WHOIS 명령을 통해 누구나 Whois 데이터베이스에 액세스할 수 있습니다. WHOIS 명령은 많은 운영 체제에서 지원할 뿐 아니라 많은 웹 사이트에서 웹 애플리케이션으로도 사용 가능합니다. 국제인터넷주소관리기구(ICANN)에서는 다른 사람이 도메인 이름 소유자와 연락해야 하는 경우를 위해 모든 도메인 이름에 공개적으로 사용 가능한 연락처 정보를 제공하도록 요구합니다.

Q: 내 도메인 이름을 Route 53로 전송하려면 어떻게 해야 합니까?

시작하려면 계정에 로그인한 다음 'Domains'를 클릭합니다. 그런 다음 화면 상단에 있는 'Transfer Domain' 버튼을 클릭하고 전송 절차를 완료합니다. 전송 절차를 시작하기 전에 (1) 현재 등록 기관이 해당 도메인 이름을 사용할 수 있는지, (2) 도메인 이름에 대한 개인 정보 보호를 비활성화했는지(사용 가능한 경우), (3) 전송 절차의 일환으로 입력해야 할 유효한 권한 부여 코드 또는 'authcode'를 현재 등록 기관으로부터 입수했는지 확인하십시오.

Q: 기존의 웹 트래픽을 방해하지 않고 기존의 도메인 이름 등록을 Amazon Route 53로 전송하려면 어떻게 해야 합니까?

우선, 도메인 이름에 대한 DNS 레코드 데이터의 목록이 필요합니다. 이는 일반적으로 기존 DNS 제공자로부터 얻을 수 있는 "영역 파일"의 형태로 구할 수 있습니다. DNS 레코드를 사용할 수 있게 되면 Route 53의 Management Console 또는 간편한 웹 서비스 인터페이스를 사용하여 도메인 이름에 대한 DNS 레코드를 저장할 수 있는 호스팅 영역을 생성하고 도메인 이름에 대한 이름 서버를 호스팅 영역과 연결된 이름 서버로 업데이트하는 단계가 포함된 전송 절차를 따르십시오. 도메인 이름 전송 절차를 완료하려면 도메인 이름을 등록한 등록 기관에 문의하고 도메인 이름에 대한 이름 서버를 호스팅 영역과 연결된 이름 서버로 업데이트하는 단계가 포함된 전송 절차를 따르십시오. 등록자가 새 이름 서버의 위임을 적용하면 최종 사용자로부터 받은 DNS 쿼리를 Route 53 DNS 서버에서 응답하기 시작합니다.

Q: 전송 요청 상태를 확인하려면 어떻게 해야 합니까?

Route 53 콘솔의 홈페이지에 있는 'Alerts' 섹션에서 도메인 이름 전송 상태를 확인할 수 있습니다.

Q: 전송이 제대로 되지 않은 경우 어떻게 합니까?

전송이 실패한 이유를 알아보려면 현재 등록 기관에 문의해야 합니다. 등록 기관에서 문제를 해결하고 나면 전송 요청을 다시 제출할 수 있습니다.

Q: 도메인 이름을 다른 등록 기관으로 전송하려면 어떻게 해야 합니까?

도메인 이름을 Route 53에서 다른 등록 기관으로 이전하려면 사용자가 새 등록 기관에 전송 요청을 하도록 의뢰해야 합니다. 해당 등록 기관에서 자체 관리할 도메인 이름에 대해 전송 요청을 하게 됩니다.

Q: Amazon Route 53을 사용하여 관리할 수 있는 도메인 수에 제한이 있습니까?

각 신규 Amazon Route 53 계정은 최대 50개 도메인으로 제한되어 있습니다. 한도를 높이려면 이 요청서를 작성해 주십시오. 업무일 기준 2일 이내에 답변해 드리겠습니다.

Q: Amazon Route 53 DNS에서는 DNSSEC를 지원합니까?

현재 Amazon Route 53의 DNS 서비스에서는 DNSSEC를 지원하지 않습니다. 하지만 AWS 도메인 이름 등록 서비스에서는 다른 공급자가 DNS 서비스를 구성하는 경우 도메인에 사용되는 서명된 DNSSEC 키의 구성을 지원합니다. 도메인 이름 등록을 위해 DNSSEC를 구성하는 데 대한 추가 정보는 여기를 참조하십시오.

Q: DNSSEC가 활성화된 도메인 등록을 Amazon Route 53으로 이전하려면 어떻게 해야 합니까?

DNSSEC가 활성화된 도메인을 Amazon Route 53으로 이전하는 방법에 대한 단계별 안내서는 AWS 설명서를 참조하십시오.