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 전용 레코드 |
| 헬스체크 | 엔드포인트 상태를 주기적으로 점검 |
| 라우팅 정책 | 같은 이름의 여러 레코드 중 어떤 응답을 줄지 결정 |
호스팅 영역 생성
# 퍼블릭 호스팅 영역 생성
aws route53 create-hosted-zone \
--name example.com \
--caller-reference "$(date +%s)"생성하면 Route 53이 네임서버(NS) 4개를 할당합니다. 도메인 등록 기관(레지스트라)의 NS를 이 값으로 바꿔야 위임이 완성됩니다.
# 할당된 네임서버 확인
aws route53 get-hosted-zone --id Z123456ABCDEFG \
--query 'DelegationSet.NameServers'레코드 타입
| 타입 | 용도 |
|---|---|
| A | 도메인 → IPv4 |
| AAAA | 도메인 → IPv6 |
| CNAME | 도메인 → 다른 도메인(별칭). 루트(zone apex)에는 불가 |
| Alias | AWS 리소스 지정. 루트에도 사용 가능, 조회 비용 없음 |
| MX | 메일 서버 |
| TXT | SPF·도메인 인증 등 텍스트 |
| NS | 하위 영역 위임 |
| SRV | 서비스 위치 |
루트 도메인(example.com)을 ELB나 CloudFront에 연결할 때 CNAME은 사용할 수 없습니다. 이때 Route 53의 Alias 레코드를 쓰면 zone apex에서도 AWS 리소스를 가리킬 수 있고 추가 조회 요금도 들지 않습니다.
CLI로 레코드 변경
Route 53의 레코드 변경은 JSON 변경 배치를 change-resource-record-sets에 전달하는 방식입니다.
# 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.jsonAction은 CREATE, DELETE, UPSERT(있으면 갱신, 없으면 생성)를 지원합니다. UPSERT가 멱등성 측면에서 가장 안전합니다.
헬스체크
라우팅 정책 중 일부는 헬스체크와 결합해 동작합니다. 엔드포인트가 정상일 때만 해당 레코드를 응답에 포함시킵니다.
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
}'| 설정 | 의미 |
|---|---|
Type | HTTP / HTTPS / TCP / 문자열 매칭 등 |
ResourcePath | 점검할 경로(예: /health) |
RequestInterval | 점검 주기(초). 10 또는 30 |
FailureThreshold | 연속 N회 실패 시 비정상 판정 |
헬스체크는 전 세계 다수 지점에서 수행됩니다. 방화벽/보안그룹에서 Route 53 헬스체커의 IP 대역과 점검 경로(/health)를 허용해야 정상으로 인식됩니다.
라우팅 정책
같은 이름·타입의 레코드를 여러 개 두고, 어느 응답을 반환할지 정하는 규칙입니다. Route 53의 핵심 기능입니다.
1) Simple (단순)
가장 기본. 레코드 하나에 값을 지정하고 그대로 응답합니다. 값이 여러 개면 무작위로 섞어 반환합니다(라우팅 제어 없음).
2) Weighted (가중치)
여러 엔드포인트에 비율로 트래픽을 분산합니다. A/B 테스트나 점진적 배포(canary)에 적합합니다.
{
"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 속성을 지정합니다.
{
"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로 응답합니다. 액티브-스탠바이 구성에 씁니다.
{
"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 (지리적 위치)
사용자의 위치(대륙/국가/지역) 에 따라 다른 응답을 줍니다. 콘텐츠 현지화나 규제 준수에 사용합니다.
{
"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 | 최저 지연 리전 | 선택 | 멀티 리전 성능 |
| Failover | Primary 상태 | 필수 | 액티브-스탠바이 |
| Geolocation | 사용자 위치 | 선택 | 현지화·규제 |
| Geoproximity | 위치 + 편향(bias) | 선택 | 지역 트래픽 미세 조정 |
| Multivalue | 정상 레코드 무작위 반환 | 선택 | 단순 분산 + 상태 점검 |
TTL 설계 팁
| 상황 | 권장 TTL |
|---|---|
| 자주 바뀌지 않는 레코드 | 3600초 이상 |
| Failover / Weighted 등 변경 잦음 | 60초 내외 |
| 마이그레이션 직전 | 미리 낮춰두기(예: 60초) |
Alias 레코드는 TTL을 직접 설정하지 않습니다. 대상 AWS 리소스의 TTL을 따릅니다.
정리
| 항목 | 핵심 |
|---|---|
| 호스팅 영역 | 도메인별 레코드 모음, 퍼블릭/프라이빗 |
| Alias | zone apex에서 AWS 리소스 지정, 조회 비용 없음 |
| 레코드 변경 | change-resource-record-sets + UPSERT |
| 헬스체크 | 경로·주기·임계치 지정, Failover의 전제 |
| Weighted | 비율 분산(카나리/AB) |
| Latency | 최저 지연 리전 선택 |
| Failover | Primary 헬스체크 기반 장애 조치 |
| Geolocation | 사용자 위치 기반 + 기본(*) 레코드 필수 |
Route 53의 진짜 가치는 단순 DNS가 아니라 라우팅 정책과 헬스체크의 조합에 있습니다. 멀티 리전 서비스라면 Latency + Failover를, 점진적 배포라면 Weighted를 적용해 가용성과 사용자 경험을 동시에 끌어올릴 수 있습니다.
이 가이드는 AI 도구를 활용해 초안을 구성하고 사람이 명령어·문맥을 검토해 발행했습니다. 운영체제와 도구 버전에 따라 결과가 달라질 수 있으므로 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요.
질문 & 답변 (Q&A)
이 가이드에 대해 궁금한 점을 질문해보세요. 확인 후 답변드립니다.