/엔지니어/클라우드/AWS Route 53 — DNS·라우팅 정책·헬스
클라우드중급linuxawsroute53dns

AWS Route 53 — DNS·라우팅 정책·헬스체크 완전 가이드

AWS Route 53의 호스팅 영역과 레코드 타입, 그리고 simple·weighted·latency·failover·geolocation 라우팅 정책을 헬스체크와 함께 설명합니다. AWS CLI로 레코드를 관리하고 장애 조치·트래픽 분산을 구성하는 실전 가이드입니다.

AWS Route 53 란?

Route 53은 AWS의 관리형 DNS 서비스입니다. 도메인 이름을 IP나 AWS 리소스로 변환해 주는 일반 DNS 기능에 더해, 트래픽 라우팅 정책헬스체크 기반 장애 조치(failover) 를 제공한다는 점이 특징입니다. 이름의 53은 DNS가 사용하는 UDP/TCP 포트 번호에서 따온 것입니다.

이 가이드는 AWS 환경에서 DNS를 운영하는 관점에 집중합니다. 클라이언트에서 dig로 레코드를 조회하는 방법이나 Cloudflare DNS 설정과는 별개로, Route 53 고유의 라우팅 정책·헬스체크를 어떻게 설계·구성하는지를 다룹니다.


핵심 구성 요소

요소설명
호스팅 영역(Hosted Zone)한 도메인(예: example.com)의 레코드 모음
퍼블릭 호스팅 영역인터넷에 공개된 DNS
프라이빗 호스팅 영역특정 VPC 내부에서만 해석되는 DNS
레코드(Record)A, AAAA, CNAME, MX 등 실제 DNS 항목
Alias 레코드AWS 리소스(ELB, CloudFront, S3 등)를 가리키는 Route 53 전용 레코드
헬스체크엔드포인트 상태를 주기적으로 점검
라우팅 정책같은 이름의 여러 레코드 중 어떤 응답을 줄지 결정

호스팅 영역 생성

Bash
# 퍼블릭 호스팅 영역 생성
aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "$(date +%s)"

생성하면 Route 53이 네임서버(NS) 4개를 할당합니다. 도메인 등록 기관(레지스트라)의 NS를 이 값으로 바꿔야 위임이 완성됩니다.

Bash
# 할당된 네임서버 확인
aws route53 get-hosted-zone --id Z123456ABCDEFG \
  --query 'DelegationSet.NameServers'

레코드 타입

타입용도
A도메인 → IPv4
AAAA도메인 → IPv6
CNAME도메인 → 다른 도메인(별칭). 루트(zone apex)에는 불가
AliasAWS 리소스 지정. 루트에도 사용 가능, 조회 비용 없음
MX메일 서버
TXTSPF·도메인 인증 등 텍스트
NS하위 영역 위임
SRV서비스 위치

루트 도메인(example.com)을 ELB나 CloudFront에 연결할 때 CNAME은 사용할 수 없습니다. 이때 Route 53의 Alias 레코드를 쓰면 zone apex에서도 AWS 리소스를 가리킬 수 있고 추가 조회 요금도 들지 않습니다.


CLI로 레코드 변경

Route 53의 레코드 변경은 JSON 변경 배치를 change-resource-record-sets에 전달하는 방식입니다.

Bash
# change-batch.json
cat > change-batch.json <<'JSON'
{
  "Comment": "웹 서버 A 레코드 추가",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{ "Value": "203.0.113.10" }]
      }
    }
  ]
}
JSON

aws route53 change-resource-record-sets \
  --hosted-zone-id Z123456ABCDEFG \
  --change-batch file://change-batch.json

ActionCREATE, DELETE, UPSERT(있으면 갱신, 없으면 생성)를 지원합니다. UPSERT가 멱등성 측면에서 가장 안전합니다.


헬스체크

라우팅 정책 중 일부는 헬스체크와 결합해 동작합니다. 엔드포인트가 정상일 때만 해당 레코드를 응답에 포함시킵니다.

Bash
aws route53 create-health-check \
  --caller-reference "$(date +%s)" \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "www.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'
설정의미
TypeHTTP / HTTPS / TCP / 문자열 매칭 등
ResourcePath점검할 경로(예: /health)
RequestInterval점검 주기(초). 10 또는 30
FailureThreshold연속 N회 실패 시 비정상 판정

헬스체크는 전 세계 다수 지점에서 수행됩니다. 방화벽/보안그룹에서 Route 53 헬스체커의 IP 대역과 점검 경로(/health)를 허용해야 정상으로 인식됩니다.


라우팅 정책

같은 이름·타입의 레코드를 여러 개 두고, 어느 응답을 반환할지 정하는 규칙입니다. Route 53의 핵심 기능입니다.

1) Simple (단순)

가장 기본. 레코드 하나에 값을 지정하고 그대로 응답합니다. 값이 여러 개면 무작위로 섞어 반환합니다(라우팅 제어 없음).

2) Weighted (가중치)

여러 엔드포인트에 비율로 트래픽을 분산합니다. A/B 테스트나 점진적 배포(canary)에 적합합니다.

JSON
{
  "Action": "UPSERT",
  "ResourceRecordSet": {
    "Name": "app.example.com", "Type": "A", "TTL": 60,
    "SetIdentifier": "v2-canary",
    "Weight": 10,
    "ResourceRecords": [{ "Value": "203.0.113.20" }]
  }
}

Weight가 90인 레코드와 10인 레코드를 두면 약 9:1로 분산됩니다. SetIdentifier로 같은 이름의 레코드들을 구분합니다.

3) Latency (지연 시간 기반)

여러 AWS 리전에 리소스가 있을 때, 사용자에게 가장 지연이 낮은 리전으로 보냅니다. Region 속성을 지정합니다.

JSON
{
  "Name": "api.example.com", "Type": "A", "TTL": 60,
  "SetIdentifier": "seoul",
  "Region": "ap-northeast-2",
  "ResourceRecords": [{ "Value": "203.0.113.30" }]
}

4) Failover (장애 조치)

Primary/Secondary 두 레코드를 두고, 헬스체크가 정상이면 Primary로, 비정상이면 Secondary로 응답합니다. 액티브-스탠바이 구성에 씁니다.

JSON
{
  "Name": "www.example.com", "Type": "A", "TTL": 60,
  "SetIdentifier": "primary",
  "Failover": "PRIMARY",
  "HealthCheckId": "abcd-1234-health",
  "ResourceRecords": [{ "Value": "203.0.113.10" }]
}

Failover의 Primary 레코드에는 반드시 헬스체크를 연결해야 합니다. 헬스체크가 없으면 Route 53은 Primary를 항상 정상으로 간주해 절대 Secondary로 넘어가지 않습니다.

5) Geolocation (지리적 위치)

사용자의 위치(대륙/국가/지역) 에 따라 다른 응답을 줍니다. 콘텐츠 현지화나 규제 준수에 사용합니다.

JSON
{
  "Name": "www.example.com", "Type": "A", "TTL": 60,
  "SetIdentifier": "korea",
  "GeoLocation": { "CountryCode": "KR" },
  "ResourceRecords": [{ "Value": "203.0.113.40" }]
}

Geolocation을 쓸 때는 어떤 지역에도 매칭되지 않는 사용자를 위한 기본 레코드("CountryCode": "*") 를 반드시 만들어 두세요. 없으면 매칭 안 되는 사용자에게 응답이 없습니다.

정책 비교

정책결정 기준헬스체크대표 용도
Simple없음선택단일 엔드포인트
Weighted가중치 비율선택A/B, 카나리 배포
Latency최저 지연 리전선택멀티 리전 성능
FailoverPrimary 상태필수액티브-스탠바이
Geolocation사용자 위치선택현지화·규제
Geoproximity위치 + 편향(bias)선택지역 트래픽 미세 조정
Multivalue정상 레코드 무작위 반환선택단순 분산 + 상태 점검

TTL 설계 팁

상황권장 TTL
자주 바뀌지 않는 레코드3600초 이상
Failover / Weighted 등 변경 잦음60초 내외
마이그레이션 직전미리 낮춰두기(예: 60초)

Alias 레코드는 TTL을 직접 설정하지 않습니다. 대상 AWS 리소스의 TTL을 따릅니다.


정리

항목핵심
호스팅 영역도메인별 레코드 모음, 퍼블릭/프라이빗
Aliaszone apex에서 AWS 리소스 지정, 조회 비용 없음
레코드 변경change-resource-record-sets + UPSERT
헬스체크경로·주기·임계치 지정, Failover의 전제
Weighted비율 분산(카나리/AB)
Latency최저 지연 리전 선택
FailoverPrimary 헬스체크 기반 장애 조치
Geolocation사용자 위치 기반 + 기본(*) 레코드 필수

Route 53의 진짜 가치는 단순 DNS가 아니라 라우팅 정책과 헬스체크의 조합에 있습니다. 멀티 리전 서비스라면 Latency + Failover를, 점진적 배포라면 Weighted를 적용해 가용성과 사용자 경험을 동시에 끌어올릴 수 있습니다.

#aws#route53#dns#routing-policy#health-check
편집 안내 · Editorial Note

이 가이드는 AI 도구를 활용해 초안을 구성하고 사람이 명령어·문맥을 검토해 발행했습니다. 운영체제와 도구 버전에 따라 결과가 달라질 수 있으므로 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요.

관련 공식 문서AWS 공식 문서

질문 & 답변 (Q&A)

이 가이드에 대해 궁금한 점을 질문해보세요. 확인 후 답변드립니다.