Route 53 라우팅 정책: Failover, Latency, Geolocation, 언제 무엇을 사용할까?

핵심 요약 (BLUF)

Failover는 장애 조치(DR)용, Latency는 최저 지연 시간용, Geolocation은 지역별 콘텐츠용, Weighted는 트래픽 비율 분배용입니다. 단일 리소스면 Simple, 성능 최적화는 Latency, 지역별 서비스는 Geolocation, 테스트 배포는 Weighted를 선택하세요.

시험 팁

시험 핵심: Failover = DR + 헬스 체크, Latency = 성능 최적화, Geolocation = 지역별 콘텐츠, Weighted = 비율 분배 + A/B 테스트

Route 53 라우팅 정책이란?

Route 53 라우팅 정책은 DNS 쿼리에 어떻게 응답할지 결정합니다. 동일한 도메인에 대해 여러 리소스가 있을 때, 어떤 리소스의 IP 주소를 반환할지 정의합니다.

사용자 DNS 쿼리: example.com
         ↓
    Route 53
    (라우팅 정책 적용)
         ↓
    응답: 52.1.2.3 (선택된 리소스 IP)

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

정책	목적	라우팅 기준	헬스 체크
Simple	단일 리소스	없음 (하나의 값)	미지원
Weighted	트래픽 비율 분배	가중치 비율	지원
Failover	장애 조치 (DR)	헬스 체크 상태	필수
Latency	성능 최적화	네트워크 지연 시간	지원
Geolocation	지역별 콘텐츠	사용자 위치 (국가/대륙)	지원
Geoproximity	위치 기반 + 편향	리소스 거리 + 편향값	지원
Multivalue Answer	부하 분산	무작위 (최대 8개)	지원
IP-based	IP 범위별 라우팅	클라이언트 IP	지원

Simple Routing (단순 라우팅)

작동 방식

가장 기본적인 정책으로, 하나의 리소스로 모든 트래픽을 라우팅합니다.

Simple Routing:

모든 DNS 쿼리 → 단일 리소스 (예: 52.1.2.3)

특징

단일 레코드에 하나 또는 여러 IP 주소 지정 가능
여러 IP 지정 시 무작위로 하나 반환 (클라이언트 선택)
헬스 체크 미지원

적합한 경우

단일 서버/리소스만 있는 경우
간단한 웹사이트
복잡한 라우팅 로직 불필요

시험 팁

주의: Simple Routing은 헬스 체크를 지원하지 않습니다. 고가용성이 필요하면 다른 정책을 사용하세요.

Weighted Routing (가중치 기반 라우팅)

작동 방식

여러 리소스에 **가중치(Weight)**를 지정하여 트래픽을 비율로 분배합니다.

Weighted Routing 예시:

리소스 A (Weight: 70) → 트래픽 70%
리소스 B (Weight: 20) → 트래픽 20%
리소스 C (Weight: 10) → 트래픽 10%

사용 사례

1. 카나리 배포 (Canary Deployment)

프로덕션 v1 (Weight: 90) → 90% 트래픽
신규 버전 v2 (Weight: 10) → 10% 트래픽 (테스트)

2. A/B 테스팅

버전 A (Weight: 50) → 50%
버전 B (Weight: 50) → 50%

3. 점진적 마이그레이션

기존 DC (Weight: 80 → 50 → 20 → 0)
AWS    (Weight: 20 → 50 → 80 → 100)

Weight 값

0-255 범위
Weight 0 = 트래픽 없음 (비활성화)
모든 리소스가 Weight 0이면 균등 분배

시험 팁

시험 포인트: 새 버전 테스트, A/B 테스트, 점진적 마이그레이션 문제 → Weighted Routing

Failover Routing (장애 조치 라우팅)

작동 방식

액티브-패시브 구성으로 Primary 리소스 장애 시 자동으로 Secondary로 전환합니다.

Failover Routing:

                    헬스 체크
                        ↓
정상 시: 쿼리 → Primary (액티브)

장애 시: 쿼리 → Secondary (패시브/대기)

필수 구성

Primary 레코드: 헬스 체크 연결 필수
Secondary 레코드: Primary 장애 시 사용
헬스 체크: Primary 상태 모니터링

헬스 체크 유형

유형	확인 대상
HTTP/HTTPS	엔드포인트 응답 코드 (2xx, 3xx)
TCP	TCP 연결 가능 여부
HTTP 문자열 일치	응답 본문에 특정 문자열 포함 여부
계산된 헬스 체크	다른 헬스 체크 조합 (AND/OR)
CloudWatch 경보	CloudWatch 경보 상태 기반

적합한 경우

재해 복구 (DR) 시나리오
액티브-패시브 아키텍처
주 리소스 장애 시 자동 전환

시험 팁

시험 문제 패턴: "Primary 리전 장애 시 자동으로 DR 리전으로 전환하려면?" → Failover Routing + 헬스 체크

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

작동 방식

사용자에게 가장 낮은 네트워크 지연 시간을 제공하는 AWS 리전의 리소스로 라우팅합니다.

Latency-based Routing:

한국 사용자
    ↓
Route 53 (지연 시간 측정)
    ↓
서울 리전 (지연 시간 최소) → 선택됨
버지니아 리전 (지연 시간 높음)
프랑크푸르트 리전 (지연 시간 높음)

특징

AWS가 지연 시간 데이터를 수집/관리
지리적 거리 ≠ 지연 시간 (네트워크 경로에 따라 다름)
각 리전별 레코드 생성 필요

Latency vs Geolocation

항목	Latency	Geolocation
라우팅 기준	네트워크 지연 시간	지리적 위치
목적	성능 최적화	지역별 콘텐츠
결과	가장 빠른 리전	지정된 리전

시험 팁

시험 포인트: "사용자에게 가장 빠른 응답을 제공하려면?" → Latency-based Routing (지리적으로 가장 가까운 것이 아님!)

Geolocation Routing (지리 위치 라우팅)

작동 방식

사용자의 지리적 위치(국가/대륙)에 따라 특정 리소스로 라우팅합니다.

Geolocation Routing:

한국 사용자     → 한국어 서버
미국 사용자     → 영어 서버
유럽 사용자     → 독일어/영어 서버
기타 (Default) → 글로벌 서버

사용 사례

지역별 콘텐츠 제공 (언어, 법적 요구사항)
콘텐츠 제한 (저작권, 지역 제한)
규정 준수 (데이터 거주지 요구사항)

필수 설정: Default 레코드

⚠️ 중요: Default 레코드 필수!

지정되지 않은 위치의 사용자를 위한 기본 응답 필요
없으면 일치하지 않는 사용자에게 "NODATA" 응답

Geolocation vs Latency

시나리오	권장 정책
지역별 언어/콘텐츠 제공	Geolocation
데이터 거주지 규정 준수	Geolocation
최고 성능 제공	Latency
사용자 경험 최적화	Latency

시험 팁

시험 문제 패턴: "유럽 사용자는 EU 리전에서만 데이터에 접근해야 합니다" → Geolocation Routing

Geoproximity Routing (지리 근접 라우팅)

작동 방식

리소스의 물리적 위치를 기반으로 라우팅하며, 편향(Bias) 값으로 트래픽 분배를 조정할 수 있습니다.

Geoproximity + Bias:

서울 리전 (Bias: +50)  → 더 넓은 범위에서 트래픽 수신
도쿄 리전 (Bias: 0)    → 기본 범위
싱가포르 리전 (Bias: -25) → 더 좁은 범위

Bias 값

양수(+): 해당 리소스로 더 많은 트래픽 유도
음수(-): 해당 리소스에서 트래픽 감소
범위: -99 ~ +99

적합한 경우

특정 리전으로 트래픽 집중
리전 간 트래픽 균형 조정
비AWS 리소스 포함 시

요구 사항

Route 53 Traffic Flow 사용 필수 (시각적 정책 편집기)

Multivalue Answer Routing (다중값 응답 라우팅)

작동 방식

DNS 쿼리에 최대 8개의 정상 레코드를 무작위로 반환합니다. 클라이언트 측 로드밸런싱 효과.

Multivalue Answer:

DNS 쿼리 응답:
- 52.1.1.1 (정상)
- 52.2.2.2 (정상)
- 52.3.3.3 (정상)
- 52.4.4.4 (비정상 → 제외)

Simple vs Multivalue Answer

항목	Simple	Multivalue Answer
헬스 체크	미지원	지원
응답 레코드	모든 값	정상 레코드만 (최대 8개)
가용성	낮음	높음

적합한 경우

간단한 로드밸런싱 필요
ELB 없이 여러 리소스 분산
헬스 체크로 정상 리소스만 반환

시험 팁

주의: Multivalue Answer는 ELB의 대체가 아닙니다! 진정한 로드밸런싱이 필요하면 ELB를 사용하세요.

IP-based Routing (IP 기반 라우팅)

작동 방식

**클라이언트 IP 주소 범위(CIDR)**에 따라 특정 리소스로 라우팅합니다.

IP-based Routing:

CIDR: 203.0.113.0/24 → 서버 A
CIDR: 198.51.100.0/24 → 서버 B
기타 IP → 기본 서버

사용 사례

ISP/네트워크별 최적화된 엔드포인트
특정 고객사 전용 서버
내부 네트워크 트래픽 분리

라우팅 정책 선택 가이드

의사결정 트리

어떤 라우팅이 필요한가요?

├─ 단일 리소스만 있음 → Simple
│
├─ 장애 조치가 필요함 → Failover + 헬스 체크
│
├─ 성능 최적화가 필요함 → Latency-based
│
├─ 지역별 콘텐츠 제공 → Geolocation
│
├─ 트래픽 비율 분배 필요
│   ├─ A/B 테스트, 카나리 배포 → Weighted
│   └─ 위치 기반 비율 조정 → Geoproximity
│
├─ 간단한 로드밸런싱 → Multivalue Answer
│
└─ 특정 IP 범위별 라우팅 → IP-based

시나리오별 선택

시나리오	권장 정책
DR(재해 복구) 구성	Failover
글로벌 사용자 성능 최적화	Latency
지역별 언어/콘텐츠	Geolocation
새 버전 카나리 테스트	Weighted
다중 리소스 간단한 분산	Multivalue Answer
특정 고객사 전용 서버	IP-based

헬스 체크 상세

헬스 체크 설정

헬스 체크 파라미터:

- 프로토콜: HTTP, HTTPS, TCP
- 엔드포인트: IP 또는 도메인
- 포트: 80, 443, 또는 사용자 지정
- 경로: /health, /status 등
- 간격: 10초 또는 30초
- 실패 임계값: 1-10회
- 문자열 일치: 응답 본문에서 확인

계산된 헬스 체크

여러 헬스 체크를 AND/OR 조건으로 조합:

예: 3개 중 2개 이상 정상이면 통과

헬스 체크 A: 정상 ✓
헬스 체크 B: 정상 ✓
헬스 체크 C: 비정상 ✗

결과: 통과 (2/3 정상)

SAA-C03 시험 출제 포인트

✅ Failover: DR 시나리오 = Failover + 헬스 체크
✅ Latency vs Geolocation: 성능 = Latency, 지역 콘텐츠 = Geolocation
✅ Weighted: 카나리 배포, A/B 테스트, 점진적 마이그레이션
✅ Simple: 헬스 체크 미지원 (고가용성 부적합)
✅ Geolocation Default: 필수 설정 (없으면 NODATA)
✅ 헬스 체크: Failover 필수, 다른 정책 선택적

시험 팁

시험 문제 예시: "회사는 글로벌 사용자에게 최고의 성능을 제공하려 합니다. 여러 AWS 리전에 리소스가 배포되어 있습니다. 어떤 Route 53 라우팅 정책을 사용해야 할까요?" → 정답: Latency-based Routing (지리적으로 가장 가까운 것이 아닌, 지연 시간이 가장 낮은 리전)

Failover: Secondary로 자동 전환
Weighted/Latency/Multivalue: 해당 레코드 응답에서 제외
Simple: 헬스 체크 미지원, 항상 응답

Q: 여러 라우팅 정책을 조합할 수 있나요?

Alias 레코드와 레코드 체이닝으로 가능합니다. 예: Latency 정책으로 리전 선택 → 각 리전 내에서 Weighted로 버전 분배.