AWS 중급 #5 Route 53: 도메인과 DNS

#4 RDS까지 백엔드의 컴퓨팅 / 스토리지 / DB 영역을 잡았습니다. 이제 사용자가 우리 시스템을 처음 만나는 관문, DNS입니다. AWS의 매니지드 DNS가 Route 53입니다 (TCP 53 포트의 DNS에서 따옴).

이 글에선 DNS의 큰 그림 → Route 53의 구조 → 레코드 종류 (특히 Alias) → 라우팅 정책 → 헬스 체크까지 한 줄로 정리합니다.

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 만들기. 자동으로 4개의 NS 부여
2. 그 NS 4개를 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 (#6)으로 인증서를 발급 받을 때 CAA가 막혀 있으면 실패하니 주의.

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

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

1) Simple Routing #

가장 단순합니다. 한 도메인 → 한 / 여러 IP. 여러 IP일 때 라운드로빈으로 응답합니다.

2) Weighted Routing: 비중 분산 #

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

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

3) 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-tokyo...   region=us-east-1

한국 사용자 → 서울, 일본 사용자 → 도쿄, 미국 사용자 → 버지니아.

4) 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

5) 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 (그 외)

6) Geoproximity Routing #

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

7) 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 필터
• 단독으로 쓸 수도 있지만 보통 라우팅 정책과 결합

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

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

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.

2) 환경별 분리 #

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

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

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

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

비용 #

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

자주 만나는 함정 #

1) NS 변경 안 했는데 Route 53만 만짐 #

Hosted Zone을 만들었지만 Registrar의 NS가 여전히 옛 값이면 변경이 전혀 반영되지 않습니다. NS 4개를 Registrar에 입력했는지 확인하세요.

dig NS example.com +short

2) Apex CNAME 시도 #

example.com CNAME myapp.heroku.com → 거부됨. Alias는 AWS 리소스만. 외부 서비스 (Heroku 등)가 루트 도메인에 와야 한다면 그 서비스가 ALIAS 류 기능을 제공 하거나 (예: CloudFlare CNAME flattening), 별도 리다이렉터 (S3 redirect → Apex → www) 패턴.

3) TTL 너무 길어서 cutover가 느려집니다 #

운영 cutover (예: ALB 교체) 직전엔 TTL을 60초 정도로 낮추고, 안정화 후 다시 올리기. 미리 안 낮추면 옛 IP가 24시간 캐시될 수 있음.

4) Health Check가 false positive #

체크 경로가 인증을 요구하는 경우면 항상 401 → unhealthy. /health 같은 공개 엔드포인트를 두기.

5) Failover 인데 health check 안 붙임 #

PRIMARY 레코드에 health check가 없으면 자동 페일오버 안 됩니다. 콘솔이 “evaluate target health” 옵션를 빠뜨리는 실수가 흔합니다.

6) DNSSEC 켜고 잊기 #

DNSSEC의 KSK / ZSK 회전을 잊으면 도메인 풀이 자체가 실패합니다. 켜는 경우는 신중하게 / 자동화와 함께.

7) Private Hosted Zone의 풀이가 VPC에서 안 됨 #

VPC의 **enableDnsHostnames / enableDnsSupport**가 꺼져 있으면 Private Hosted Zone이 안 풀립니다. 둘 다 true 확인.

8) MX의 우선순위 문법 실수 #

MX 10 mail.example.com.에서 10 항목 빠뜨리면 풀이 자체가 깨짐.

정리 #

이번 글에서 잡은 것:

• Route 53 = AWS의 매니지드 DNS. Domain Registration / Hosted Zone / Health Check / Resolver의 4가지 구성
• Domain Registrar ↔ Hosted Zone은 별개. Registrar의 NS를 Route 53 NS로 가리키는 게 시작
• Public Hosted Zone = 인터넷 풀이, Private Hosted Zone = VPC 안만
• A / AAAA / CNAME / TXT / MX / NS / SOA / CAA가 일반 레코드
• Alias는 Route 53만의 기능. 루트 도메인에서도 가능, AWS 리소스 가리키면 무료, IP 자동 갱신
• 라우팅 정책 7종. Simple / Weighted / Latency / Failover / Geolocation / Geoproximity / Multivalue
• Health Check는 Failover / Multivalue 라우팅의 자동 전환 트리거
• 운영 패턴. 환경별 서브도메인 / 별도 Hosted Zone / Apex의 Alias
• 함정. NS 갱신, Apex CNAME, TTL 큰 채 cutover, health check false positive, Multi-AZ + Failover, Private Hosted Zone DNS 옵션, MX 문법

다음: ALB / NLB / ACM #

DNS의 큰 그림은 잡았습니다. 이제 그 도메인이 가리키는 곳, 로드 밸런서와 HTTPS로 이어집니다.

#6 ALB / NLB와 ACM (HTTPS)에서는 ALB / NLB / GWLB의 차이, Listener / Target Group / Health Check의 흐름, ACM의 인증서 발급과 자동 갱신, HTTPS의 운영 패턴을 정리하겠습니다.