기준: SAP-C02 시험 가이드오류 제보
DR(Disaster Recovery)을 "백업을 해두는 것"으로 이해하면 SAA 수준이다. Pro에서는 RTO(Recovery Time Objective, 복구 시간 목표)와 RPO(Recovery Point Objective, 데이터 손실 허용 시간)를 비즈니스가 정의하고, 그 숫자에 맞는 DR 전략을 비용 효율적으로 설계해야 한다. AWS는 이를 위해 4가지 전략(Backup/Restore, Pilot Light, Warm Standby, Multi-Site)과 자동 검증 도구(Resilience Hub, FIS, DRS, Route 53 ARC)를 제공한다. 오늘은 14주차에 본 DR 전체를 한 시나리오로 정리한다.
| 전략 | RTO | RPO | 비용 | 적합 워크로드 |
|---|---|---|---|---|
| Backup & Restore | 수 시간 ~ 수 일 | 수 시간 | ★ (가장 저렴) | 비중요 시스템, 개발/스테이징 |
| Pilot Light | 10분 ~ 1시간 | 분 단위 | ★★ | 중요도 중간 |
| Warm Standby | 수 분 ~ 30분 | 초 ~ 분 | ★★★ | 미션 크리티컬 |
| Multi-Site Active-Active | 0 ~ 수 초 | 0 ~ 수 초 | ★★★★ (가장 비싼) | 금융·결제·게임 매치메이킹 |
4가지 전략은 본질적으로 "DR 환경에 평소 얼마나 자원을 켜두느냐"의 스펙트럼이다. Backup/Restore는 0% 켜둠, Multi-Site는 100% 켜둠. Pilot Light는 DB만 켜두고 앱은 꺼둠(failover 시 시작), Warm Standby는 축소된 capacity로 항상 켜둠(failover 시 확장). 비용은 capacity에 비례, RTO는 capacity에 반비례.
Gartner의 RTO/RPO 매트릭스는 비즈니스 영향 분석(BIA, Business Impact Analysis)의 산출물이다. RTO 1분 vs 1시간의 차이는 수십 배 비용이 들 수 있으므로, 비즈니스 부서가 "다운타임 1분당 손실액"을 명시해야 합리적 설계가 가능. AWS는 이를 WA Tool의 Reliability Pillar 질문에 포함시켜 워크로드 등록 시 명시하게 한다. 이 RTO/RPO 용어 자체는 ISO 22301(사업 연속성)·NIST SP 800-34(비상계획 가이드)에서 공식 정의된 표준이다.
(가상 사례) 한 작은 SaaS가 production을 us-east-1에서 운영하며 백업만 us-west-2 S3에 CRR(Cross-Region Replication)로 보낸다. 리전 장애 시 us-west-2에서 CloudFormation으로 인프라 재생성 → 6시간 RTO. 비즈니스 SLA가 24시간이라 충분. 이 패턴의 정당성은 2017년 S3 us-east-1 대장애(4시간)가 증명했다 — 백업이 같은 리전에만 있었다면 그 리전 장애 시 백업도 함께 사라졌을 것이다. 백업은 반드시 다른 리전·계정에 격리되어야 한다.
🎯 시나리오: "한 글로벌 결제 회사가 SLA 99.99%(연간 다운타임 52분)를 약속한다. DR 전략은?" — 답: Multi-Site Active-Active + Aurora Global + DDB Global + Route 53 ARC Routing Control. 4 9 SLA는 사실상 Multi-Site 외에는 불가능. 비용 2배지만 1분 다운타임 = 수천만 원 손실이라 정당화됨.
⚠️ 함정: "RTO를 더 짧게 하면 항상 좋다"는 함정이다. Pro 사고는 비즈니스 RTO/RPO를 충족하는 가장 저렴한 전략을 고르는 것이다. SLA가 24시간인데 Multi-Site를 택하면 충족할 필요 없는 RTO를 위해 비용 2배를 낭비하는 over-engineering이다. 시험에서 "비용 효율 + RTO 충족"이 함께 나오면 RTO를 만족하는 최저 비용 전략을 골라야 한다.
| 모드 | 변경 가능 여부 | 사용처 |
|---|---|---|
| Governance | IAM 권한 있으면 가능 | 일반·실수 방지 |
| Compliance | 어떤 권한으로도 불가 | 규제(7년 보관) |
Compliance 모드는 한 번 활성화하면 AWS 본사 root 사용자도 변경 불가. 백업이 영구 삭제되거나 변경되지 않음을 법적으로 보장. 금융권 SEC Rule 17a-4, FINRA 4511 등 WORM(Write Once Read Many) 요구사항을 만족. S3 Object Lock Compliance 모드와 동일한 철학.
2021년 Colonial Pipeline 랜섬웨어 사건에서 회사는 약 440만 달러 몸값을 지불했다. 만약 모든 백업이 변경 불가능한 immutable storage(Compliance Lock)에 별도 계정으로 격리돼 있었다면 몸값 없이 복구가 가능했을 것이다. 이 사건 이후 immutable backup은 "있으면 좋은 것"에서 "랜섬웨어 시대의 필수"로 격상됐다. 헬스케어 회사가 HIPAA 준수로 환자 백업을 7년 보관할 때도 Backup Vault Compliance Lock + Cross-Region Copy로 의도적·우발적 삭제를 모두 차단하고 감사관에게 정책 출력본으로 컴플라이언스를 증명한다.
Chaos Engineering은 Netflix가 2010년 도입한 패러다임. "production은 항상 부분적으로 망가져 있다"는 가정 하에 정기적으로 의도적 장애를 주입해 시스템이 graceful degradation을 하는지 검증. AWS는 2021년 FIS로 관리형 서비스화. Stop Condition이 핵심 차별화 — 의도적 장애가 실제 사고로 번지지 않도록 자동 안전 정지(fail-safe)를 제공한다. 2012년 크리스마스이브 Netflix 대장애(us-east-1 ELB 장애) 이후 Netflix는 전체 리전을 죽이는 "Chaos Kong"까지 만들어 정기 검증했다 — 페일오버는 평소에 연습한 만큼만 실제 위기에서 작동한다.
| 서비스 | 용도 | 동작 |
|---|---|---|
| MGN | 일회성 마이그레이션 | 온프레 → AWS 옮긴 후 종료 |
| DRS | 지속적 DR | 온프레/타 클라우드 → AWS 지속 복제 |
🎯 시나리오: "온프레미스 VM 100대를 AWS로 영구 이전(7R의 Rehost)". → MGN. "온프레미스 VM을 그대로 유지하면서 AWS에 24시간 DR 환경 유지". → DRS. 둘은 같은 복제 엔진(과거 CloudEndure)에서 갈라졌지만 목적이 정반대다.
2021년 12월 7일 AWS us-east-1 대장애(약 7시간) 때 일부 기업은 자동 health check가 정상/비정상을 오락가락 판정해 트래픽이 불안정하게 튀는 문제를 겪었다. ARC Routing Control의 데이터 평면은 5개 리전에 분산돼 us-east-1이 죽어도 작동하므로, 운영자가 명시적으로 "지금 us-west-2로 전환"을 결정할 수 있다. 이 장애는 "제어 평면(control plane)이 죽어도 데이터 평면(data plane)은 살게" 설계하라는 교훈을 남겼다.
| 모드 | Failover | Replica 사용 |
|---|---|---|
| Multi-AZ Instance | 60-120초 | Replica는 standby, 트래픽 불가 |
| Multi-AZ Cluster | 35초 | 2개 Replica에 read 트래픽 가능 |
Multi-AZ Cluster는 2022년 출시. 기존 Multi-AZ Instance가 "1 primary + 1 standby(트래픽 불가)"였다면, Cluster는 "1 primary + 2 readable replica"로 진화. semi-synchronous replication으로 primary가 2개 중 1개 replica에 데이터 도달 확인 후 commit ack(쿼럼) → 비동기 replication보다 데이터 손실 위험 ↓, 완전 동기보다 빠름.
⚠️ 함정: Aurora Global secondary는 read-only이지만 DDB Global Tables는 모든 리전에 쓰기 가능. "양 리전 쓰기"라는 키워드가 보이면 DDB Global Tables, 또는 Aurora Global의 write forwarding(write를 primary 리전으로 자동 forward, latency 대가). DDB의 Last Writer Wins는 동시 쓰기 시 한쪽이 조용히 사라지는(lost update) 한계가 있어, 리전별 쓰기 키 분할 설계가 모범이다.
데이터 계층 DR의 모든 선택은 결국 PACELC 정리(CAP 확장)의 지연-일관성 트레이드오프로 환원된다. AZ 간은 수 km(1~2ms)라 동기 복제(RPO 0)가 가능하지만, 리전 간은 수천 km(40ms+)라 거의 항상 비동기(RPO>0)다. "리전 간 RPO 0"을 요구하면 큰 지연 대가 또는 불가능을 의심해야 한다.
| 키워드 | 정답 |
|---|---|
| "RPO 0 + Active-Active 양 리전 쓰기" | DDB Global Tables |
| "글로벌 SQL DB + RPO 1초" | Aurora Global |
| "RDS Failover 30초" | Multi-AZ Cluster |
| "온프레 → AWS 영구 이전" | MGN |
| "온프레 + AWS 지속 DR" | DRS |
| "S3 다중 리전 단일 엔드포인트" | MRAP |
| "백업 7년 변경 불가(root도)" | Backup Vault Compliance Lock |
| "운영 중 의도적 장애 + 자동 중단" | FIS + Stop Condition |
| "DR 격차 자동 식별 + 권고" | Resilience Hub |
| "AZ만 즉시 트래픽 제외" | Route 53 ARC Zonal Shift |
| "사람이 명시적 페일오버 결정" | Route 53 ARC Routing Control |
| "백업 정책 준수 자동 평가" | Backup Audit Manager |
| "RTO 충족 + 비용 최소" | 충족하는 최저 전략 |
DR은 비즈니스 RTO/RPO 정의 → 4전략 중 선택 → 검증 자동화의 워크플로다. 비용·RTO·RPO는 상호 trade-off이므로 무작정 Multi-Site를 선택하면 안 되고, 비즈니스 임팩트 분석으로 적정 수준을 정해야 한다. AWS Backup, Resilience Hub, FIS, DRS, Route 53 ARC를 조합해 "정의 → 구현 → 검증"의 전체 수명주기를 자동화하는 것이 Pro 수준의 설계.
다음 주(Week 15)는 종합 시나리오다. 대기업·스타트업·금융·미디어·정부/헬스케어 각 산업별 종합 케이스를 풀어본다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
RTO 5분 · RPO 1초 · 글로벌 SQL DB가 필요하다.
문제 2
"운영 중 의도적 장애 주입 + 알람 시 자동 중단".
문제 3
규제 요건: 백업 7년 보관 + 즉시 변경·삭제 불가 (AWS root도 불가).
문제 4
양 리전 모두 쓰기 가능한 글로벌 DB.
문제 5
문제 발생한 AZ만 즉시 트래픽에서 제외.
문제 6
온프레미스 VM 200대를 AWS에 24시간 DR 환경으로 유지.
문제 7
RDS Failover를 30초 이내로 달성하고 standby에도 read 트래픽을 분산.
문제 8
DR 격차를 자동으로 식별하고 구체적 개선 권고를 받아 CI/CD에 통합.
문제 9
S3 다중 리전 버킷을 단일 글로벌 엔드포인트로 노출.
문제 10
사람이 명시적으로 의사결정해 failover를 트리거 (자동 health check의 false positive 회피).
문제 11
한 회사가 SLA 24시간 RTO의 스테이징 환경 DR을 비용 최소로 설계하려 한다. 가장 적합한 전략은?
문제 12
한 기업이 워크로드 계정이 랜섬웨어로 탈취되어도 백업만은 복구 가능하도록 보호하려 한다. 가장 견고한 구성은?