Source: Dev.to

AWS Route 53 DNS (Domain Name System) 라우팅 정책

AWS Route 53은 도메인 이름을 IP 주소와 매핑하는 DNS 서비스이며, 다양한 라우팅 정책을 통해 트래픽을 세밀하게 제어할 수 있습니다. 이번 포스트에서는 Route 53에서 제공하는 주요 라우팅 정책 7가지를 살펴보고, 각각을 언제, 어떻게 사용해야 하는지 예시와 함께 설명합니다.

---

1️⃣ Simple Routing Policy (단순 라우팅)

• 설명: 가장 기본적인 정책으로, 하나의 레코드에 하나의 IP 주소(또는 Alias)를 지정합니다. 트래픽은 지정된 레코드로 무조건 라우팅됩니다.
• 사용 사례: 단일 서버 혹은 단일 리전에서 서비스가 운영될 때.

example.com.   A   192.0.2.44

---

2️⃣ Weighted Routing Policy (가중 라우팅)

• 설명: 동일한 도메인에 여러 레코드를 만들고, 각 레코드에 가중치(weight) 를 부여합니다. 트래픽은 가중치 비율에 따라 분산됩니다.
• 사용 사례: A/B 테스트, 점진적 배포, 블루/그린 배포 등.

---

3️⃣ Latency‑Based Routing Policy (지연 시간 기반 라우팅)

• 설명: 사용자의 지연 시간(latency) 이 가장 낮은 리전으로 트래픽을 라우팅합니다. Route 53은 전 세계에 배포된 DNS 엣지 로케이션을 활용해 지연 시간을 측정합니다.
• 사용 사례: 전 세계 사용자에게 최적의 응답 속도를 제공해야 할 때.

example.com.   A   52.95.110.1   (us-east-1)
example.com.   A   13.58.123.4   (ap-northeast-2)

---

4️⃣ Failover Routing Policy (장애 조치 라우팅)

• 설명: Primary 레코드와 Secondary 레코드를 정의하고, Primary 가 정상(헬스 체크 통과)일 경우에만 트래픽을 전달합니다. Primary 가 비정상이면 자동으로 Secondary 로 전환됩니다.
• 사용 사례: 고가용성(HA) 구성, 재해 복구(DR) 시나리오.

---

5️⃣ Geolocation Routing Policy (지리 위치 라우팅)

• 설명: 요청자의 국가/대륙 정보를 기반으로 지정된 레코드로 라우팅합니다.
• 사용 사례: 지역별 콘텐츠 제공, 법적 규제에 따른 트래픽 제한.

---

6️⃣ Geoproximity Routing (위치 근접 라우팅) [Traffic Flow 사용]

• 설명: Geolocation 보다 세밀하게, 특정 리전의 트래픽 비중을 bias 값으로 조정할 수 있습니다. 양수 bias는 해당 리전으로 더 많은 트래픽을 끌어들이고, 음수 bias는 트래픽을 감소시킵니다.
• 사용 사례: 특정 리전의 용량이 한정돼 있을 때, 트래픽을 의도적으로 분산하고 싶을 때.

주의: Geoproximity 라우팅은 Route 53 Traffic Flow 콘솔에서만 설정 가능하며, API/CLI에서는 지원되지 않습니다.

---

7️⃣ Multi‑Value Answer Policy (다중 응답 정책)

• 설명: 하나의 레코드에 다중 IP 주소 를 지정하고, DNS 응답에 최대 8개의 IP 중 랜덤 으로 반환합니다. 각 IP에 대해 별도의 헬스 체크를 적용할 수 있어, 비활성화된 IP는 자동으로 응답에서 제외됩니다.
• 사용 사례: 간단한 로드 밸런싱이 필요하지만, 별도 로드 밸런서를 도입하고 싶지 않을 때.

example.com.   A   192.0.2.44
example.com.   A   192.0.2.45
example.com.   A   192.0.2.46
example.com.   A   192.0.2.47

---

📌 정리

Route 53의 라우팅 정책을 적절히 조합하면 비용 효율적이면서도 고가용성을 갖춘 DNS 설계가 가능합니다. 실제 운영 환경에 맞게 정책을 선택하고, 헬스 체크와 모니터링을 함께 구성해 두면 예상치 못한 장애에도 빠르게 대응할 수 있습니다.

Tip: 정책을 변경할 때는 TTL(Time‑to‑Live) 값도 함께 검토하세요. TTL이 짧을수록 변경 사항이 빠르게 반영되지만, DNS 쿼리 비용이 증가할 수 있습니다.

---

이 글이 도움이 되셨다면, 👍와 📌를 눌러 주세요! 궁금한 점은 댓글로 남겨 주시면 답변해 드리겠습니다.

DNS란?

• Domain Name System – 사람이 읽기 쉬운 호스트명을 기계가 사용하는 IP 주소로 변환합니다.

  www.google.com → 172.217.18.36

• 인터넷의 중추 역할을 합니다.
• 계층적 네이밍 구조를 사용합니다 (예: .com, example.com, www.example.com, api.example.com).
• Domain Registrar – 도메인 이름을 판매하는 서비스 (예: Amazon Route 53, GoDaddy).
• DNS 레코드 – A, AAAA, CNAME, NS, …
• Zone File – 도메인의 DNS 레코드를 포함합니다.
• Name Server – DNS 질의를 해결합니다 (권한 있는 또는 비권한).
• Top‑Level Domain (TLD) – .com, .us, .in, .gov, .org, …
• Second‑Level Domain (SLD) – amazon.com, google.com, …

Source: …

Amazon Route 53 개요

• 고가용성, 확장성, 완전 관리형, 권한 있는 DNS 서비스.
• 권한 있음 – 고객(귀하)이 DNS 레코드를 업데이트할 수 있습니다.
• 또한 도메인 등록기관 역할을 수행합니다.
• 리소스의 상태를 확인할 수 있습니다.
• 100 % 가용성 SLA를 제공하는 유일한 AWS 서비스입니다.
• “53”이라는 이름은 전통적인 DNS 포트(53/TCP)를 의미합니다.

도메인에 대한 트래픽 라우팅

각 DNS 레코드에는 다음과 같은 항목이 포함됩니다:

Source:

Route 53에서 지원하는 DNS 레코드 유형

• A – 호스트 이름을 IPv4 주소에 매핑합니다.
• AAAA – 호스트 이름을 IPv6 주소에 매핑합니다.
• CNAME – 호스트 이름을 다른 호스트 이름에 매핑합니다.
  • 대상에는 A 또는 AAAA 레코드가 있어야 합니다.
  • 존 최상위에서는 사용할 수 없습니다 (예: example.com에 CNAME을 만들 수 없지만 www.example.com에는 만들 수 있습니다).

Name Server (NS) Records

• 호스티드 존에 대한 권한 있는 이름 서버를 정의합니다.

호스티드 영역

• 비용: 월 $0.50, 호스티드 영역당.

TTL (Time‑to‑Live)

Note: Alias 레코드를 제외하고는, 모든 DNS 레코드에 TTL이 필수입니다.

CNAME vs. Alias 레코드

예시 – AWS 로드 밸런서를 친숙한 이름에 매핑:

myapp.mydomain.com  →  lb-1234.us-east-2.elb.amazonaws.com   (Alias)

라우팅 정책 (Route 53이 DNS 쿼리에 응답하는 방식)

중요: DNS 라우팅은 로드 밸런서가 수행하는 트래픽 라우팅과 동일하지 않습니다. DNS는 IP 주소 또는 별칭만 반환하며, 클라이언트는 반환된 엔드포인트에 연결합니다.

상태 확인

• 목적: 엔드포인트(애플리케이션, 서버, AWS 리소스)의 상태를 모니터링하고 자동 DNS 장애 조치를 가능하게 합니다.
• 헬스 체크 유형:
  1. 엔드포인트 헬스 체크 – HTTP, HTTPS, 또는 TCP 프로브.
  2. 계산된 헬스 체크 – 여러 헬스 체크 결과를 결합합니다.
  3. CloudWatch 기반 헬스 체크 – CloudWatch 알람을 사용합니다(예: DynamoDB 스로틀링, RDS 알람, 사용자 정의 메트릭).

핵심 설정

헬스 체크 통합

• 헬스 체크는 가중치, 지연 시간 기반, 장애 조치, 다중 값 응답 정책을 사용하여 레코드에 연결할 수 있습니다.
• HTTP 헬스 체크는 공용 리소스에만 적용됩니다.
• 프라이빗 리소스는 계산된 또는 CloudWatch 기반 헬스 체크를 통해 모니터링할 수 있습니다.

팁: 방화벽이나 보안 그룹이 Route 53 헬스 체크 IP 범위에서 오는 인바운드 트래픽을 허용하도록 설정하세요.

빠른 참고용 치트‑시트

헬스 체크

• 여러 헬스 체크 결과를 결합하여 단일 헬스 체크로 만든다.
  • 논리 연산자: OR, AND, NOT.
• 최대 자식: 256개의 자식 헬스 체크.
• 통과 기준: 부모가 정상으로 간주되기 위해 자식 체크 중 몇 개가 통과해야 하는지 지정한다.
• 일반적인 사용 사례: 모든 헬스 체크가 실패하지 않도록 웹사이트를 유지보수한다.

Note: Route 53 헬스 체크는 VPC 외부에서 실행되므로 프라이빗 엔드포인트(프라이빗 VPC 리소스 또는 온프레미스 서버)에 접근할 수 없습니다.
프라이빗 리소스를 모니터링하려면 다음을 수행할 수 있습니다:

1. 프라이빗 엔드포인트의 상태를 반영하는 CloudWatch 메트릭을 생성합니다.
2. 해당 메트릭에 CloudWatch 알람을 연결합니다.
3. 그 알람 자체를 모니터링하는 Route 53 헬스 체크를 생성합니다.

Failover (Active‑Passive)

표준 Route 53 장애 조치 라우팅으로, 하나의 리소스는 기본(활성)이고 다른 하나는 대기(수동) 상태입니다.

지리 위치 라우팅

• 목적: 사용자 위치에 따라 트래픽을 라우팅합니다 (지연 시간 기반 라우팅과는 다름).
• 위치 세분화: 대륙, 국가, 미국 주 (지역이 겹칠 경우 가장 정밀한 매치가 우선).
• 기본 레코드: “Default” 레코드를 항상 생성하여 어떤 위치 규칙에도 일치하지 않는 요청을 잡아냅니다.
• 사용 사례:
  • 웹사이트 현지화
  • 지역별 콘텐츠 제한
  • 지역 간 로드 밸런싱
• 헬스 체크: 헬스 체크와 연동하여 정상적인 엔드포인트에만 트래픽이 전달되도록 할 수 있습니다.

지오프로시미티 라우팅

• 목표: 지리적 편향에 따라 트래픽을 리소스로 이동하거나 회피합니다.
• 지원되는 리소스:
  • AWS 리소스 – AWS 리전을 지정합니다.
  • 비‑AWS 리소스 – 위도와 경도를 지정합니다.
• 구현: **Route 53 Traffic Flow (고급)**가 필요합니다.
• 편향 값:
  • 양의 편향 (1 – 99): 지리적 영역을 확대 → 리소스로 더 많은 트래픽을 보냅니다.
  • 음의 편향 (‑1 – ‑99): 영역을 축소 → 리소스로 향하는 트래픽을 줄입니다.

IP 기반 라우팅 (CIDR 매핑)

• 작동 방식: 클라이언트의 IP 주소를 기준으로 트래픽을 라우팅합니다.
• 구성: CIDR 블록 목록을 제공하고 각 블록을 특정 엔드포인트/위치에 매핑합니다 (사용자 IP‑대‑엔드포인트 매핑).
• 사용 사례:
  • 사용자를 가장 가까운 엔드포인트로 보내 성능을 최적화합니다.
  • 네트워크 비용을 절감합니다.
  • 예시: 특정 ISP 사용자를 전용 엔드포인트로 직접 연결합니다.

멀티‑밸류 응답 라우팅

• 사용 시점: 동일한 요청을 처리할 수 있는 여러 리소스가 있는 경우.
• 동작: Route 53은 각 쿼리마다 최대 8개의 정상 레코드를 반환합니다.
• 헬스 체크: 연결할 수 있으며, 정상 레코드만 반환됩니다.
• 중요: 이는 Elastic Load Balancer (ELB) 를 대체하는 것이 아님을 유의하십시오.

도메인 등록 vs. DNS 서비스

일반적인 흐름:

1. 구입: 모든 레지스트라(제3자 레지스트라 포함)에서 도메인을 구입합니다.
2. Route 53에서 Hosted Zone을 생성합니다.
3. 레지스트라에서 NS 레코드를 업데이트하여 Route 53 네임 서버를 가리키게 합니다.

핵심 요점: Domain registrar ≠ DNS service. 많은 레지스트라가 DNS를 번들로 제공하지만, 원하는 어떤 DNS 제공자든 자유롭게 사용할 수 있습니다.

Route 53 Resolver (Hybrid DNS)

기본적으로 Resolver는 다음에 대한 DNS 쿼리에 자동으로 응답합니다:

• EC2 인스턴스의 로컬 도메인 이름.
• Private Hosted Zones의 레코드.
• Public Name Servers의 레코드.

연결할 수 있는 네트워크 유형

• VPC (피어링된 VPC 포함).
• 온프레미스 네트워크 (AWS Direct Connect 또는 AWS VPN를 통해).

엔드포인트

이러한 엔드포인트를 통해 하이브리드 DNS 아키텍처를 구축할 수 있으며, AWS와 외부 네트워크 전반에 걸쳐 이름을 원활하게 해결할 수 있습니다.