Amazon Route 53 FAQ

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

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

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

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

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

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

• A(주소 레코드)
• AAAA(IPv6 주소 레코드)
• CNAME(정식 이름 레코드)
• CAA(인증 기관 인증)
• MX(메일 교환 레코드)
• NAPTR(이름 권한 포인터 레코드)
• NS(이름 서버 레코드)
• PTR(포인터 레코드)
• SOA(권한 시작 레코드)
• SPF(Sender Policy Framework)
• SRV(서비스 로케이터)
• TXT(텍스트 레코드)
• Amazon Route 53는 DNS에 대한 Amazon Route 53 특정 확장명인 별칭 레코드를 제공합니다. 별칭 레코드를 생성하여 Amazon Elastic Load Balancing 로드 밸런서, Amazon CloudFront 배포, AWS Elastic Beanstalk 환경, API Gateway, VPC 인터페이스 엔드포인트 및 웹사이트로 구성된 Amazon S3 버킷 등의 선택한 AWS 리소스에 트래픽을 라우팅할 수 있습니다. 별칭 레코드에는 A 또는 AAAA 유형이 있지만, 이들은 CNAME 레코드처럼 동작합니다. 별칭 레코드를 사용하면 레코드 이름(example.com)을 AWS 리소스의 DNS 이름(elb1234.elb.amazonaws.com)에 매핑할 수 있습니다. Resolver는 A 또는 AAAA 레코드와 AWS 리소스의 IP 주소를 확인합니다.

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

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

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

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

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

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

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

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

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

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

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

예. 기존 및 새로운 퍼블릭 호스트 영역에 대해 DNSSEC 서명을 활성화하고 Amazon Route 53 Resolver에 대해 DNSSEC 유효성 검사를 활성화할 수 있습니다. 또한, Amazon Route 53에서 도메인 등록에 DNSSEC를 적용할 수 있습니다.

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

예. Amazon Route 53는 ‘별칭’ 레코드라고 불리는 특정 유형의 레코드를 제공하므로 이를 이용하여 Zone Apex(example.com) DNS 이름을 ELB 로드 밸런서(my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com)의 DNS 이름에 매핑할 수 있습니다. 로드 밸런서와 연관된 IP 주소는 언제든 규모 확장/축소 또는 소프트웨어 업데이트에 맞게 변경할 수 있습니다. Route 53는 로드 밸런서에 대한 하나 이상의 IP 주소를 사용하여 각 별칭 레코드에 대한 요청에 응답합니다. Route 53는 Application Load Balancer, Network Load Balancer 및 Classic Load Balancer 등 세 가지 유형의 로드 밸런서의 별칭 레코드를 지원합니다. AWS ELB 로드 밸런서에 매핑된 별칭 레코드에 대한 쿼리에는 추가 요금이 부과되지 않습니다. 이 쿼리는 Amazon Route 53 사용 보고서에 “Intra-AWS-DNS-Queries”로 기재되어 있습니다.

예. Amazon Route 53는 ‘별칭’ 레코드라는 특정 유형의 레코드를 제공하여 루트 도메인(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”로 기재되어 있습니다.

예. 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”로 기재되어 있습니다.

예. 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”로 기재되어 있습니다.

예. Amazon Route 53는 ‘별칭’ 레코드라고 하는 특정 유형의 레코드를 제공하여 Zone Apex(example.com) DNS 이름을 Amazon API Gateway DNS 이름(예: api-id.execute-api.region.amazonaws.com/stage)에 매핑할 수 있습니다. Amazon API Gateway와 연결된 IP 주소는 언제든 확장, 축소 또는 소프트웨어 업데이트에 맞게 변경할 수 있습니다. Route 53는 API Gateway에 대한 하나 이상의 IP 주소를 사용하여 각 별칭 레코드 요청에 응답합니다. Amazon API Gateway 환경에 매핑된 별칭 레코드에 대한 쿼리는 추가 요금이 부과되지 않습니다. 이 쿼리는 Route 53 사용 보고서에 “Intra-AWS-DNS-Queries”로 기재되어 있습니다.

예. Amazon Route 53는 ‘별칭’ 레코드라고 하는 특정 유형의 레코드를 제공하여 Zone Apex(example.com) DNS 이름을 Amazon VPC 엔드포인트 DNS 이름(예: vpce-svc-03d5ebb7d9579a2b3.us-east-1.vpce.amazonaws.com)에 매핑할 수 있습니다. Amazon VPC 엔드포인트와 연결된 IP 주소는 언제든 확장, 축소 또는 소프트웨어 업데이트에 맞게 변경할 수 있습니다. Route 53는 VPC 엔드포인트에 대한 하나 이상의 IP 주소를 사용하여 각 별칭 레코드 요청에 응답합니다. Amazon VPC 엔드포인트 환경에 매핑된 별칭 레코드에 대한 쿼리는 추가 요금이 부과되지 않습니다. 이 쿼리는 Amazon Route 53 사용 보고서에 “Intra-AWS-DNS-Queries”로 기재되어 있습니다.

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)에 대한 별칭 레코드를 만들 수 있으며 둘째, 별칭 레코드에 대한 쿼리가 무료로 제공됩니다.

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

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

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

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

모든 AWS 서비스가 그러하듯이 Amazon Route 53와 LBR을 사용할 때에는 사전 수수료나 장기 약정을 체결하지 않아도 됩니다. 실제로 사용한 호스팅 영역과 쿼리에 대해서만 비용을 지불하면 됩니다. 지연 시간 기반 라우팅 쿼리 요금에 대한 세부 정보는 Amazon Route 53 요금 페이지를 참조하십시오.

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

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

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

Route 53의 지역 IP 데이터베이스에서 인식하지 못하는 IP 주소로부터 DNS 쿼리가 수신되는 경우

사용자가 생성한 특정 지역 DNS 레코드에 포함되어 있지 않은 로케이션에서 DNS 쿼리가 수신되는 경우

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

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

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

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

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

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

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

트래픽 정책은 애플리케이션의 DNS 이름(예: www.example.com)에 아직 연결되어 있지 않으므로 그 자체로는 최종 사용자가 애플리케이션에 라우팅되는 방법에 영향을 주지 못합니다. 생성한 트래픽 정책을 사용하여 Amazon Route 53 Traffic Flow에서 트래픽을 애플리케이션으로 라우팅하기 시작하려면, 트래픽 정책을 자체 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 호스팅 영역 섹션에서 모두 확인할 수 있습니다.

예. 정책을 재사용하여 하나 이상의 DNS 이름을 관리할 수 있으며, 다음과 같은 두 가지 방법 중 하나를 사용하면 됩니다. 첫 번째 방법은 정책을 사용하여 추가 정책 레코드를 생성하는 것입니다. 생성하는 각 정책 레코드에 대해 요금이 청구되므로 이 방법을 사용할 경우 추가 요금이 있습니다.

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

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

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

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

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

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

엔드포인트에서 지리적 근접성 바이어스 값을 변경하면 Route 53가 트래픽을 리소스에 라우팅하는 영역이 확장되거나 축소됩니다. 하지만 지리적 영역 크기의 작은 변화에는 많은 수의 쿼리를 생성하는 주요 대도시 영역이 포함될 수도 있고 제외될 수도 있기 때문에 지리적 근접성 바이어스는 로드 비율을 정확히 예측할 수 없습니다. 자세한 내용은 설명서를 참조하십시오.

현재는 지리적 근접성 규칙에만 바이어스를 적용할 수 있습니다. 

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

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

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

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

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

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

예. 다른 계정에 속한 VPC를 단일 호스팅 영역에 연결할 수 있습니다. 여기에서 자세한 정보를 확인할 수 있습니다.

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

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

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

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

시작하기 위한 자세한 정보는 Amazon Route 53 개발자 안내서를 참조하십시오. 또한 Route 53 Console에서 DNS 장애 조치를 구성할 수 있습니다.

예, 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 개발자 안내서를 참조하십시오.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Route 53는 애플리케이션의 상태 확인을 수행합니다. 이 예에서 애플리케이션이 3회 연속으로 상태 확인에 실패하면 다음 이벤트가 트리거됩니다.

Route 53는 실패한 엔드포인트의 리소스 레코드를 비활성화하고 더 이상 해당 레코드를 제공하지 않습니다. 이 장애 조치 단계에서 실패한 엔드포인트 대신 상태가 양호한 엔드포인트로 트래픽을 라우팅하기 시작합니다.

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

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

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

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

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

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

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

상태 확인의 현재 상태 및 장애 원인에 대한 세부 정보는 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)가 포함되며, 이 값을 사용하여 지표가 어떤 상태 확인을 추적하고 있는지를 식별할 수 있습니다.

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

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

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

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

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 개발자 안내서를 참조하십시오.

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 서비스 자체를 사용할 수 없는 경우에 다른 위치로 장애 조치를 수행할 뿐입니다.

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

예. 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 로드, 네트워크 수신/송신, 디스크 읽기 등과 같은 내부 지표가 서버 자체가 비정상임을 보여주는 경우, 엔드포인트가 장애 조치되도록 구성을 생성할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

TLD 목록은 요금 목록을 참조하십시오. 각 TLD에 대한 특정 등록 요구 사항은 Amazon Route 53 개발자 안내서 및 도메인 이름 등록 계약을 참조하십시오.

도메인 이름이 생성되면 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 설명서를 참조하십시오.

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

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

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

사용할 기본 도메인 대행업체를 동적으로 선택합니다. 대부분의 도메인은 Amazon Registrar를 통해 등록됩니다. 현재 Amazon Route 53를 사용하여 등록할 수 있는 도메인의 목록은 설명서를 참조하세요.

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

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

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

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

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

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

각 신규 Amazon Route 53 계정은 최대 20개 도메인으로 제한되어 있습니다. 한도 증가를 요청하려면 AWS에 문의하세요.

예. 기존 및 새로운 퍼블릭 호스팅 영역에 대해 DNSSEC 서명을 활성화할 수 있습니다.

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

Route 53 Resolver는 EC2에 호스팅된 이름과 인터넷에서 사용하는 퍼블릭 이름에 대한 반복적 DNS 조회를 제공하는 지역 DNS 서비스입니다. 이 기능은 모든 Amazon Virtual Private Cloud(VPC)에서 기본적으로 사용할 수 있습니다. 하이브리드 클라우드 시나리오의 경우 조건부 전달 규칙과 DNS 엔드포인트를 구성하여 AWS Direct Connect 및 AWS 관리형 VPN 전반에 걸쳐 DNS 확인을 활성화할 수 있습니다.

Amazon Route 53은 신뢰할 수 있는 DNS 서비스 및 재귀 DNS 서비스입니다. 신뢰할 수 있는 DNS에는 DNS 쿼리에 대한 최종 응답(일반적으로 IP 주소)가 포함됩니다. 매우 드문 경우를 제외하고, 클라이언트(예: 모바일 디바이스, 클라우드에서 실행되는 애플리케이션, 데이터 센터의 서비스)는 실제로 신뢰할 수 있는 DNS 서비스와 직접 통신하지 않습니다. 그 대신, 클라이언트는 재귀 DNS 서비스(DNS 확인자라고도 알려짐)와 통신하며 이 서비스는 모든 DNS 쿼리에 대해 신뢰할 수 있는 올바른 답변을 찾습니다. Route 53 Resolver는 재귀 DNS 서비스입니다.

쿼리를 수신하면 Route 53 Resolver와 같은 재귀 DNS 서비스는 쿼리를 곧바로 특정 재귀 DNS 서버에 자동으로 전달하도록 구성되거나, 도메인의 루트에서 시작하여 최종 응답을 찾을 때까지 계속 재귀적으로 검색할 수 있습니다. 어떠한 경우에든 응답을 발견하면 재귀 DNS 서버는 향후 동일한 이름에 대한 후속 쿼리에 더 빠르게 응답할 수 있도록 일정 기간 동안 응답을 캐시할 수 있습니다.

Resolver는 조건부 전달 규칙을 사용하여 지정된 도메인에 대한 쿼리를 선택한 대상 IP 주소(일반적으로 온프레미스 DNS 확인자)에 전달할 수 있습니다. 규칙은 VPC 수준에서 적용되며 규칙을 한 계정에서 관리하고 여러 계정 간에 공유할 수 있습니다.

DNS 엔드포인트에는 Amazon Virtual Private Cloud(VPC)에 연결하는 하나 이상의 탄력적 네트워크 인터페이스(ENI)가 포함되어 있습니다. 각 ENI에는 현재 위치하고 있는 VPC의 서브넷 공간에서 IP 주소가 할당됩니다. 그러면 이 IP 주소는 온프레미스 DNS 서버가 쿼리를 전달할 수 있도록 전달 대상 역할을 수행할 수 있습니다. 엔드포인트는 AWS Direct Connect 및 관리형 VPN를 통해 VPC에서 네트워크로, 네트워크에서 VPC로 전달하는 DNS 쿼리 트래픽에 모두 필요합니다.

Route 53 Resolver는 AWS 계정 간에 또는 AWS Organization 내에서 리소스를 공유하는 간단한 방법을 고객에게 제공하는 AWS Resource Access Manager(RAM)와 통합됩니다. RAM을 사용하면 하나의 기본 계정에서 규칙을 생성한 다음 여러 계정 간에 공유할 수 있습니다. 공유한 후에도 규칙이 효과를 나타내려면 먼저 해당 계정에서 VPC에 규칙을 적용해야 합니다. 자세한 내용은 AWS RAM 설명서를 참조하십시오.

이전에 규칙을 공유했던 다른 계정에서 해당 규칙을 더 이상 사용할 수 없습니다. 따라서 해당 규칙이 해당 계정에서 VPC에 연결된 경우 해당 VPC에서 해당 규칙의 연결이 해제됩니다.

Route 53 Resolver가 출시된 리전을 확인하려면 AWS 리전 표를 참조하십시오.

아니요. Amazon Route 53 퍼블릭 및 프라이빗 DNS, 트래픽 흐름, 상태 확인, 도메인 이름 확인은 모두 글로벌 서비스입니다.

Route 53 Resolver를 사용하면 AWS Outposts 랙에서 로컬로 도메인 이름 서버(DNS) 쿼리를 확인하여 온프레미스 애플리케이션의 가용성과 성능을 높일 수 있습니다. Route 53 Resolver on Outposts를 사용하도록 설정하면 Route 53가 DNS 응답을 Outposts 랙에 자동으로 저장하고 상위 AWS 리전과의 네트워크 연결이 예기치 않게 끊긴 경우에도 애플리케이션에 대한 DNS 확인을 지속적으로 제공합니다. 또한 Route 53 Resolver on Outposts는 DNS 응답을 로컬로 제공하므로 DNS 확인의 지연 시간이 짧아지고
온프레미스 애플리케이션의 성능이 개선됩니다.

Route 53 Resolver 엔드포인트를 통해 Route 53 Resolvers on Outposts 랙을 온프레미스 데이터 센터의 DNS 서버에 연결할 수도 있습니다. 이렇게 하면 Outposts 랙과 다른 온프레미스 리소스 간의 DNS 쿼리를 확인할 수 있습니다.

시작하기 위한 자세한 정보는 Amazon Route 53 개발자 안내서를 참조하십시오. 또한 Amazon Route 53 콘솔 내에서 Resolver를 구성할 수 있습니다.

예. Amazon Route 53 Resolver는 인바운드 및 아웃바운드 해석기 엔드포인트에 대해 DNS over HTTPS(DoH) 프로토콜의 사용을 지원합니다.

Amazon Route 53 Resolver DNS 방화벽은 모든 Amazon Virtual Private Cloud(VPC)에 DNS 보호를 신속하게 배포할 수 있는 기능입니다. Route 53 Resolver DNS 방화벽을 사용하면 재귀적 DNS 확인을 위해 Route 53 Resolver를 사용할 때 알려진 악성 도메인에 대한 쿼리를 차단하고("거부목록" 생성) 신뢰할 수 있는 도메인에 대한 쿼리를 허용할 수 있습니다("허용 목록"생성). AWS 관리형 도메인 목록을 사용하여 일반적인 DNS 위협에 대한 보호를 빠르게 시작할 수도 있습니다. Amazon Route 53 Resolver DNS 방화벽은 AWS Firewall Manager와 연동되므로, DNS 방화벽 규칙을 기반으로 정책을 구축한 후 해당 정책을 중앙에서 VPC 및 계정 전반에 적용할 수 있습니다.

VPC 내에서 DNS를 통해 쿼리할 수 있는 도메인 이름을 필터링하려는 경우 DNS 방화벽이 적합합니다. 다음 두 가지 방법으로 조직의 보안 상태에 가장 적합한 구성을 유연하게 선택할 수 있습니다. (1) 엄격한 DNS 유출 요구 사항이 있고 승인된 도메인 목록에 없는 도메인에 대한 모든 아웃바운드 DNS 쿼리를 거부하려는 경우, DNS 보안에 대한 "벽으로 둘러싸인" 접근 방식에 대해 이러한 규칙을 만들 수 있습니다. (2) 기본적으로 계정 내에서 모든 아웃바운드 DNS 조회를 허용하고 알려진 악성 도메인에 대한 DNS 요청을 차단하는 기능만 필요한 경우 DNS 방화벽을 사용하여 조직이 인식하고 있는 모든 악성 도메인 이름을 포함하는 거부 목록 만들 수 있습니다. DNS 방화벽에는 의심스러운 도메인 및 C&C(Command-and-Control) 봇으로부터 보호하는 데 도움이 되는 AWS 관리형 도메인 목록도 함께 제공됩니다.

Route 53 Resolver DNS 방화벽은 전체 VPC에 Route 53 Resolver DNS 트래픽(예: AmazonProvidedDNS)에 대한 제어 및 가시성을 제공하여 AWS의 기존 네트워크 및 애플리케이션 보안 서비스를 보완합니다. 사용 사례에 따라 AWS 네트워크 방화벽, Amazon VPC 보안 그룹, AWS 웹 애플리케이션 방화벽 규칙 또는 AWS Marketplace 어플라이언스와 같은 기존 보안 제어 기능과 함께 DNS 방화벽을 구현하도록 선택할 수 있습니다.

예. Route 53 Resolver DNS 방화벽은 리전 기능으로, 조직 및 계정 수준에서 Route 53 Resolver DNS 네트워크 트래픽을 보호합니다. 여러 계정에서 정책과 거버넌스를 유지하려면 AWS Firewall Manager를 사용해야 합니다.

요금은 방화벽 내에 저장된 도메인 이름 수와 검사된 DNS 쿼리 수를 기반으로 합니다. 자세한 내용을 살펴보려면 Amazon Route 53 요금을 방문하십시오.

추가 분석 및 조사를 위해 DNS 방화벽 활동을 Amazon S3 버킷 또는 Amazon CloudWatch 로그 그룹에 기록할 수 있습니다.. Amazon Kinesis Firehose를 사용하여 서드 파티 공급자에게 로그를 보낼 수도 있습니다.

Amazon Route 53 Resolver DNS Firewall과 AWS Network Firewall은 모두 아웃바운드 DNS 쿼리 위협에 대한 보호를 제공하지만 배포 모델에 있어서 다릅니다. Amazon Route 53 Resolver DNS Firewall은 DNS 확인에 Amazon Route 53 Resolver를 사용하는 경우 악성 또는 손상된 도메인에 대한 DNS 요청을 차단하는 세분화된 제어를 제공합니다. AWS Network Firewall은 외부 DNS 서비스를 사용하여 DNS 요청을 확인하는 경우 알려진 악성 도메인으로의 아웃바운드 DNS 쿼리를 필터링하고 차단하는 유사한 기능을 제공합니다.

Amazon Route 53 Profiles를 사용하면 하나 이상의 공유 가능한 구성을 Profile 형태로 생성하여 전체 조직의 DNS 구성을 손쉽게 관리할 수 있습니다. Profiles를 사용하면 프라이빗 호스팅 영역(PHZ) 연결, Resolver 규칙, Route 53 Resolver DNS 방화벽 규칙 그룹과 같은 다양한 구성을 하나의 RAM 공유 가능 구성 안에 결합할 수 있습니다. Profile을 AWS 계정 전체에서 공유하고 Amazon Virtual Private Cloud(VPC)에 연결하면 별도의 리소스를 관리할 필요 없이 모든 VPC에서 동일한 DNS 구성을 유지할 수 있습니다.

Route 53 Profiles는 기본적으로 AWS RAM과 통합되므로 계정 간에 또는 AWS Organization과 Profiles를 공유할 수 있습니다.

예. Route 53 Profiles는 사용자가 각 리소스에 서로 다른 권한을 연결할 수 있도록 하는 RAM 관리형 권한을 활용합니다.

최대 5,000개의 VPC를 단일 Route 53 Profile에 연결할 수 있습니다.

예. 계정당 하나 이상의 Profile을 만들 수 있습니다. 하지만 VPC에는 한 번에 하나의 Profile만 연결할 수 있습니다.

Route 53 Profiles는 프라이빗 호스팅 영역과 해당 영역 내에 지정된 설정, Route 53 Resolver 규칙(전달 및 시스템 모두), DNS 방화벽 규칙 그룹을 지원합니다. 또한 일부 VPC 구성은 Profiles 내에서 직접 관리됩니다. 이러한 구성으로는 Resolver 규칙에 대한 역방향 DNS 조회 구성, DNS 방화벽 장애 모드 구성, DNSSEC 검증 구성이 있습니다.

아니요. AWS 리전 간에 Profile을 공유할 수 없습니다.