AWS (Route 53)

엄경문·2026년 1월 20일

AWS

목록 보기

8/10

Route 53

Route 53 기술을 알기 앞서 DNS 의 개념을 알아야한다.

DNS란?

DNS는 이름(도메인) → 어디로 갈지(주소/목적지)를 알려주는 인터넷 전화번호부의 역할은한다.
사용자는 www.example.com 같은 이름만 입력하지만 실제 통신은 결국 IP 주소로 가서 통신을 한다.

Route 53

Route 53은 AWS가 제공하는 완전 관리형 DNS 서비스로
- DNS 레코드를 운영
- 도메인 구입 및 Domain호스팅 관리지원
- 필요하면 트래픽을 어떤 엔드포인트로 보낼지(라우팅 정책) 결정
- 도메인 및 연결된 리소스에 대한 헬스체크(HealthCheck) 기능 제공
- AWS에서 유일하게 100% SLA를 제공하며 서비스 안전성 보장

즉, Route 53은 도메인 질의가 들어오면 어떤 답(A/AAAA/CNAME/ALIAS 등)을 줄지 결정해서 응답하는 시스템이다.

Route 53 외부 도메인을 AWS Route 53의Hosted Zone에 등록하여 사용 가능하다.

1) Public Hosted Zone

인터넷 어디서든 DNS 질의가 들어오면 Route 53이 답해준다
www.myservice.com 같은 외부 공개 서비스에 사용
보통 연결 대상: ALB, CloudFront, 퍼블릭 IP(EC2), API Gateway 등

2) Private Hosted Zone

특정 VPC 내부에서만 DNS가 해석(Resolve)
인터넷에서는 같은 도메인 이름을 물어봐도 알 수 없거나(응답 없음) 애초에 공개 DNS에 등록이 안 되어 있다
예) db.internal, api.corp.local 같은 사내 전용 도메인
주 용도:
- 마이크로서비스 내부 호출 (서비스끼리 이름으로 통신)
- DB, 캐시, 내부 API 같은 외부 노출 금지 리소스를 편하게 찾는 용도

Record Type 6개

1. A (Address)

이름 → IPv4 주소로 매핑
예) app.example.com → 203.0.113.10

2. AAAA

이름 → IPv6 주소로 매핑

3. CNAME (Canonical Name)

이름 → 다른 도메인 이름으로 별칭 연결
예) www.example.com → d123.cloudfront.net
주의(본질): 보통 루트 도메인(example.com) 에는 못 씀 (표준 DNS 제약)

4. ALIAS (Route 53 전용 개념)

CNAME처럼 별칭인데 루트 도메인에도 사용 가능하고 AWS 리소스 (ALB, CloudFront, S3 웹호스팅 등)로 바로 연결 가능.
CNAME 쓰고 싶은데 루트라서 못 쓰는 문제를 풀어주는 게 ALIAS이다

5. MX (Mail eXchange)

메일 수신 서버 지정
예) example.com의 메일은 mail.example.com으로 받는다

6. TXT

임의 텍스트 저장(검증/보안에 많이 씀)
- SPF/DKIM/DMARC 같은 메일 보안 정책
- 도메인 소유권 확인(구글/마이크로소프트 등)

Routing Policy

1) Simple Routing

기본값: 한 개(또는 여러 개) 레코드를 그대로 응답
특징: 조건/비율/장애 판단 없음
예: www는 ALB 하나로만 보낸다

2) Weighted Routing

비율(가중치)로 분산
예: 신버전 10%, 구버전 90% (점진 배포/카나리)

3) Latency-based Routing

사용자가 질의한 위치 기준으로 지연시간이 가장 낮은 리전/엔드포인트를 선택
예: 한국 사용자는 서울 리전 미국 사용자는 버지니아 리전으로 더 자주 연결

4) Failover Routing

Primary/Secondary로 나누고
Primary가 헬스체크에서 실패하면 Secondary로 자동 전환
예: 메인 ALB 장애 시 DR(재해복구) 리전으로 넘김

5) Geolocation Routing

사용자 위치(국가/대륙/지역) 기준으로 정책적으로 분기
예: EU 사용자는 EU 리전으로만(규정/정책) KR은 KR로만

실습

Public Hosted Zone 생성

Route 53에서 st18.cj-cloud-wave.com 도메인의 공개 DNS 전화번호부(Hosted Zone) 를 만들고 이 안에 앞으로 simple.cj-cloud-wave.com 같은 레코드(A, CNAME, ALIAS 등)를 저장

Route 53 콘솔 화면 → 호스트 영역 리소스 탭 → 호스팅 영역 생성 버튼 클릭

Public Hosted Zone NS Record 생성

VS Code IDE Terminal 화면으로 이동
Script 폴더로 이동

cd /Workshop/scripts

# Public Hosted Zone NS Record 정보 수집 Script 실행

sh get_ns-record_json.sh st18

이 도메인의 Route 53 네임서버 목록(NS 4개)을 뽑아서(JSON 파일로) 정리

결국 가비아(도메인 판매처/등록기관) 쪽 NS 설정을 Route 53 NS 4개로 바꿔야 인터넷이 Route 53에게 묻게 된다. 이 작업은 NS 4개를 복붙하기위해 자동으로 뽑는 단계이다.

권한 생성

ubuntu@ip-10-0-1-211:/Workshop/scripts$ sudo bash get_ns_record_json.sh st18
Created folder: JSON_FILE

서울, 버지니아, 프랑크프루트 Web Server Public IP 메모

서울 배스천 3.38.150.146
버지니아 리전 3.231.145.76
프랑크프루트 리전 18.185.99.79

DNS 레코드(A)를 만들 때 IP 가 필요하다.

그래서 각 리전 웹서버의 공인 IP를 미리 적어둔 것

Route 53 Simple Routing Policy

Single Value Simple Routing Policy 생성
Route 53 메인 콘솔 화면 → 호스팅 영역 리소스 탭 → st18.cj-cloud-wave.com 클릭

Routing Policy 생성 정보 입력

레코드 이름: simple.st18.cj-cloud-wave.com
레코드 유형: A
값: ap-northeast-2 web server public ip
TTL(option): 10초

확인해보면

Multy Value Simple Routing Policy 생성

Route 53 레코드 편집 화면으로 이동 → simple.st18.cj-cloud-wave.com 레코드 클릭 → 레코드 편집 버튼 클릭

값 수정 → 저장 버튼 클릭

ap-northeast-2 web server public ip
us-east-1 web server public ip
eu-central-1 web server public ip

vscode 서버에서 dig 명령어로 확인

Route 53 Weighted Routing Policy

Weighted Routing Policy 생성

Route 53 메인 콘솔 화면 → 호스팅 영역 리소스 탭 → st18.cj-cloud-wave.com 클릭
- 레코드 이름: weighted.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: ap-northeast-2 web server public ip
- TTL(option): 1초
- Routing Policy: 가중치 기반
- Weight: 60
- Record id: ap-northeast-2
Routing Policy 생성 정보 입력 (버지니아 리전) → 다른 레코드 추가
- 레코드 이름: weighted.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: us-east-1 web server public ip
- TTL(option): 1초
- Routing Policy: 가중치 기반
- Weight: 30
- Record id: us-east-1
Routing Policy 생성 정보 입력 (프랑크프루트 리전) → 레코드 생성
- 레코드 이름: weighted.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: eu-central-1 web server public ip
- TTL(option): 1초
- Routing Policy: 가중치 기반
- Weight: 10
- Record id: eu-central-1
dig 명령어로 확인

Route 53 Latency Routing Policy

Latency Routing Policy 생성

Route 53 메인 콘솔 화면 → 호스팅 영역 리소스 탭 → st18.cj-cloud-wave.com 클릭
Routing Policy 생성 정보 입력 (서울 리전)
- 레코드 이름: latency.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: ap-northeast-2 web server public ip
- TTL(option): 1초
- Routing Policy: 지연 시간
- Region: ap-northeast-2
- Record id: ap-northeast-2
Routing Policy 생성 정보 입력 (버지니아 리전)
- 레코드 이름: latency.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: us-east-1 web server public ip
- TTL(option): 1초
- Routing Policy: 지연 시간
- Region: us-east-1
- Record id: us-east-1
Routing Policy 생성 정보 입력 (프랑크푸르트 리전)
- 레코드 이름: latency.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: eu-central-1 web server public ip
- TTL(option): 1초
- Routing Policy: 지연 시간
- Region: eu-central-1
- Record id: eu-central-1

서울리전

버지니아

프랑크푸르트

Route 53 Failover Routing Policy

Route 53 Health Check 생성

Route 53 메인 콘솔 화면 → 상태 검사 리소스 탭 → 상태 검사 생성 버튼 클릭
서울 리전 상태 검사기 생성 정보 입력
- 이름: ap-northeast-2
- IP 주소: ap-northeast-2 배스천 public ip
- 고급 구성 → 요청 간격: 빠름 (10초)
- 고급 구성 → 실패 임계값: 1
- 고급 구성 → 상태 검사기 리전: 사용자 지정
  - 아시아 태평양(도쿄)
  - 아시아 태평양(시드니)
  - 아시아 태평양(싱가포르)
버지니아 리전 상태 검사기 생성 정보 입력
- 이름: us-east-1
- IP 주소: us-east-1 web server public ip
- 고급 구성 → 요청 간격: 빠름 (10초)
- 고급 구성 → 실패 임계값: 1
- 고급 구성 → 상태 검사기 리전: 사용자 지정
  - 미국 동부(버지니아 북부)
  - 미국 서부(캘리포니아 북부)
  - 미국 서부(오레곤 북부)

같은 리전일 경우에 상태 검사기도 같이 장애를 겪거나 고립될 수 있고 이 경우 검사기 자체가 서버에 도달하지 못하면서도 뭐가 문제인지 제대로 판단하지 못할 위험이 있다.

Fail-over Routing Policy 생성

Route 53 메인 콘솔 화면 → 호스팅 영역 리소스 탭 → stxx.cj-cloud-wave.com 클릭
레코드 생성 버튼 클릭
서울 리전 Routing Policy 생성 정보 입력
- 레코드 이름: failover.st18.cj-cloud-wave.com
- 레코드 유형: A*
- 값: ap-northeast-2 web server public ip
- TTL(option): 1초
- Routing Policy: 장애 조치
- Failover record type: Primary
- Health check: ap-northeast-2
- Record id: ap-northeast-2
다른 레코드 추가 버튼 클릭
버지니아 리전 Routing Policy 생성 정보 입력
- 레코드 이름: failover.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: us-east-1 web server public ip
- TTL(option): 1초
- Routing Policy: 장애 조치
- Failover record type: Secondary
- Health check: us-east-1
- Record id: us-east-1
레코드 생성 버튼 클릭

Web 서비스 접속 테스트

http://failover.st18.cj-cloud-wave.com 주소로 웹 브라우저에서 접속

서울 리전 Web Server 중지

Web 서비스 접속 테스트
http://failover.st18.cj-cloud-wave.com/ 주소로 웹 브라우저에서 접속

Route 53 Geolocation Routing Policy

Geolocation Routing Policy 생성

Route 53 메인 콘솔 화면 → 호스팅 영역 리소스 탭 → st18.cj-cloud-wave.com 클릭
레코드 생성 버튼 클릭
서울 리전 Routing Policy 생성 정보 입력
- 레코드 이름: geolocation.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: ap-northeast-2 web server public ip
- TTL(option): 1초
- Routing Policy: 지리적 위치
- Location: Default
버지니아 리전 Routing Policy 생성 정보 입력
- 레코드 이름: geolocation.st18.cj-cloud-wave.com*
- 레코드 유형: A
- 값: us-east-1 web server public ip
- TTL(option): 1초
- Routing Policy: 지리적 위치
- Location: 미국
- Record id: us-east-1
프랑크푸르트 리전 Routing Policy 생성 정보 입력
- 레코드 이름: geolocation.st18.cj-cloud-wave.com
- 레코드 유형: A
- 값: eu-central-1 web server public ip
- TTL(option): 1초
- Routing Policy: 지리적 위치
- Location: 유럽
- Record id: eu-central-1

서울리전에서 확인

Local DNS 서버 IP 변경 (Alabama)

ubuntu@ip-10-0-1-211:/Workshop/scripts$ dig @8.8.8.8 geolocation.st18.cj-cloud-wave.com +subnet=18.184.0.0/16

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> @8.8.8.8 geolocation.st18.cj-cloud-wave.com +subnet=18.184.0.0/16
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9900
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 18.184.0.0/16/16
;; QUESTION SECTION:
;geolocation.st18.cj-cloud-wave.com. IN A

;; ANSWER SECTION:
geolocation.st18.cj-cloud-wave.com. 1 IN A      18.185.99.79

;; Query time: 201 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Jan 19 06:47:51 UTC 2026
;; MSG SIZE  rcvd: 89

ubuntu@ip-10-0-1-211:/Workshop/scripts$

거리가 가까운 유럽에서 ANSWER 이 오는것을 확인할 수 있다.

마무리

Route 53 기능을 통해 DNS 서버로 조회하는것을 공부하였다. 또한 다양한 Routing policy를 직접 실습 형태로 진행하며 dig 를 보내며 정책대로 실행되는지 확인해보았다. 눈으로 ip 를 직접 비교하면서 확인하니 각 라우팅 policy가 제대로 작동하는지 확인할 수 있었다.

엄경문

이전 포스트

AWS (VPC Endpoint)

다음 포스트