AWS Route 53 완전 정복: 도메인 이름 하나로 전 세계를 연결하는 법

들어가며: IP 주소 대신 이름으로 — DNS가 왜 필요한가

인터넷에 연결된 모든 서버에는 IP 주소가 있다. 예를 들어 142.250.196.110은 Google 서버의 주소다. 하지만 우리는 이 숫자를 외우지 않는다. 대신 google.com이라고 입력한다.

이것이 가능한 이유는 DNS(Domain Name System) 때문이다. DNS는 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 이해하는 IP 주소로 변환하는 시스템이다. 인터넷의 전화번호부라고 생각하면 된다.

그런데 이 전화번호부가 단순하지 않다. 전 세계 수십억 개의 도메인을 실시간으로 처리해야 하고, DNS가 멈추면 웹사이트도, 이메일도, API도 전부 멈춘다.

AWS Route 53은 아마존이 제공하는 관리형 DNS 서비스다. 도메인 이름을 IP 주소로 바꿔주는 것에 그치지 않고, 도메인 등록, 지능형 트래픽 라우팅, 서버 상태 모니터링까지 한다. 이 글에서는 Route 53의 이름 유래부터 핵심 기능, 6가지 라우팅 정책, 실전 아키텍처, 비용 구조까지 모든 것을 다룬다.

1. Why "Route 53"? — 이름에 숨겨진 두 가지 의미

AWS 서비스 이름은 보통 직관적이다. S3(Simple Storage Service), EC2(Elastic Compute Cloud), RDS(Relational Database Service). 그런데 Route 53은 좀 다르다. 숫자 53은 어디서 온 걸까?

첫 번째 의미: DNS 포트 번호 53

인터넷에서 데이터가 오갈 때는 포트(port) 번호를 사용한다. 웹 트래픽은 80번(HTTP) 또는 443번(HTTPS), 이메일 전송은 25번(SMTP)을 쓴다. DNS는 53번 포트를 사용한다. 즉 Route "53"은 DNS 서비스임을 포트 번호로 알려주는 것이다.

두 번째 의미: 미국의 Route 66

미국에는 Route 66이라는 전설적인 고속도로가 있다. 시카고에서 로스앤젤레스까지 미국 대륙을 횡단하는 이 도로는 "어디로든 연결해주는 길"의 상징이다. AWS가 Route라는 이름을 붙인 것은 — DNS가 사용자를 어디로든 올바른 목적지로 안내하는 길이라는 의미를 담은 것이다.

2. Route 53의 3가지 핵심 역할

Route 53은 단순한 DNS 서버가 아니다. 세 가지 독립적인 역할을 동시에 수행한다.

역할 1: 도메인 등록 (Domain Registration)

도메인을 사용하려면 먼저 등록해야 한다. Route 53에서 직접 .com, .io, .co.kr 등 수백 개 TLD의 도메인을 구매하면 DNS 설정이 자동으로 연결된다. 자동 갱신, WHOIS 프라이버시 보호, 도메인 잠금 기능을 제공한다. 외부 등록 기관(가비아, Namecheap 등)에서 구매한 도메인도 네임서버만 변경하면 Route 53에서 관리할 수 있다.

역할 2: DNS 라우팅 (DNS Routing)

Route 53의 핵심 기능이다. 도메인 이름에 대한 DNS 쿼리를 받아서, 적절한 IP 주소(또는 다른 리소스)를 반환한다.

DNS 레코드의 기본 타입을 먼저 이해해야 한다.

역할 3: 헬스 체크 (Health Checks)

Route 53은 연결된 서버(엔드포인트)가 정상적으로 작동하는지 주기적으로 확인한다. 서버가 죽으면 자동으로 트래픽을 다른 서버로 우회시킨다. 이것이 DNS 장애 전환(DNS Failover)이다.

HTTP/HTTPS 요청의 200 응답 확인, TCP 연결 확인, 응답 본문의 문자열 매칭, CloudWatch 알람 기반 체크 등 다양한 방식을 지원한다. 전 세계 여러 리전에서 동시에 체크하며, 18% 이상의 체크 포인트가 "unhealthy"로 판단하면 해당 엔드포인트를 비정상으로 표시한다.

3. DNS 쿼리는 어떻게 동작하는가 — 한 번의 요청, 네 번의 질문

브라우저에 www.example.com을 입력했을 때, DNS 쿼리가 실제로 어떻게 처리되는지 살펴보자.

이 과정이 매번 일어나면 느릴 것 같지만, 캐싱 덕분에 실제로는 대부분의 쿼리가 밀리초 단위로 처리된다. 각 DNS 레코드에는 TTL(Time To Live)이 설정되어 있어, 한 번 조회한 결과를 일정 시간 동안 캐시에 저장한다.

4. 라우팅 정책 6가지 완전 정리

Route 53이 단순한 DNS 서버와 차별화되는 지점이 바로 라우팅 정책(Routing Policy)이다. 같은 도메인 이름에 대해 어떤 기준으로 응답을 결정할지를 6가지 방식으로 제어할 수 있다.

4-1. Simple Routing (단순 라우팅)

가장 기본적인 정책이다. 하나의 도메인에 하나(또는 여러 개)의 IP를 연결한다. 여러 IP가 있으면 랜덤으로 하나를 반환한다.

api.example.com → A 레코드
  값: 54.1.2.3, 54.4.5.6, 54.7.8.9
  TTL: 300초

적합한 경우: 개발/테스트 환경, 단일 서버 운영, 트래픽 제어가 필요 없는 경우

4-2. Weighted Routing (가중치 라우팅)

각 레코드에 가중치(weight)를 부여하여, 트래픽을 원하는 비율로 분배한다. A/B 테스트나 점진적 배포(blue-green deployment)에 핵심적이다.

활용 예시: 새 버전 배포 시 처음에 10%만 새 서버로 보내고, 문제가 없으면 점진적으로 비율을 높인다. 카나리 배포(Canary Deployment)의 핵심 메커니즘이다.

4-3. Latency-based Routing (지연시간 기반 라우팅)

사용자의 요청이 가장 낮은 지연시간(latency)으로 응답할 수 있는 리전의 서버로 라우팅된다. AWS가 전 세계 네트워크 지연시간 데이터를 자체적으로 수집하여 판단한다.

핵심 포인트: 지연시간 기반 라우팅은 지리적 위치가 아니라 네트워크 지연시간으로 판단한다. 물리적으로 가까운 리전이 항상 빠른 것은 아니기 때문이다. 예를 들어, 네트워크 경로에 따라 일본 사용자가 서울보다 도쿄 리전이 더 느릴 수도 있다.

4-4. Failover Routing (장애 전환 라우팅)

Active-Passive 구조를 구현한다. 주 서버(Primary)가 정상이면 그쪽으로 보내고, 장애가 발생하면 자동으로 보조 서버(Secondary)로 전환한다.

헬스 체크와 함께 사용하며, Primary 엔드포인트의 헬스 체크가 실패하면 자동으로 Secondary로 DNS 응답이 바뀐다. 별도의 코드 변경 없이 DNS 레벨에서 장애 전환이 이루어지는 것이 핵심이다.

4-5. Geolocation Routing (지리 위치 라우팅)

사용자의 물리적 위치(국가, 대륙)에 따라 다른 서버로 라우팅한다. Latency 기반과 비슷해 보이지만, 목적이 다르다.

활용 예시: 한국 사용자 → 한국어 사이트, EU 사용자 → GDPR 준수 서버(EU 리전), 특정 국가 접근 차단(해당 국가에 레코드를 설정하지 않음).

4-6. Multi-value Answer Routing (다중 값 응답 라우팅)

Simple Routing과 비슷하게 여러 IP를 반환하지만, 각 레코드에 헬스 체크를 연결할 수 있다. 비정상 서버의 IP는 응답에서 자동 제외된다. 최대 8개의 정상 레코드를 동시에 반환하며, 완전한 로드 밸런서를 대체하지는 않지만 DNS 레벨에서의 간단한 고가용성을 제공한다.

6가지 라우팅 정책 한눈에 비교

5. Alias 레코드: AWS만의 특별한 무기

Route 53에는 표준 DNS에 없는 특별한 레코드 타입이 있다. Alias 레코드다. 이것은 Route 53이 다른 DNS 서비스와 차별화되는 핵심 기능 중 하나다.

CNAME의 한계

표준 DNS의 CNAME 레코드는 도메인을 다른 도메인으로 매핑한다. 하지만 CNAME에는 치명적인 제약이 있다 — Zone Apex(루트 도메인)에 사용할 수 없다. www.example.com → CNAME은 가능하지만, example.com → CNAME은 RFC 규격 위반이다. Zone Apex에는 SOA와 NS 레코드가 반드시 있어야 하고, CNAME은 다른 레코드와 공존할 수 없기 때문이다.

현실에서는 example.com을 CloudFront나 ALB에 연결하고 싶은 경우가 매우 많다. 이때 Alias 레코드가 등장한다.

Alias 레코드란

Alias 레코드는 Route 53이 내부적으로 처리하는 가상의 CNAME이다. DNS 쿼리가 들어오면 Route 53이 대상 리소스의 실제 IP 주소를 조회하여 A 레코드처럼 직접 반환한다.

Alias 대상이 될 수 있는 AWS 리소스는 CloudFront 배포, ALB/NLB, S3 정적 웹사이트, Elastic Beanstalk, API Gateway, 같은 Hosted Zone의 다른 Route 53 레코드 등이다.

6. Health Check와 DNS Failover: 서버가 죽어도 서비스는 살린다

인터넷 서비스에서 단일 장애점(Single Point of Failure)은 가장 피해야 할 것이다. Route 53의 헬스 체크와 DNS Failover는 서버 장애 시 사용자가 거의 인지하지 못하게 자동으로 정상 서버로 전환한다.

Health Check의 작동 원리

Route 53은 전 세계 여러 위치에서 동시에 엔드포인트를 모니터링한다.

Active-Passive 아키텍처 실전 예제

가장 흔한 패턴은 Active-Passive 장애 전환이다. 평소에는 서울 리전(Primary)이 트래픽을 처리하고, 서울에 장애가 발생하면 도쿄 리전(Secondary)으로 자동 전환된다.

Hosted Zone: example.com

레코드 1 (Primary):
  이름: api.example.com
  타입: A (Alias → ALB 서울)
  라우팅: Failover - Primary
  헬스 체크: hc-seoul-alb (연결됨)

레코드 2 (Secondary):
  이름: api.example.com
  타입: A (Alias → ALB 도쿄)
  라우팅: Failover - Secondary
  헬스 체크: 선택 사항

이 구조에서 서울 ALB의 헬스 체크가 실패하면, Route 53은 자동으로 api.example.com의 DNS 응답을 도쿄 ALB의 IP로 변경한다. 사용자는 동일한 URL에 접속하지만, 뒤에서는 다른 서버가 응답하는 것이다.

헬스 체크는 3가지 유형이 있다. 엔드포인트 모니터링(IP/도메인에 직접 요청), 계산된 헬스 체크(여러 체크의 AND/OR 조합 — 예: "웹 서버, DB, 캐시 중 2개 이상 정상이면 OK"), CloudWatch 알람(메트릭 기반 판단)이다.

7. Route 53 + CloudFront + ALB — 실전 아키텍처

이론을 넘어서, 실제 프로덕션 환경에서 Route 53이 다른 AWS 서비스와 어떻게 조합되는지 살펴보자. 가장 전형적인 패턴은 Route 53 + CloudFront + ALB 3단 구조다.

글로벌 웹 서비스 아키텍처

각 계층의 역할

이 아키텍처에서 Route 53의 구체적인 설정

Hosted Zone: myservice.com

1) 루트 도메인 → CloudFront
   이름: myservice.com
   타입: A (Alias)
   대상: d1234abcd.cloudfront.net

2) www 서브도메인 → CloudFront
   이름: www.myservice.com
   타입: A (Alias)
   대상: d1234abcd.cloudfront.net

3) API → ALB 직접 연결
   이름: api.myservice.com
   타입: A (Alias)
   대상: my-alb-1234.ap-northeast-2.elb.amazonaws.com

4) 이메일 설정
   이름: myservice.com
   타입: MX
   값: 10 inbound-smtp.us-east-1.amazonaws.com

여기서 주목할 점은 루트 도메인(myservice.com)을 Alias로 CloudFront에 연결하고 있다는 것이다. 앞서 설명했듯이 CNAME으로는 불가능한 설정이다. 이것이 Alias 레코드의 존재 이유다.

멀티 리전 Active-Active 아키텍처

더 발전된 패턴은 여러 리전에서 동시에 서비스하는 Active-Active 구조다. Route 53의 Latency 기반 라우팅 + 헬스 체크를 조합하면, 한국 사용자는 서울, 미국 사용자는 버지니아, 유럽 사용자는 프랑크푸르트로 자동 라우팅된다. 서울 리전에 장애가 발생하면 한국 사용자의 트래픽이 자동으로 두 번째로 빠른 리전(보통 도쿄)으로 전환된다. Active-Active이면서 동시에 자동 Failover까지 되는 구조다.

8. 비용 구조: 의외로 저렴한 DNS

클라우드 비용은 서비스 선택에서 중요한 요소다. Route 53의 비용 구조는 크게 세 가지로 나뉜다.

비용 항목별 정리

비용 예측 시나리오

시나리오: 월 500만 DNS 쿼리, Alias 사용, 헬스 체크 2개

Hosted Zone:       1개 × $0.50     = $0.50
DNS 쿼리:         Alias → AWS 무료  = $0.00
헬스 체크:        2개 × $0.50      = $1.00
────────────────────────────────────────────
월 합계:                            = $1.50
연 합계:                            = $18.00

Alias 레코드를 활용하면 DNS 쿼리 비용이 거의 제로에 가깝다. 월 $1~2 수준으로 글로벌 DNS 라우팅과 헬스 체크를 운영할 수 있다. 클라우드 서비스 비용 중에서 DNS가 차지하는 비중은 극히 미미하다.

9. 실전 사례: 글로벌 서비스의 Route 53 활용

이론과 설정 방법을 모두 다뤘으니, 실제 글로벌 서비스에서 Route 53이 어떻게 활용되는지 구체적인 시나리오를 살펴보자.

사례 1: 글로벌 SaaS — 지역별 성능 최적화

한국에서 시작한 SaaS 서비스가 미국과 유럽으로 확장한다고 가정하자.

사례 2: 카나리 배포 — 새 버전 점진적 롤아웃

서비스의 v2를 배포할 때, 한 번에 모든 트래픽을 전환하면 위험하다. Route 53의 Weighted Routing으로 점진적으로 전환한다.

각 단계에서 에러율과 지연시간을 모니터링한다. 문제가 발견되면 v2의 가중치를 0으로 변경하여 즉시 롤백한다. TTL(보통 60초) 이내에 모든 트래픽이 v1으로 돌아온다.

사례 3: 규정 준수 — GDPR과 데이터 주권

EU의 GDPR은 EU 시민의 데이터를 EU 밖으로 전송하는 것을 엄격히 규제한다. Geolocation 라우팅으로 이 요구사항을 DNS 레벨에서 해결한다.

EU 사용자의 요청은 물리적으로 EU 리전에서만 처리되므로, 데이터가 EU 밖으로 나가지 않는다. 애플리케이션이 아닌 DNS 레벨에서 강제하는 것이 핵심이다.

사례 4: 재해 복구 — S3 정적 페이지 폴백

서버 전체가 다운되는 최악의 시나리오에서도, S3 정적 웹사이트를 Failover Secondary로 설정해두면 "점검 중" 안내 페이지를 서빙할 수 있다. S3는 99.99% 가용성이므로 거의 확실하게 동작하며, 비용도 무시할 수 있는 수준이다.

10. Route 53을 더 잘 쓰기 위한 실무 팁

TTL 전략

자주 하는 실수

마치며: DNS는 인프라의 시작이자 끝이다

이 글에서 다룬 내용을 정리해보자.

DNS는 사용자가 서비스에 접근하는 가장 첫 번째 단계다. 아무리 서버가 빠르고, 코드가 완벽해도, DNS가 잘못되면 사용자는 서비스에 도달조차 하지 못한다. 반대로 DNS가 잘 설계되어 있으면, 서버 장애가 발생해도 사용자는 거의 인지하지 못한 채 정상적으로 서비스를 이용할 수 있다.

Route 53은 100% SLA를 보장하는 몇 안 되는 AWS 서비스 중 하나다. AWS가 그만큼 DNS의 중요성을 인지하고 있다는 의미다.

진짜 견고한 아키텍처는 DNS부터 시작한다. Route 53의 라우팅 정책과 헬스 체크를 제대로 활용하면, 글로벌 규모의 고가용성을 놀라울 정도로 적은 비용으로 구현할 수 있다.

"좋은 인프라는 투명하다. 사용자가 그 존재를 인지하지 못할 때, 그것이 가장 잘 작동하고 있는 것이다." DNS가 바로 그런 인프라다.