Route 53 — 도메인과 DNS

11장 RDS까지 백엔드의 컴퓨팅 / 스토리지 / DB 영역을 잡았습니다. 본 챕터는 사용자가 우리 시스템을 처음 만나는 지점인 DNS입니다. AWS의 매니지드 DNS가 Route 53으로, 이름은 DNS가 쓰는 53 포트에서 따왔습니다.

본 챕터에서는 DNS의 큰 그림에서 시작해 Route 53의 구조, 레코드 종류(특히 Alias), 라우팅 정책, 헬스 체크까지 한 줄로 정리합니다. 여기서 만드는 Alias 레코드는 13장 ALB / NLB와 ACM의 로드 밸런서와 14장 CloudFront의 배포를 도메인에 연결하는 마지막 조각이 됩니다.

DNS의 동작 — 5초 복습 #

DNS는 example.com을 IP로 매핑하는 기능입니다. 브라우저가 example.com을 치면 다음이 일어납니다.

1. 브라우저: `example.com` 캐시 확인 → 없음
2. OS: `/etc/hosts` → 없음
3. OS: 시스템 DNS resolver (보통 라우터, 또는 1.1.1.1)
4. resolver: 캐시 확인 → 없음 → root → .com TLD → example.com 의 NS
5. example.com 의 NS = Route 53 → A 레코드 → 192.0.2.10
6. 응답이 거꾸로 돌아오며 캐시

이 그림에서 5번 지점, 즉 도메인의 권한 있는(authoritative) DNS가 Route 53입니다.

TTL의 의미 #

각 레코드에는 **TTL (Time To Live)**이 붙습니다. resolver와 브라우저가 얼마나 캐시할지를 정합니다.

TTL이 길면 응답이 빠르고 비용이 적지만, 변경이 전 세계에 퍼지는 시간도 깁니다. 운영 cutover 시점에는 TTL을 미리 줄여 두는 것이 일반적입니다.

Route 53의 구조 #

Route 53의 구성 요소는 다음과 같습니다.

도메인 등록 vs Hosted Zone #

자주 헷갈리는 부분입니다. 도메인을 어디서 샀는지(Registrar)와 DNS를 어디서 푸는지(Hosted Zone)는 별개입니다.

가비아 (Registrar):
  example.com 의 NS = ns-1234.awsdns-56.com  ← Route 53 NS 로 지정
                       ns-2345.awsdns-67.org
                       ns-3456.awsdns-78.net
                       ns-4567.awsdns-89.co.uk

Route 53 Hosted Zone:
  example.com.
    NS    ns-1234... (자동 생성)
    SOA   ... (자동 생성)
    A     www → 192.0.2.10
    A     api → 198.51.100.20

다른 곳에서 산 도메인을 Route 53으로 옮기는 절차는 다음과 같습니다.

1. Route 53에 Public Hosted Zone을 만듭니다. 자동으로 네 개의 NS가 부여됩니다.
2. 그 NS 네 개를 Registrar 콘솔의 NS 항목에 입력합니다.
3. 전파를 기다립니다(수 분 ~ 24시간).
4. dig나 nslookup으로 확인합니다.

Hosted Zone의 종류 #

Public Hosted Zone #

인터넷 어디서나 풀 수 있는 DNS입니다. 일반적인 공개 DNS입니다.

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference $(date +%s)

Private Hosted Zone #

VPC 안에서만 풀리는 DNS입니다. 내부 서비스 디스커버리에 씁니다.

내부 도메인: api.internal.example.com → 10.0.10.100 (앱 EC2)
                db.internal.example.com → RDS endpoint

VPC의 EC2만 풀 수 있고 인터넷에서는 안 풀립니다. 사내 마이크로서비스에 매끄럽습니다.

레코드 종류 #

A / AAAA — 도메인을 IP로 #

가장 기본입니다.

A     api.example.com.    300   192.0.2.10        (IPv4)
AAAA  api.example.com.    300   2001:db8::10      (IPv6)

CNAME — 도메인을 도메인으로 #

다른 도메인의 별칭입니다.

CNAME  www.example.com.    300   example.com.
CNAME  blog.example.com.   300   ghs.googlehosted.com.

제한은 다음과 같습니다.

• 루트 도메인(example.com 자체)에는 CNAME이 안 됩니다(DNS 표준의 한계).
• CNAME이 있으면 다른 레코드(MX, TXT 같은)와 공존할 수 없습니다.

루트 도메인을 ALB나 CloudFront로 보내고 싶을 때 CNAME을 못 씁니다. 이때 Alias가 등장합니다.

Alias — Route 53 만의 구조 #

Alias는 Route 53이 만든 비표준 레코드입니다. DNS 응답 시점에는 A / AAAA처럼 IP를 반환합니다. CNAME의 한계를 우회합니다.

A   example.com.   ALIAS  d111111abcdef8.cloudfront.net    (CloudFront)
A   www.example.com. ALIAS my-alb-1234567890.elb.amazonaws.com  (ALB)
A   shop.example.com. ALIAS my-bucket.s3-website-ap-northeast-2.amazonaws.com (S3)

특징은 다음과 같습니다.

• 루트 도메인에서도 사용할 수 있습니다.
• 무료입니다(CNAME은 쿼리당 과금이지만 Alias는 AWS 리소스를 가리키면 무료입니다).
• 자동 IP 갱신 — ALB와 CloudFront는 IP가 동적인데 Alias가 따라갑니다.

Alias는 AWS 리소스만 가리킬 수 있습니다(ALB, NLB, CloudFront, API Gateway, S3 website, 같은 zone의 다른 레코드 등). 외부 도메인은 CNAME을 써야 합니다.

MX — 메일 #

MX  example.com.   300   10 inbound-smtp.us-east-1.amazonaws.com.
                          20 inbound-smtp.us-east-2.amazonaws.com.

10, 20은 우선순위로, 작은 값이 우선입니다. SES / Google Workspace / Microsoft 365의 SMTP 호스트를 가리킵니다.

TXT — 텍스트 #

도메인 검증 / SPF / DKIM 등에 씁니다.

TXT   example.com.   300   "v=spf1 include:_spf.google.com ~all"
TXT   _dmarc.example.com. 300  "v=DMARC1; p=quarantine; rua=mailto:..."
TXT   _acme-challenge.example.com. 300  "lemonjuice123..." (Let's Encrypt 검증)

NS / SOA — 자동 #

Hosted Zone을 만들 때 자동 생성됩니다. 거의 안 만집니다.

CAA — 인증서 발급 권한 #

어느 CA가 이 도메인 인증서를 발급할 수 있는지 제한합니다.

CAA  example.com.  300  0 issue "amazon.com"

ACM(13장)으로 인증서를 발급받을 때 CAA가 막혀 있으면 실패하니 주의합니다.

라우팅 정책 — Route 53의 진짜 매력 #

같은 도메인에 여러 IP를 다른 조건으로 응답할 수 있습니다.

Simple Routing #

가장 단순합니다. 한 도메인을 한 개 또는 여러 IP로 보냅니다. 여러 IP 일 때 라운드로빈입니다.

Weighted Routing — 비중 분산 #

각 레코드에 가중치를 둬서 비율로 나눕니다. 카나리 배포에 유용합니다.

A   api.example.com   ALIAS   alb-v1.elb...   weight=90
A   api.example.com   ALIAS   alb-v2.elb...   weight=10

Latency Routing — 가까운 리전으로 #

여러 리전에 같은 서비스를 띄우고 사용자를 가장 가까운 리전으로 라우팅합니다.

A   api.example.com   ALIAS   alb-seoul...   region=ap-northeast-2
A   api.example.com   ALIAS   alb-tokyo...   region=ap-northeast-1
A   api.example.com   ALIAS   alb-virginia...region=us-east-1

한국 사용자는 서울로, 일본 사용자는 도쿄로, 미국 사용자는 버지니아로 갑니다.

Failover Routing — 자동 페일오버 #

Primary와 Secondary 두 대상을 두고, Primary가 health check에 실패하면 Secondary로 보냅니다.

A   api.example.com   ALIAS   alb-prod-seoul...   PRIMARY   health-check=HC1
A   api.example.com   ALIAS   alb-dr-tokyo...     SECONDARY

Geolocation Routing — 국가 / 대륙별 #

사용자의 지리적 위치로 라우팅합니다. 컴플라이언스나 콘텐츠 차이에 씁니다.

A   api.example.com   ALIAS   alb-kr...   geolocation=KR (Korea)
A   api.example.com   ALIAS   alb-jp...   geolocation=JP (Japan)
A   api.example.com   ALIAS   alb-default... geolocation=DEFAULT (그 외)

Geoproximity Routing #

지리에 bias를 더합니다. AWS 내부 알고리즘이 더 복잡합니다. 거의 안 만집니다.

Multivalue Answer Routing #

여러 IP를 무작위로 응답합니다. Health check와 결합해 살아 있는 IP만 반환합니다. 단순한 클라이언트 측 부하 분산입니다.

정책 결정 가이드 #

한 개만이면 → Simple
배포 비중을 나누고 싶다 → Weighted
여러 리전 중 가까운 곳 → Latency
DR / 백업 용도 → Failover
국가 단위 컴플라이언스 → Geolocation
DNS 단 부하 분산 → Multivalue

Health Check #

라우팅 정책의 핵심 동반자입니다. 엔드포인트가 살아 있는지 30초마다 체크합니다.

aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "ResourcePath": "/health",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

종류는 다음과 같습니다.

• HTTP / HTTPS / TCP — 직접 엔드포인트를 체크합니다.
• Calculated — 다른 health check 들의 AND / OR 조합입니다.
• CloudWatch Alarm 기반 — 알람 상태로 판단합니다.

Health Check는 Failover 라우팅의 자동 전환 트리거이자 Multivalue 라우팅의 살아 있는 IP 필터입니다. 단독으로 쓸 수도 있지만 보통 라우팅 정책과 결합합니다.

도메인 운영 — 자주 쓰는 패턴 #

메인 사이트 + 서브도메인 #

A      example.com.        ALIAS   www.example.com.    (root → www)
A      www.example.com.    ALIAS   d111...cloudfront.net
A      api.example.com.    ALIAS   alb-prod...elb.amazonaws.com
A      app.example.com.    ALIAS   d222...cloudfront.net
TXT    _dmarc.example.com. "v=DMARC1; p=reject; ..."
MX     example.com.        10 inbound-smtp.ses-us-east-1.amazonaws.com.

환경별 분리 #

api.dev.example.com       ← dev 환경 ALB
api.staging.example.com   ← staging
api.example.com           ← prod

또는 별도 Hosted Zone으로 dev.example.com을 둘 수도 있습니다. 권한 위임이 깔끔해집니다.

Apex (루트) 도메인의 ALB / S3 #

CNAME을 못 쓰는 경우는 Alias를 씁니다. ALB의 zone이 자동으로 매칭됩니다(콘솔에서 드롭다운).

비용 #

작은 사이트는 월 $1~2 수준입니다.

자주 만나는 함정 #

• NS 변경 안 했는데 Route 53만 만짐 — Hosted Zone을 만들었지만 Registrar의 NS가 여전히 옛 값이면 변경이 전혀 반영되지 않습니다. NS 네 개를 Registrar에 입력했는지 dig NS example.com +short로 확인합니다.
• Apex CNAME 시도 — example.com CNAME myapp.heroku.com은 거부됩니다. Alias는 AWS 리소스만 가리킵니다. 외부 서비스가 루트 도메인에 와야 한다면 그 서비스가 ALIAS 류 기능을 제공하거나(예: CloudFlare CNAME flattening), 별도 리다이렉터(S3 redirect로 Apex를 www로) 패턴을 씁니다.
• TTL이 너무 길어 cutover가 느려짐 — 운영 cutover(예: ALB 교체) 직전에는 TTL을 60초 정도로 낮추고, 안정화 후 다시 올립니다. 미리 안 낮추면 옛 IP가 24시간 캐시될 수 있습니다.
• Health Check가 false positive — 체크 경로가 인증을 요구하면 항상 401이 나와 unhealthy가 됩니다. /health 같은 공개 엔드포인트를 둡니다.
• Failover 인데 health check 안 붙임 — PRIMARY 레코드에 health check가 없으면 자동 페일오버가 안 됩니다. 콘솔의 “evaluate target health” 옵션을 빠뜨리는 실수가 흔합니다.
• DNSSEC 켜고 잊기 — DNSSEC의 KSK / ZSK 회전을 잊으면 도메인 풀이 자체가 실패합니다. 켜는 경우는 신중하게 자동화와 함께 합니다.
• Private Hosted Zone의 풀이가 VPC에서 안 됨 — VPC의 enableDnsHostnames / enableDnsSupport가 꺼져 있으면 Private Hosted Zone이 안 풀립니다. 둘 다 true인지 확인합니다.
• MX의 우선순위 문법 실수 — MX 10 mail.example.com.에서 10 항목을 빠뜨리면 풀이 자체가 깨집니다.

연습문제 #

1. 본인 도메인을 다른 등록 업체에서 샀다고 가정하고, 그 DNS를 Route 53으로 옮기는 네 단계를 §“도메인 등록 vs Hosted Zone"을 보지 않고 적어 보세요. 그중 어느 단계를 빠뜨리면 §“자주 만나는 함정"의 첫 항목이 되는지 표시하세요.
2. 루트 도메인 example.com을 CloudFront 배포에 연결하려고 합니다. CNAME이 안 되는 이유와 Alias가 되는 이유를 §“CNAME"과 §“Alias"를 근거로 한 단락으로 설명하고, 그 Alias가 14장 CloudFront 배포를 어떻게 가리키는지 한 줄 덧붙이세요.
3. 서울과 도쿄에 같은 서비스를 두고 한 리전이 죽으면 다른 리전으로 넘기려 합니다. §“라우팅 정책"의 일곱 가지 중 어느 것을 골라야 하는지, 그리고 §“Health Check"가 왜 함께 필요한지 적어 보세요.

한 줄 요약: Route 53은 매니지드 DNS로, 도메인을 어디서 샀는지(Registrar)와 DNS를 어디서 푸는지(Hosted Zone)는 별개이며 Registrar의 NS를 Route 53 NS로 가리키는 것이 시작이다. Alias는 Route 53 만의 레코드로 루트 도메인에서도 쓰이고 AWS 리소스를 가리키면 무료다. 라우팅 정책 일곱 가지 중 Failover와 Multivalue는 Health Check가 자동 전환 트리거가 된다.

다음 챕터 #

DNS의 큰 그림은 잡았습니다. 다음 13장 ALB / NLB와 ACM에서는 그 도메인이 가리키는 곳인 로드 밸런서와 HTTPS로 이어집니다. ALB / NLB / GWLB의 차이, Listener / Target Group / Health Check의 흐름, ACM의 인증서 발급과 자동 갱신, HTTPS의 운영 패턴을 정리합니다.