네트워킹중급
Multi-AZ vs Multi-Region: AWS 고가용성과 재해복구 전략 완벽 가이드
AWS Multi-AZ와 Multi-Region 아키텍처의 차이점을 비교하고, Pilot Light, Warm Standby, Active-Active 등 DR 전략별 RTO/RPO, 비용, 복잡도를 분석합니다.
PHILOLAMB••-
Multi-AZMulti-Region고가용성재해복구DRPilot LightWarm Standby
관련 시험 도메인
- Domain 2: Design Resilient Architectures
핵심 요약: Multi-AZ vs Multi-Region
결론부터 말하면: Multi-AZ는 **고가용성(HA)**을 위한 것이고, Multi-Region은 **재해복구(DR)**를 위한 것입니다. AZ 장애에 대비하려면 Multi-AZ, 리전 전체 장애나 지리적 요구사항이 있다면 Multi-Region을 선택하세요.
한눈에 보는 비교
| 구분 | Multi-AZ | Multi-Region |
|---|---|---|
| 목적 | 고가용성 (HA) | 재해복구 (DR) |
| 보호 범위 | AZ 장애 | 리전 장애, 자연재해 |
| 페일오버 시간 | 자동, 1-2분 | 수동/자동, 수분~수시간 |
| 데이터 복제 | 동기식 | 비동기식 |
| 지연 시간 | 밀리초 | 수십~수백 밀리초 |
| 비용 | 기본 대비 ~2배 | 기본 대비 2배 이상 |
| 복잡도 | 낮음 | 높음 |
시험 팁
시험 빈출 포인트: "AZ 장애 대비"는 Multi-AZ, "리전 장애 대비" 또는 "자연재해 복구"는 Multi-Region입니다. 비용과 복잡도도 함께 고려하세요.
Multi-AZ 아키텍처
Multi-AZ란?
Multi-AZ는 **단일 리전 내 여러 가용 영역(Availability Zone)**에 리소스를 분산 배치하는 아키텍처입니다.
┌─────────────────────────────────────────────────┐
│ Seoul Region │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ │ AZ-a │ │ AZ-b │ │ AZ-c │
│ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │
│ │ │ EC2 │ │ │ │ EC2 │ │ │ │ EC2 │ │
│ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │
│ │ ┌───────┐ │ │ ┌───────┐ │ │ │
│ │ │ RDS │←─┼──┼─→│Standby│ │ │ │
│ │ │Primary│ │ │ │ RDS │ │ │ │
│ │ └───────┘ │ │ └───────┘ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘
└─────────────────────────────────────────────────┘
Multi-AZ 특징
| 특징 | 설명 |
|---|---|
| 동기식 복제 | Primary와 Standby 간 실시간 데이터 동기화 |
| 자동 페일오버 | 장애 감지 시 자동으로 Standby로 전환 |
| 단일 엔드포인트 | DNS 이름은 그대로, IP만 변경 |
| 동일 리전 내 | 낮은 지연 시간, 간단한 아키텍처 |
Multi-AZ 지원 서비스
✅ RDS (자동 페일오버)
✅ ElastiCache (Redis 클러스터 모드)
✅ EFS (기본 Multi-AZ)
✅ Aurora (기본 Multi-AZ)
✅ OpenSearch (Multi-AZ 배포)
✅ MSK (Multi-AZ 권장)
Multi-AZ 사용 사례
- 프로덕션 데이터베이스: RDS Multi-AZ로 DB 고가용성 확보
- 웹 애플리케이션: ALB + Auto Scaling으로 여러 AZ에 분산
- 파일 스토리지: EFS로 여러 AZ에서 공유 파일 시스템 사용
Multi-Region 아키텍처
Multi-Region이란?
Multi-Region은 여러 AWS 리전에 인프라를 분산 배치하는 아키텍처입니다.
┌──────────────────────┐ ┌──────────────────────┐
│ Seoul Region │ │ Tokyo Region │
│ (ap-northeast-2) │ │ (ap-northeast-1) │
│ ┌────────────────┐ │ │ ┌────────────────┐ │
│ │ Primary DB │──┼─ 복제 ──┼─→│ Replica DB │ │
│ │ (Aurora) │ │ │ │ (Aurora) │ │
│ └────────────────┘ │ │ └────────────────┘ │
│ ┌────────────────┐ │ │ ┌────────────────┐ │
│ │ Application │ │ │ │ Application │ │
│ │ Servers │ │ │ │ (Standby) │ │
│ └────────────────┘ │ │ └────────────────┘ │
└──────────────────────┘ └──────────────────────┘
│ │
└──────────┬─────────────────┘
│
┌──────┴──────┐
│ Route 53 │
│ (Failover) │
└─────────────┘
Multi-Region 특징
| 특징 | 설명 |
|---|---|
| 비동기식 복제 | 리전 간 지연 시간으로 인해 비동기 복제 |
| 글로벌 서비스 필요 | Route 53, CloudFront, Global Accelerator |
| 복잡한 데이터 동기화 | 충돌 해결, 일관성 관리 필요 |
| 높은 비용 | 데이터 전송 비용 + 중복 인프라 비용 |
Multi-Region 지원 서비스
✅ Aurora Global Database (1초 미만 복제)
✅ DynamoDB Global Tables (밀리초 복제)
✅ S3 Cross-Region Replication (CRR)
✅ Route 53 (글로벌 DNS)
✅ CloudFront (글로벌 CDN)
✅ Global Accelerator (글로벌 네트워크)
Multi-Region 사용 사례
- 글로벌 사용자 서비스: 전 세계 사용자에게 낮은 지연 시간 제공
- 규정 준수: 데이터 주권 요구사항 충족
- 재해복구: 리전 전체 장애 대비
- 비즈니스 연속성: 자연재해, 대규모 장애 대비
DR 전략 상세 비교
RTO와 RPO 이해하기
재해복구 전략을 선택하기 전에 두 가지 핵심 지표를 이해해야 합니다:
| 지표 | 정의 | 질문 |
|---|---|---|
| RPO (Recovery Point Objective) | 허용 가능한 데이터 손실량 | "얼마나 많은 데이터를 잃어도 되는가?" |
| RTO (Recovery Time Objective) | 복구에 허용되는 시간 | "얼마나 빨리 복구해야 하는가?" |
장애 발생
│
▼
──────┬─────┼─────┬──────────────────→ 시간
│ │ │
│◄───►│ │◄──────────────►│
│ RPO │ │ RTO │
│ │ │ │
마지막 장애 복구 시작 서비스 복구
백업
시험 팁
시험 팁: RPO가 "0"에 가까워야 한다면 동기식 복제가 필요하고, RTO가 "0"에 가까워야 한다면 Hot Standby나 Active-Active가 필요합니다.
DR 전략 4가지
1. Backup and Restore (백업 및 복원)
가장 기본적인 DR 전략으로, 데이터를 주기적으로 백업하고 재해 시 복원합니다.
Primary Region DR Region
┌─────────────────┐ ┌─────────────────┐
│ ┌───────────┐ │ │ │
│ │ RDS │ │ 백업 │ S3 버킷 │
│ │ Primary │──┼─────────────→│ (스냅샷 저장) │
│ └───────────┘ │ │ │
│ ┌───────────┐ │ │ │
│ │ EC2 │ │ │ AMI 복사 │
│ │ Servers │──┼─────────────→│ (이미지 저장) │
│ └───────────┘ │ │ │
└─────────────────┘ └─────────────────┘
재해 발생 시: 백업에서 새 인프라 생성 (수 시간)
| 항목 | 값 |
|---|---|
| RTO | 수 시간 ~ 24시간 |
| RPO | 마지막 백업 이후 (시간 단위) |
| 비용 | 💰 (가장 저렴) |
| 복잡도 | ⭐ (가장 단순) |
적합한 경우: 비핵심 시스템, 개발/테스트 환경, 비용이 중요한 경우
2. Pilot Light (파일럿 라이트)
핵심 시스템만 DR 리전에 최소한으로 유지하고, 재해 시 나머지를 빠르게 프로비저닝합니다.
Primary Region DR Region
┌─────────────────┐ ┌─────────────────┐
│ ┌───────────┐ │ │ ┌───────────┐ │
│ │ Aurora │ │ 복제 │ │ Aurora │ │
│ │ Primary │──┼─────────────→│ │ Replica │ │
│ │ (Active) │ │ │ │ (Standby) │ │
│ └───────────┘ │ │ └───────────┘ │
│ ┌───────────┐ │ │ │
│ │ App (10x) │ │ │ AMI 준비 │
│ │ Running │ │ │ (중지 상태) │
│ └───────────┘ │ │ │
└─────────────────┘ └─────────────────┘
재해 발생 시: App 서버 시작, Auto Scaling 확장
| 항목 | 값 |
|---|---|
| RTO | 수십 분 ~ 수 시간 |
| RPO | 수 분 (비동기 복제 지연) |
| 비용 | 💰💰 (중저) |
| 복잡도 | ⭐⭐ (중간) |
적합한 경우: 핵심 비즈니스 시스템, 비용과 복구 시간의 균형이 필요한 경우
3. Warm Standby (웜 스탠바이)
DR 리전에 축소된 규모로 전체 시스템을 실행합니다.
Primary Region DR Region
┌─────────────────┐ ┌─────────────────┐
│ ┌───────────┐ │ │ ┌───────────┐ │
│ │ Aurora │ │ 복제 │ │ Aurora │ │
│ │ Primary │──┼─────────────→│ │ Replica │ │
│ │ (Active) │ │ │ │(Read-only)│ │
│ └───────────┘ │ │ └───────────┘ │
│ ┌───────────┐ │ │ ┌───────────┐ │
│ │ App (10x) │ │ │ │ App (2x) │ │
│ │ Running │ │ │ │ Running │ │
│ └───────────┘ │ │ └───────────┘ │
└─────────────────┘ └─────────────────┘
재해 발생 시: Aurora 승격, Auto Scaling 확장
| 항목 | 값 |
|---|---|
| RTO | 수 분 ~ 수십 분 |
| RPO | 수 초 ~ 수 분 |
| 비용 | 💰💰💰 (중고) |
| 복잡도 | ⭐⭐⭐ (높음) |
적합한 경우: 빠른 복구가 필요한 핵심 시스템, 일부 다운타임 허용 가능
4. Multi-Site Active-Active (액티브-액티브)
두 리전 모두에서 동시에 트래픽을 처리합니다.
Primary Region Secondary Region
┌─────────────────┐ ┌─────────────────┐
│ ┌───────────┐ │ 양방향 │ ┌───────────┐ │
│ │ DynamoDB │ │ 복제 │ │ DynamoDB │ │
│ │ Global │◄─┼─────────────►│ │ Global │ │
│ │ Table │ │ │ │ Table │ │
│ └───────────┘ │ │ └───────────┘ │
│ ┌───────────┐ │ │ ┌───────────┐ │
│ │ App (10x) │ │ │ │ App (10x) │ │
│ │ Active │ │ │ │ Active │ │
│ └───────────┘ │ │ └───────────┘ │
└─────────────────┘ └─────────────────┘
│ │
└────────────┬───────────────────┘
│
┌──────┴──────┐
│ Route 53 │
│ (Weighted/ │
│ Latency) │
└─────────────┘
| 항목 | 값 |
|---|---|
| RTO | 실시간 (거의 0) |
| RPO | 실시간 (거의 0) |
| 비용 | 💰💰💰💰 (가장 높음) |
| 복잡도 | ⭐⭐⭐⭐ (가장 높음) |
적합한 경우: 미션 크리티컬 시스템, 다운타임 허용 불가, 글로벌 사용자
DR 전략 종합 비교
비용 vs 복구 시간 매트릭스
비용
↑
│ ┌───────────────┐
│ │ Active-Active │
│ └───────────────┘
│ ┌──────────────┐
│ │ Warm Standby │
│ └──────────────┘
│ ┌─────────────┐
│ │ Pilot Light │
│ └─────────────┘
│ ┌─────────────────────┐
│ │ Backup and Restore │
│ └─────────────────────┘
└─────────────────────────────────────────────→ 복구 시간 (RTO)
빠름 느림
전략별 상세 비교표
| 전략 | RTO | RPO | 비용 | 복잡도 | 자동화 수준 |
|---|---|---|---|---|---|
| Backup/Restore | 24시간+ | 시간 단위 | $ | 낮음 | 수동 |
| Pilot Light | 시간 | 분 단위 | $$ | 중간 | 반자동 |
| Warm Standby | 분 | 초~분 | $$$ | 높음 | 자동 |
| Active-Active | ~0 | ~0 | $$$$ | 매우 높음 | 완전 자동 |
전략별 AWS 서비스 구성
| 전략 | 데이터베이스 | 컴퓨팅 | 네트워킹 |
|---|---|---|---|
| Backup/Restore | RDS 스냅샷 + S3 CRR | AMI 복사 | Route 53 수동 변경 |
| Pilot Light | Aurora 글로벌 (복제만) | EC2 AMI (중지) | Route 53 Failover |
| Warm Standby | Aurora 글로벌 (축소 운영) | EC2 최소 운영 | Route 53 Failover |
| Active-Active | DynamoDB 글로벌 테이블 | 양쪽 풀 스케일 | Route 53 Latency/Weighted |
시험 팁
시험 핵심: 문제에서 RTO/RPO 요구사항이 주어지면, 그에 맞는 DR 전략을 선택하세요. "다운타임 최소화" = Active-Active, "비용 최소화" = Backup/Restore입니다.
시나리오별 아키텍처 선택
시나리오 1: 전자상거래 플랫폼
요구사항: 99.99% 가용성, 24/7 운영, 글로벌 사용자
추천: Multi-Region Active-Active
┌─────────────┐
│ Route 53 │
│ (Latency) │
└──────┬──────┘
┌────────────┴────────────┐
▼ ▼
┌──────────┐ ┌──────────┐
│ Seoul │ │ Tokyo │
│ Region │◄────────────►│ Region │
│ (Active) │ DynamoDB │ (Active) │
└──────────┘ Global └──────────┘
Table
시나리오 2: 금융 거래 시스템
요구사항: 데이터 무손실 (RPO=0), 빠른 복구 (RTO 15분 미만)
추천: Warm Standby + 동기식 복제
Primary (Seoul) DR (Tokyo)
┌────────────────┐ ┌────────────────┐
│ Aurora Primary │ ──동기──→│ Aurora Replica │
│ (Writer) │ (sync) │ (Promoted) │
└────────────────┘ └────────────────┘
│ │
App (Full) App (Warm)
│ │
└───── Route 53 ────────────┘
(Failover)
시나리오 3: 개발/테스트 환경
요구사항: 비용 최소화, RTO 24시간 허용
추천: Backup and Restore
Primary Region S3 (백업)
┌─────────────────┐ ┌─────────────────┐
│ Dev/Test Env │──── 일일 ───→│ 스냅샷/AMI │
│ │ 백업 │ Cross-Region │
└─────────────────┘ └─────────────────┘
재해 시: CloudFormation으로 DR 리전에 재생성
시나리오 4: 지역 규정 준수가 필요한 서비스
요구사항: EU 데이터는 EU에, 한국 데이터는 한국에 저장
추천: Multi-Region with Data Sovereignty
EU Users ─→ Frankfurt Region ─→ EU Data
│
│ 메타데이터만 공유
│
KR Users ─→ Seoul Region ─→ KR Data
구현 체크리스트
Multi-AZ 구현 체크리스트
□ RDS Multi-AZ 활성화
□ ELB를 여러 AZ에 분산
□ Auto Scaling 그룹에 여러 AZ 지정
□ EFS 또는 Multi-AZ 지원 스토리지 사용
□ 애플리케이션의 AZ 장애 대응 테스트
Multi-Region 구현 체크리스트
□ DR 전략 및 RTO/RPO 정의
□ 리전 간 데이터 복제 설정
□ Aurora Global Database 또는
□ DynamoDB Global Tables 또는
□ S3 Cross-Region Replication
□ Route 53 Health Check 설정
□ Route 53 Failover Routing 구성
□ DR 리전 인프라 프로비저닝
□ 정기적인 DR 테스트 (Game Day) 수행
□ Runbook 문서화
시험 출제 포인트
자주 나오는 문제 유형
-
RTO/RPO 기반 DR 전략 선택
- "RTO 15분, RPO 1시간" → Warm Standby
- "다운타임 불가" → Active-Active
-
비용 최적화 vs 가용성
- "비용 최소화하면서 DR 구현" → Pilot Light
- "예산 무관, 최고 가용성" → Active-Active
-
서비스별 Multi-AZ/Multi-Region
- RDS Multi-AZ → 동기식 복제, 자동 페일오버
- Aurora Global → 비동기식, 1초 미만 복제
-
Route 53 역할
- Health Check + Failover Routing → DR 페일오버
- Latency Routing → Active-Active 트래픽 분산
핵심 암기 포인트
| 키워드 | 연상 |
|---|---|
| AZ 장애 대비 | Multi-AZ |
| 리전 장애 대비 | Multi-Region |
| 동기식 복제 | Multi-AZ, RPO=0 |
| 비동기식 복제 | Multi-Region, RPO>0 |
| 최소 비용 DR | Backup and Restore |
| 최소 RTO | Active-Active |
| 핵심만 유지 | Pilot Light |
| 축소 운영 | Warm Standby |
FAQ
Q1: Multi-AZ만으로 충분한가요?
A: AZ 장애에는 충분하지만, 리전 전체 장애(자연재해, 대규모 정전)에는 대비할 수 없습니다. 비즈니스 연속성이 중요하다면 Multi-Region을 고려하세요.
Q2: Active-Active에서 데이터 충돌은 어떻게 처리하나요?
A: DynamoDB Global Tables는 "last writer wins" 방식으로 충돌을 해결합니다. 더 세밀한 제어가 필요하면 애플리케이션 레벨에서 충돌 해결 로직을 구현해야 합니다.
Q3: DR 테스트는 얼마나 자주 해야 하나요?
A: AWS는 최소 분기별 DR 테스트(Game Day)를 권장합니다. 중요한 시스템은 월별로 테스트하고, 테스트 결과를 문서화하세요.
Q4: Pilot Light와 Warm Standby의 실질적 차이는?
A:
- Pilot Light: 데이터베이스만 실행, 앱 서버는 중지 상태
- Warm Standby: 전체 스택이 실행 중이지만 축소된 규모
Warm Standby가 더 빠른 복구를 제공하지만 비용이 더 높습니다.
Q5: Aurora Global Database vs DynamoDB Global Tables 선택 기준은?
A:
- Aurora Global: 관계형 데이터, SQL 필요, ACID 트랜잭션
- DynamoDB Global: NoSQL, 밀리초 복제, Active-Active 쓰기
마무리
Multi-AZ와 Multi-Region은 서로 배타적이 아닌 상호 보완적입니다:
- 기본: Multi-AZ로 고가용성 확보
- 확장: Multi-Region으로 재해복구 능력 추가
- DR 전략: 비즈니스 요구사항(RTO/RPO)에 맞게 선택
비용과 복잡도는 가용성 요구사항에 비례합니다. SAA-C03 시험에서는 주어진 요구사항에 가장 비용 효율적이면서 요구사항을 충족하는 솔루션을 선택하는 것이 핵심입니다.