기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Route 53 모범 사례 이 섹션에서는 다음을 포함하여 Amazon Route 53의 다양한 구성 요소에 대한 모범 사례를 제공합니다. 1. **DNS 모범 사례:** + TTL(Time to Live) 값과 응답성 대 신뢰성 간의 균형을 이해합니다. + 성능 개선 및 비용 절감을 위해 가능하면 CNAME 레코드 대신 별칭 레코드를 사용합니다. + 모든 클라이언트가 응답을 받도록 기본 라우팅 정책을 구성합니다. + 지연 시간 기반 라우팅을 활용하여 애플리케이션 지연 시간 및 지리적 위치/지리 근접성 라우팅을 최소화하고 안정성과 예측성을 높입니다. + 자동화된 워크플로용 `GetChange` API를 사용하여 변경 전파를 확인합니다. + 일관된 라우팅을 위해 상위 영역에서 하위 도메인을 위임합니다. + 다중 값 응답 라우팅을 사용하여 대규모 단일 응답을 피합니다. 1. **Resolver 모범 사례:** + 동일한 VPC를 Resolver 규칙 및 인바운드 엔드포인트와 연결하지 않게 하여 라우팅 루프를 방지합니다. + 보안 그룹 규칙을 구현하여 연결 추적 오버헤드를 줄이고 쿼리 처리량을 극대화합니다. + 중복을 위해 여러 가용 영역에 IP 주소를 사용하여 인바운드 엔드포인트를 구성합니다. + 잠재적 DNS 영역 걷기 공격에 유의하고 엔드포인트에 제한이 있는 경우 AWS Support에 문의하세요. 1. **상태 확인 모범 사례:** + Amazon Route 53 상태 확인을 최적화하기 위한 권장 사항을 준수하여 리소스를 안정적으로 모니터링 이러한 모범 사례를 준수하면 DNS 인프라의 성능, 안정성, 보안을 최적화하여 애플리케이션과 서비스로 트래픽을 효율적이고 효과적으로 라우팅할 수 있습니다. **Topics** + [Amazon Route 53 DNS 모범 사례](best-practices-dns.md) + [VPC Resolver 모범 사례](best-practices-resolver.md) + [Amazon Route 53 상태 확인의 모범 사례](best-practices-healthchecks.md) # Amazon Route 53 DNS 모범 사례 다음 모범 사례를 따르면 Amazon Route 53 DNS 서비스를 사용할 때 최상의 결과를 얻을 수 있습니다. **DNS 장애 조치 및 앱 복구에 데이터 영역 기능 사용** 상태 확인 및 Amazon Application Recovery Controller(ARC) 라우팅 제어를 포함한 Route 53용 데이터 플레인은 전 세계에 분산되고, 심각한 이벤트 중에도 100% 가용성과 기능을 제공하도록 설계되었습니다. 이들은 서로 통합되며 제어 영역 기능에 의존하지 않습니다. 콘솔을 포함한 이러한 서비스의 제어 영역은 일반적으로 매우 안정적이지만, 중앙 집중식으로 설계되어 고가용성 대신에 내구성과 일관성을 우선시합니다. 재해 복구 중 장애 조치와 같은 시나리오의 경우, 데이터 플레인 기능에 의존하는 Route 53 상태 확인 및 ARC 라우팅 제어와 같은 기능을 사용하여 DNS를 업데이트하는 것이 좋습니다. 자세한 정보는 [제어 및 데이터 영역 개념](route-53-concepts.md#route-53-concepts-control-and-data-plane) 및 [블로그: Amazon Route 53를 사용하여 재해 복구 메커니즘 생성](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)을 참조하세요. **DNS 레코드에 대한 TTL 값 선택** DNS TTL은 DNS 해석기가 Route 53에 다른 쿼리를 수행하지 않고 레코드가 캐시될 수 있는 기간을 결정하는 데 사용하는 숫자 값(초)입니다. 모든 DNS 레코드에는 TTL이 지정되어 있어야 합니다. TTL 값의 권장 범위는 60초에서 172,800초입니다. 지연 시간과 안정성, 변화에 대한 응답성 사이의 절충을 위해 TTL을 선택합니다. 레코드의 TTL이 짧을수록 DNS 해석기는 더 자주 쿼리해야 하므로 레코드에 대한 업데이트를 더 빠르게 알립니다. 이렇게 하면 쿼리 볼륨(및 비용)이 증가합니다. TTL을 늘리면 DNS 해석기가 캐시의 쿼리에 더 자주 응답합니다. 이는 일반적으로 더 빠르고 저렴하며 일부 상황에서는 인터넷을 통한 쿼리를 피할 수 있기 때문에 더 안정적입니다. 올바른 값은 없지만 응답성과 신뢰성 중 무엇이 중요한지 생각해 보는 것은 가치가 있습니다. TTL 값을 설정할 때 고려할 사항은 다음을 포함합니다. + 변경 사항이 적용될 때까지 기다릴 수 있는 시간의 길이에 대해 DNS 레코드 TTL을 설정합니다. 이는 특히 위임(NS 레코드 세트) 또는 거의 변경되지 않는 다른 레코드(예: MX 레코드)에 해당됩니다. 이러한 레코드의 경우 긴 TTL을 권장합니다. 한 시간(3600초)과 하루(86,400초) 사이의 값을 일반적으로 선택합니다. + 신속한 장애 조치 메커니즘의 일부로 변경해야 하는 레코드(특히 상태 확인된 레코드)의 경우 짧은 TTL이 적합합니다. 이 시나리오에서는 TTL을 60초 또는 120초로 설정하는 것이 일반적입니다. + 중요한 DNS 항목을 변경하는 경우 일시적으로 TTL을 줄이는 것이 좋습니다. 그런 다음 변경, 관찰 및 필요한 경우 빠르게 롤백할 수 있습니다. 변경이 완료되고 예상대로 작동하면 TTL을 늘릴 수 있습니다. 자세한 정보는 [TTL(초)](resource-record-sets-values-shared.md#rrsets-values-common-ttl)을 참조하세요. **CNAME 레코드** DNS CNAME 레코드는 한 도메인 이름을 다른 도메인 이름으로 가리키는 방법입니다. DNS 해석기가 domain-1.example.com을 확인하고 domain-2.example.com을 가리키는 CNAME을 찾으면 DNS 해석기는 응답하기 전에 domain-2.example.com을 확인해야 합니다. 이러한 레코드는 웹 사이트에 도메인 이름이 두 개 이상일 때 일관성을 유지하는 것과 같은 여러 상황에서 유용합니다. 그러나 DNS 해석기는 CNAME에 응답하기 위해 더 많은 쿼리를 작성해야 하므로 지연 시간과 비용이 증가합니다. 가능하면 Route 53 별칭 레코드를 사용하는 것이 더 빠르고 저렴한 대안입니다. 별칭 레코드를 사용하면 Route 53가 AWS 리소스(예: 로드 밸런서) 및 동일한 호스팅 영역 내의 다른 도메인에 대한 직접 응답으로 응답할 수 있습니다. 자세한 내용은 [AWS 리소스로 인터넷 트래픽 라우팅](routing-to-aws-resources.md) 단원을 참조하십시오. **고급 DNS 라우팅** + 지리적 위치, 지리적 근접성 또는 지연 시간 기반 라우팅을 사용할 때 일부 클라이언트가 *응답 없음* 응답을 받기 원하지 않는 한 항상 기본값을 설정하세요. + 애플리케이션 지연 시간을 최소화하려면 지연 시간 기반 라우팅을 사용합니다. 이러한 유형의 라우팅 데이터는 자주 변경될 수 있습니다. + 라우팅 안정성과 예측 가능성을 제공하려면 지리적 위치 또는 지리적 근접성 라우팅을 사용합니다. 자세한 내용은 [지리적 라우팅](routing-policy-geo.md), [지리 근접 라우팅](routing-policy-geoproximity.md), [지연 시간 기반 라우팅](routing-policy-latency.md) 섹션을 참조하세요. **DNS 변경 전파** Route 53 콘솔 또는 API를 사용하여 레코드 또는 호스트 영역을 생성하거나 업데이트하는 경우 변경 사항이 인터넷에 반영되기까지 약간의 시간이 걸립니다. 이는 *변경 전파*라고 불립니다. 일반적으로 전파에는 전역적으로 1분 미만이 걸리지만, 예를 들어 한 위치에 동기화하는 문제나 드문 경우 중앙 제어 영역 내의 문제로 인해 가끔 지연될 수 있습니다. 자동화된 프로비저닝 워크플로를 구축하고 있고 다음 워크플로 단계로 진행하기 전에 변경 전파가 완료될 때까지 기다리는 것이 중요한 경우 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API를 사용하여 DNS 변경이 적용되었는지 확인하세요(`Status =INSYNC`). **DNS 위임** DNS에서 여러 수준의 하위 도메인을 위임하는 경우, 항상 상위 영역에서 위임해야 합니다. 예를 들어 www.dept.example.com을 위임하는 경우 example.com 영역이 아니라 dept.example.com 영역에서 그렇게 해야 합니다. *조부모*에서 *자식* 영역으로 위임하는 것은 전혀 작동하지 않거나 일관성 없이 작동할 수 있습니다. 자세한 내용은 [하위 도메인에 대한 트래픽 라우팅](dns-routing-traffic-for-subdomains.md) 단원을 참조하십시오. **DNS 응답의 크기** 대규모 단일 응답을 생성하지 마십시오. 응답이 512바이트를 초과하면 많은 DNS 해석기가 UDP 대신 TCP를 통해 재시도해야 하므로 안정성이 저하되고 응답이 느려질 수 있습니다. 응답을 512바이트 경계 내로 유지하려면 8개의 정상적인 임의 IP 주소를 선택하는 다중 응답 라우팅을 사용하는 것이 좋습니다. 자세한 내용은 [다중값 응답 라우팅](routing-policy-multivalue.md) 및 [DNS 응답 크기 테스트 서버](https://www.dns-oarc.net/oarc/services/replysizetest/)를 참조하세요. # VPC Resolver 모범 사례 이 섹션에서는 다음 주제를 다루는 Amazon Route 53 VPC Resolver 최적화 모범 사례를 제공합니다. 1. **Resolver 엔드포인트를 사용하여 루프 구성 방지:** + 동일한 VPC가 Resolver 규칙 및 인바운드 엔드포인트와 모두 연결되지 않게 하여 라우팅 루프를 방지합니다. + AWS RAM 를 사용하여 계정 간에 VPCs 공유하는 동시에 적절한 라우팅 구성을 유지합니다. 자세한 내용은 [Resolver 엔드포인트를 사용하여 루프 구성을 방지합니다.](best-practices-resolver-endpoints.md) 섹션을 참조하세요. 1. **Resolver 엔드포인트 크기 조정:** + 연결 상태를 기반으로 트래픽을 허용하는 보안 그룹 규칙을 구현하여 연결 추적 오버헤드를 줄입니다. + 인바운드 및 아웃바운드 Resolver 엔드포인트에 권장되는 보안 그룹 규칙을 준수하여 쿼리 처리량을 극대화합니다. + DNS 트래픽을 생성하는 고유한 IP 주소 및 포트 조합을 모니터링하여 용량 제한을 방지합니다. 자세한 내용은 [Resolver 엔드포인트 크기 조정](best-practices-resolver-endpoint-scaling.md) 섹션을 참조하세요. 1. **Resolver 엔드포인트의 고가용성:** + 중복을 위해 두 개 이상의 가용 영역에 IP 주소를 사용하여 인바운드 엔드포인트를 구성합니다. + 추가 네트워크 인터페이스를 프로비저닝하여 유지 관리 또는 트래픽 급증 중에 가용성을 보장합니다. 자세한 내용은 [Resolver 엔드포인트의 고가용성](best-practices-resolver-endpoint-high-availability.md) 섹션을 참조하세요. 1. **DNS 영역 보행 공격 방지:** + 공격자가 DNSSEC 서명 DNS 영역에서 모든 콘텐츠를 검색하려고 시도하는 잠재적 DNS 영역 보행 공격에 유의합니다. + 의심스러운 영역 걷기로 인해 엔드포인트가 제한되는 경우 AWS Support에 문의하여 지원을 받으세요. 자세한 내용은 [DNS zone walking](best-practices-resolver-zone-walking.md) 섹션을 참조하세요. 이러한 모범 사례를 따르면 VPC Resolver 배포의 성능, 확장성 및 보안을 최적화하여 애플리케이션 및 리소스에 대한 안정적이고 효율적인 DNS 확인을 보장할 수 있습니다. # Resolver 엔드포인트를 사용하여 루프 구성을 방지합니다. 동일한 VPC를 (엔드포인트의 직접 대상이든, 온프레미스 DNS 서버를 통해서든) Resolver 규칙 및 인바운드 엔드포인트에 연결하지 마세요. Resolver 규칙의 아웃바운드 엔드포인트가 VPC를 규칙과 공유하는 인바운드 엔드포인트를 가리키면 쿼리가 인바운드 엔드포인트와 아웃바운드 엔드포인트 간에 지속적으로 전달되는 루프가 발생할 수 있습니다. 전달 규칙은 AWS Resource Access Manager ()를 사용하여 다른 VPCs와 계속 연결할 수 있습니다AWS RAM. 허브 또는 중앙 VPC와 연결된 프라이빗 호스팅 영역은 여전히 인바운드 엔드포인트에 대한 쿼리에서 해석됩니다. 해석기 전달 규칙이 이 해석을 변경하지 않기 때문입니다. # Resolver 엔드포인트 크기 조정 Resolver 엔드포인트 보안 그룹은 연결 추적을 사용해 엔드포인트에서 송수신하는 트래픽에 대한 정보를 수집합니다. 각 엔드포인트 인터페이스에는 추적할 수 있는 최대 연결 수가 있으며 많은 양의 DNS 쿼리가 연결 수를 초과하면 제한 및 쿼리 손실이 발생할 수 있습니다. 연결 추적은 보안 그룹(SG)을 통해 흐르는 트래픽의 상태를 모니터링하기 위한 AWS기본 동작입니다.SGs SG에서 연결 추적을 사용하면 트래픽 처리량이 감소하지만 추적하지 않는 연결을 구현하여 오버헤드를 줄이고 성능을 개선할 수 있습니다. 자세한 내용은 [추적하지 않는 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections)을 참조하세요. 제한적인 보안 그룹 규칙을 사용하여 연결 추적을 적용하거나 Network Load Balancer 통해 쿼리를 라우팅하는 경우([자동으로 추적하는 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking) 참조) 엔드포인트에 대한 IP 주소별 초당 전체 최대 쿼리는 최소 1,500개가 될 수 있습니다. **인바운드 Resolver 엔드포인트에 대한 수신 및 송신 보안 그룹 규칙 권장 사항** **** | | | **수신 규칙** | | --- | | 프로토콜 유형 | 포트 번호 | 소스 IP | | TCP | 53 | 0.0.0.0/0 | | UDP | 53 | 0.0.0.0/0 | | **송신 규칙** | | --- | | 프로토콜 유형 | 포트 번호 | 목적지 IP | | TCP | All | 0.0.0.0/0 | | UDP | All | 0.0.0.0/0 | **아웃바운드 Resolver 엔드포인트에 대한 수신 및 송신 보안 그룹 규칙 권장 사항** **** | | | **수신 규칙** | | --- | | 프로토콜 유형 | 포트 번호 | 소스 IP | | TCP | All | 0.0.0.0/0 | | UDP | All | 0.0.0.0/0 | | **송신 규칙** | | --- | | 프로토콜 유형 | 포트 번호 | 목적지 IP | | TCP | 53 | 0.0.0.0/0 | | UDP | 53 | 0.0.0.0/0 | **참고** **보안 그룹 포트 요구 사항:** **인바운드 엔드포인트**에는 포트 53의 TCP 및 UDP가 네트워크에서 DNS 쿼리를 수신하도록 허용하는 수신 규칙이 필요합니다. 송신 규칙의 경우 엔드포인트가 다양한 소스 포트의 쿼리에 응답해야 할 수 있으므로 모든 포트를 허용할 수 있습니다. **아웃바운드 규칙**에는 네트워크에서 DNS 쿼리에 사용하는 포트에 대해 TCP 및 UDP 액세스를 허용하는 송신 규칙이 필요합니다. 포트 53는 가장 일반적인 DNS 포트여서 위 예제에 제시되었지만 각 네트워크는 다른 포트를 사용할 수도 있습니다. 수신 규칙은 모든 포트가 DNS 서버의 응답을 수용하도록 허용할 수 있습니다. **인바운드 Resolver 엔드포인트** 인바운드 Resolver 엔드포인트를 사용하는 클라이언트의 경우 DNS 트래픽을 생성하는 40,000개 이상의 고유 IP 주소 및 포트 조합이 있는 경우 탄력적 네트워크 인터페이스 용량에 영향을 미칩니다. # Resolver 엔드포인트의 고가용성 VPC Resolver 인바운드 엔드포인트를 생성할 때 Route 53에서는 네트워크의 DNS 해석기가 쿼리를 전달할 IP 주소를 두 개 이상 생성해야 합니다. 또한 중복성을 위해 가용 영역 2개 이상에서 IP 주소를 지정해야 합니다. 항상 둘 이상의 탄력적 네트워크 인터페이스 엔드포인트를 사용할 수 있어야 하는 경우 네트워크 인터페이스를 필요한 수보다 하나 더 생성하여 트래픽 급증 가능성에 대비할 수 있는 추가 용량을 확보하는 것이 좋습니다. 또한 추가 네트워크 인터페이스는 유지 관리 또는 업그레이드와 같은 서비스 운영 중에도 가용성을 보장합니다. 자세한 내용은이 자세한 블로그 문서인 [Resolver 엔드포인트 및를 사용하여 DNS 고가용성을 달성하는 방법을 참조하세요](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/)[인바운드 엔드포인트를 생성 또는 편집할 때 지정하는 값](resolver-forwarding-inbound-queries-values.md). # DNS zone walking DNS zone walking 공격은 DNSSEC 서명 DNS 영역에서 모든 콘텐츠를 가져오려고 시도합니다. VPC Resolver 팀이 엔드포인트에서 DNS 영역이 확인될 때 생성된 트래픽 패턴과 일치하는 트래픽 패턴을 감지하면 서비스 팀은 엔드포인트의 트래픽을 제한합니다. 따라서 DNS 쿼리 시간 초과의 비율이 높아질 수 있습니다. 엔드포인트의 용량 감소를 목격하고 엔드포인트 제한이 잘못되었다고 생각하면 https://console.aws.amazon.com/support/home\$1/으로 이동하여 지원 사례를 만듭니다. # Amazon Route 53 상태 확인의 모범 사례 고가용성과 복원력을 갖춘 인프라를 유지하려면 효과적인 상태 확인 구성이 필수적입니다. 다음은 Amazon Route 53 상태 확인을 설정하고 관리할 때 고려해야 할 몇 가지 모범 사례입니다. 1. **상태 확인 엔드포인트에 탄력적 IP 주소 사용:** + 상태 확인 엔드포인트에 탄력적 IP 주소를 활용하여 일관된 모니터링을 보장합니다. + Amazon EC2 인스턴스를 더 이상 사용하지 않는 경우 잠재적인 보안 위험 또는 데이터 손상을 방지하려면 관련 상태 확인을 삭제해야 합니다. 자세한 내용은 [상태 확인 생성 또는 업데이트 시 지정하는 값](health-checks-creating-values.md)을 참조하세요. 1. **적절한 상태 확인 간격 구성:** + 애플리케이션의 요구 사항과 모니터링된 리소스의 중요도에 따라 상태 확인 간격을 설정합니다. + 간격이 짧을수록 장애 감지가 빨라지지만 Route 53 비용과 리소스의 부담이 증가할 수 있습니다. + 간격이 길수록 비용과 리소스 리소스의 부담은 줄어들지만 장애 감지가 지연될 수 있습니다. 자세한 내용은 [고급 구성("Monitor an endpoint" 전용)](health-checks-creating-values.md#health-checks-creating-values-advanced)을 참조하세요. 1. **경보 알림 구현:** + 상태 확인이 실패하거나 복구될 때 알림을 받도록 Amazon CloudWatchalarms를 구성합니다. + 애플리케이션의 요구 사항과 리소스의 예상 동작에 따라 적절한 경보 임계값을 설정합니다. + 알림과 모니터링 및 인시던트 대응 프로세스를 통합합니다. 자세한 내용은 [CloudWatch를 이용한 상태 확인 모니터링](monitoring-health-checks.md)을 참조하세요. 1. **상태 확인 리전을 전략적으로 활용:** + 사용자 및 리소스의 지리적 분포를 기반으로 상태 확인 리전을 선택합니다. + 중요 리소스에 여러 상태 확인 리전을 사용하여 신뢰성을 개선하고 리전 중단의 영향을 줄이는 것을 고려합니다. 1. **상태 확인 로그 및 지표 모니터링:** + Route 53 상태 확인 로그 및 CloudWatch 지표를 정기적으로 검토하여 잠재적 문제 또는 성능 병목 현상을 식별합니다. + 상태 확인 실패 이유를 분석하고 기본 문제를 해결하기 위해 적절한 조치를 취합니다. 1. **장애 조치 및 장애 복구 전략 구현:** + Route 53의 장애 조치 라우팅 정책을 활용하여 장애 발생 시 트래픽을 정상 리소스로 자동 라우팅합니다. + 장애 조치 및 장애 복구 프로세스를 계획하고 테스트하여 중단 및 복구 중에 원활한 전환을 보장합니다. 자세한 내용은 [DNS 장애 조치 구성](dns-failover-configuring.md)을 참조하세요. 1. **상태 확인 정기 검토 및 업데이트:** + 최적의 모니터링 및 성능을 유지하기 위해 필요에 따라 상태 확인 엔드포인트, 간격, 경보 임계값을 업데이트합니다. 이러한 모범 사례를 따르면 Amazon Route 53 상태 확인을 효과적으로 활용하여 리소스의 상태와 가용성을 모니터링하고 애플리케이션 및 서비스에 대한 안정적인 고성능 인프라를 보장할 수 있습니다.