🚨 AWS Disaster Recovery — Whitepaper Summary#

Disaster (재해)란?#

워크로드 또는 시스템이 Primary 배포 위치에서 비즈니스 목표를 달성하지 못하도록 방해하는 이벤트.

자연재해, 기술 장애, 인위적 실수 모두 포함.

RTO & RPO#

1
재해 발생
2
    │
3
    ├─── RPO ───→ (마지막 백업 시점)
4
    │                   데이터 손실 범위
5
    │
6
    └─── RTO ───→ (서비스 복구 시점)
7
                    서비스 다운타임 범위

📌 RTO, RPO가 낮을수록 비용과 복잡도 증가 — 비즈니스 요구사항에 맞는 수준 선택 필수

Resiliency vs. DR vs. High Availability#

DR은 HA와 별개이며, HA가 완벽해도 DR 전략은 별도로 필요함.

전략 비교 한눈에 보기#

1
비용/복잡도 (낮음 → 높음):
2
Backup & Restore → Pilot Light → Warm Standby → Multi-Site Active/Active
3

4
RTO/RPO (높음 → 낮음, 즉 복구 시간 길어짐):
5
Multi-Site Active/Active → Warm Standby → Pilot Light → Backup & Restore

전략 1: Backup & Restore (백업 및 복원)#

개념: 데이터를 정기적으로 백업 → 재해 발생 시 복원

1
[Primary Region]                    [Recovery Region]
2
EC2 / RDS / EBS 등
3
    │
4
    ├── 스냅샷 생성 (같은 리전)
5
    └── 스냅샷 복사 ─────────────────→ S3 / Glacier 저장
6
                                         (재해 시 복원)
7
                                         인프라도 IaC로 재배포

특성:

• 가장 단순하고 가장 저렴한 전략
• Recovery 시 인프라 배포 + 코드 배포 + 데이터 복원 모두 필요 → 높은 RTO
• PITR(Point-in-Time Recovery) 활용 시 RPO를 약 5분까지 낮출 수 있음
• 모든 워크로드에 기본 적용 (다른 전략과 함께 사용)

AWS 서비스:

• AWS Backup: EC2, EBS, RDS, DynamoDB, EFS, FSx 등 중앙 집중 백업 관리
• S3 + S3 Glacier: 백업 저장 (Glacier: 수시간 복원)
• CloudFormation / CDK: 인프라 코드(IaC)로 복원 시간 단축
• Amazon EventBridge + Lambda: 감지 자동화 → RTO 단축

적합한 경우:

• 비즈니스 크리티컬하지 않은 워크로드
• 단일 AZ/데이터 센터 장애 수준의 재해만 고려할 때
• 비용 절감이 최우선일 때 (cost-effective)

전략 2: Pilot Light (파일럿 라이트)#

개념: 데이터는 항상 복제 유지 → 핵심 인프라만 Recovery Region에 배포 → 컴퓨팅(EC2 등)은 꺼진(Shut-off) 상태

1
[Primary Region]               [Recovery Region]
2
앱 서버 (Active)               앱 서버 = 0개 (배포 안 됨)
3
RDS Primary ─── Async 복제 ──→ RDS Replica (항상 실행)
4
ELB / ASG                      ELB / ASG (배포됨, 트래픽 없음)
5
    │                               │
6
    │       재해 발생               │
7
    └───────────────────────────────→
8
                    AMI에서 EC2 인스턴스 배포 + 스케일 아웃
9
                    DNS/Global Accelerator로 트래픽 전환

특성:

• 데이터는 항상 라이브 복제 (DB는 항상 켜짐)
• 컴퓨팅 리소스는 재해 시 비로소 배포 → 배포 시간 포함 = RTO 수십 분
• Warm Standby 대비 비용 절감 (컴퓨팅 비용 없음)
• Pilot Light vs Warm Standby 핵심 차이: Pilot Light는 컴퓨팅 없음 → 재해 시 “Turn on”(배포) 필요

AWS Elastic Disaster Recovery (DRS):

• Pilot Light 전략을 기반으로 구현
• 에이전트 기반 블록 레벨 연속 복제 (Block-level replication)
• On-premises/EC2 → AWS로 복제 가능 (단, RDS 제외 — EC2 기반 DB만)
• RPO: 초 단위 / RTO: 분 단위 달성 가능
• Staging Area에 복제본 유지 (저비용 스토리지 + 최소 컴퓨팅)
• 비파괴적(Non-disruptive) 테스트 드릴 지원
• Failover/Failback 모두 지원

AWS 서비스:

• Aurora Global Database (복제)
• Amazon S3 + CloudFormation (백업 + IaC)
• Route 53 / Global Accelerator (트래픽 전환)
• AWS Elastic Disaster Recovery

전략 3: Warm Standby (웜 스탠바이)#

개념: Recovery Region에 축소된(Scaled-down) 완전한 기능의 환경 항상 실행 → 재해 시 스케일 업(Scale up)만 하면 됨

1
[Primary Region]               [Recovery Region]
2
앱 서버 × N개 (Full)          앱 서버 × 1개 (Minimum) ← 항상 실행
3
RDS Primary ─── 복제 ───────→ RDS Replica (항상 실행)
4
ELB / ASG (Full)               ELB / ASG (Minimum)
5
    │                               │
6
    │       재해 발생               │
7
    └───────────────────────────────→
8
                    Scale Out만 하면 됨 (배포 불필요)
9
                    DNS/Global Accelerator로 트래픽 전환

특성:

• 항상 최소한의 프로덕션 환경이 실행 중 → 즉시 일부 트래픽 처리 가능
• 재해 시 스케일 업만 필요 → Pilot Light보다 낮은 RTO
• Pilot Light와 비교: 코드와 인프라가 이미 실행 중인 것이 차이
• Full Scale = “Hot Standby”라고도 불림

Pilot Light vs Warm Standby 차이 요약:

AWS 서비스:

• Aurora Global Database / RDS Multi-Region Replica
• EC2 Auto Scaling (스케일 업)
• Route 53 / Global Accelerator (Failover 라우팅)

전략 4: Multi-Site Active/Active (멀티 사이트 액티브/액티브)#

개념: 2개 이상의 AWS Region에서 동시에 트래픽 처리 → 한 리전 장애 시 트래픽만 재라우팅

1
[Region A: Active]             [Region B: Active]
2
앱 서버 (Full)                 앱 서버 (Full)
3
RDS ←──── 양방향 복제 ─────→  RDS (Aurora Global)
4
    ↑                              ↑
5
    └──── Route 53 / Global Accelerator ────┘
6
              (두 리전 모두 트래픽 수신)
7

8
재해 발생 시: 트래픽을 장애 리전에서 빼는 것만으로 복구

특성:

• RPO: Near-zero / RTO: Near-zero 또는 Zero
• 비동기 데이터 복제로 Near-zero RPO 달성
• 가장 높은 비용과 복잡도
• 쓰기 충돌(Write Conflict) 관리 필요 (두 리전에 동시 Write 가능)
• 데이터 복제는 일부 재해로부터만 보호 → PITR(Point-in-Time Recovery)도 함께 필요

트래픽 라우팅:

• Route 53: 지역별 라우팅 정책 (Geoproximity, Latency 등), 비율 기반 가중치
• Global Accelerator: AWS Edge Network 활용 → 낮은 지연 시간, DNS 캐시 문제 없음, Traffic Dial로 리전별 비율 설정

핵심 원칙#

• DR 구현을 검증하고 DR 리전으로의 Failover를 정기 테스트하여 RTO/RPO 달성 여부 확인
• “거의 실행되지 않는 복구 경로” 패턴 피하기: 드물게 테스트된 경로는 실제 장애 시 실패 위험

테스트해야 하는 이유 (실제 사례):

1
가정: Secondary DB가 Read-only 쿼리를 담당
2
     Primary 장애 시 Secondary로 Write 가능하다고 생각
3

4
현실: 오랫동안 Failover 테스트를 안 했다면
5
     → Secondary 용량이 부족하거나
6
     → 서비스 쿼터가 충족 안 될 수 있음

DR 테스트 방법#

NOTE

💡 AWS Resilience Hub: RTO/RPO 목표 달성 여부를 지속적으로 검증하는 서비스