기준: SAA-C03 시험 가이드오류 제보
이번 주는 "장애를 어떻게 견디고, 재해에서 어떻게 복구하며, 워크로드를 어떻게 옮기는가"라는 세 주제를 다뤘다. 표면적으로는 별개로 보이지만, 셋은 하나의 질문으로 수렴한다 — "이 시스템이 견뎌야 할 최악은 무엇이고, 그것을 견디는 데 얼마를 쓸 것인가." 단일 AZ 장애인지 리전 전체 마비인지, 데이터 1초도 못 잃는지 한 시간은 괜찮은지, 옮기는 길을 막는 게 다운타임인지 대역폭인지 — 이 제약을 정확히 읽어 적정 비용의 도구로 매핑하는 것이 SAA 도메인 2(복원력)의 본질이다. 이 글은 한 주의 핵심을 결정 트리로 압축하고, 실제 시험에 나오는 복합 시나리오로 그 매핑을 몸에 새긴다.
이번 주 모든 결정은 결국 세 축 위에 놓인다.
첫째, 장애의 반경(blast radius)이 격리 수준을 정한다. 한 AZ가 죽어도 무중단이어야 하면 Multi-AZ(같은 리전 내 동기 복제, RPO 0). 리전 전체가 마비돼도 살아야 하면 Multi-Region(비동기 복제, DR). "Multi-AZ는 DR이 아니다"가 한 주의 가장 큰 함정이었다 — Day 1의 2021 us-east-1 사고가 "리전도 장애 단위"임을 보여줬다.
둘째, RTO와 RPO가 DR 단계와 비용을 정한다. RPO(잃어도 되는 데이터)는 복제 방식이, RTO(허용 다운타임)는 컴퓨팅 준비 상태가 결정한다. 둘 다 작아질수록 DR 스펙트럼의 비싼 쪽(Backup-Restore → Pilot Light → Warm Standby → Active-Active)으로 올라간다. Day 2의 핵심은 "요구되는 복원력을 초과하는 설계는 그 자체로 낭비"라는 것 — 느슨한 RTO/RPO엔 싼 단계로 충분하다.
셋째, 제약의 종류가 도구를 정한다. 트래픽을 어디로 보낼지는 Route 53 라우팅 정책이(Day 3), 워크로드를 어떻게 옮길지는 마이그레이션 도구가(Day 4) 푼다. DB의 적은 다운타임(DMS+CDC), 대용량 파일의 적은 대역폭(Snow vs DataSync), 서버 이전의 도구는 MGN이다.
| 비교 | 왼쪽 | 오른쪽 | 가르는 기준 |
|---|---|---|---|
| Multi-AZ vs Multi-Region | HA(동기, RPO 0) | DR(비동기) | 장애 반경(AZ냐 리전이냐) |
| Aurora Global vs Cross-Region RR | 단일 라이터, 승격 수 분 | 비동기 읽기 사본 | 승격 속도·전용 복제 인프라 |
| DynamoDB Global Tables vs Aurora Global | 다중 리전 동시 쓰기(AP) | 단일 리전 쓰기(일관성) | 쓰기 가능 리전 수 |
| Pilot Light vs Warm Standby | 앱 OFF, DB 복제 | 축소 풀스택 ON | 컴퓨팅 준비 상태 |
| DMS vs MGN | DB 데이터(CDC) | 서버 전체(블록) | 옮기는 단위 |
| MGN vs DRS | 일회성 마이그레이션 | 지속적 DR | 목적(이전이냐 복구냐) |
| DataSync vs Storage Gateway | 마이그/복제(일회·정기) | 영구 하이브리드 캐시 | 일시적이냐 영구냐 |
| Snow vs DataSync | 오프라인(네트워크 부족) | 온라인(대역폭 충분) | 회선×데이터량 전송 시간 |
| Alias vs CNAME | 루트 도메인 가능, 무료 | zone apex 불가 | zone apex 제약 |
| Latency vs Geolocation | 가장 빠른 리전 | 사용자 위치(규제·언어) | 속도냐 위치냐 |
💡 관련 이론: 이 모든 비교의 밑바닥에는 Day 1에서 본 CAP/PACELC가 깔려 있다. Multi-Region에서 "여러 리전 동시 쓰기"를 택하면(DynamoDB Global Tables) 일관성을 양보하고 가용성을 얻는 AP 선택이고, "한 리전만 쓰기"를 택하면(Aurora Global) 일관성을 지키되 페일오버라는 절차적 RTO를 치른다. DR 4단계도 결국 "분단·장애 시 얼마나 빨리·얼마나 정확히 복구하느냐"를 비용과 맞바꾸는 CAP의 비즈니스 번역이다. 복원력 설계가 암기가 아니라 추론으로 풀리는 이유가 이것이다 — 분산 시스템의 근본 제약 위에서 비용과 견딤을 저울질하는 일관된 논리다.
⚠️ 함정: 한 주 동안 반복된 4대 함정을 묶어 둔다. ① Multi-AZ를 DR로 착각 — AZ는 같은 리전 내 격리라 리전 장애엔 무력. ② RTO와 RPO 혼동 — 서로 독립 축이라 "RPO는 느슨하지만 RTO는 빡빡한" 시나리오가 흔함. ③ 루트 도메인에 CNAME — zone apex 제약으로 불가, Alias가 답. ④ 백업을 운영과 같은 계정에 둠 — 운영을 지운 손이 백업도 지움(Code Spaces). 이 넷이 보이면 반사적으로 오답을 걸러낼 수 있어야 한다.
[ 멀티 리전 DR + 마이그레이션 통합 ]
┌─ Region A (Primary, 운영) ────────────────┐
│ Route 53 Alias(example.com) → CloudFront │
│ → ALB → ECS(Auto Scaling, 다중 AZ) │
│ → Aurora Global Writer (RPO ~1초) │
│ S3 (Standard, 3+ AZ) ──CRR──▶ Region B │
│ AWS Backup → Vault Lock(WORM) + 별도 계정 │
└────────────────────────────────────────────┘
│ 비동기 복제
▼
┌─ Region B (DR, Warm Standby) ──────────────┐
│ ALB(상시) → ECS(축소, 장애 시 Scale Up) │
│ Aurora Global Reader (장애 시 수 분 승격) │
└────────────────────────────────────────────┘
Route 53 Failover/ARC: Primary 비정상 → Secondary
(Health Check + ARC Readiness로 준비 상태 상시 점검)
[ 마이그레이션 유입 경로 ]
온프레 DB(Oracle) ─SCT+DMS(CDC)─▶ Aurora
온프레 VM 200대 ─MGN(블록 복제)─▶ EC2
온프레 파일(NFS) ─DataSync(대역폭 충분)─▶ S3
페타바이트 오프라인 ─Snowball Edge Cluster─▶ S3
이 한 장에 주의 모든 개념이 들어 있다 — Multi-AZ HA(ECS 다중 AZ), Multi-Region DR(Aurora Global + CRR), Warm Standby 단계, Route 53 Alias·Failover·ARC, 불변 백업, 그리고 네 갈래 마이그레이션 경로. 시험의 복합 문제는 대개 이 그림의 한 조각을 떼어 "여기서 무엇을 골라야 하나"를 묻는다.
사례: Day 2에서 본 Netflix의 카오스 엔지니어링은 이 통합 아키텍처를 "문서가 아니라 검증된 시스템"으로 만드는 마지막 조각이다. 아무리 정교하게 그려도 실제로 Region A를 죽여 보지 않으면 Region B의 ECS가 정말 스케일 업하는지, Aurora 승격이 정말 1분에 끝나는지, ARC Readiness가 정말 부족을 잡아내는지 알 수 없다. "테스트하지 않은 백업은 백업이 아니고, 연습하지 않은 DR은 DR이 아니다"라는 한 주의 운영 철학이 이 그림에 생명을 불어넣는다. SAA가 아키텍트 자격증인 이유도, 단순히 서비스를 나열하는 게 아니라 "이 설계가 진짜 견디는가"를 검증 가능하게 만드는 판단을 묻기 때문이다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
한 글로벌 핀테크가 리전 전체 장애 시에도 RTO 30초·RPO 거의 0으로 서비스를 이어가야 한다. 비용은 부차적이다. 가장 적절한 아키텍처는?
문제 2
한 회사가 내부 보고서 시스템의 DR을 RTO 12시간·RPO 6시간으로 설계하며 비용을 최소화한다. 적절한 전략은?
문제 3
한 게임사가 전 세계 5개 리전에서 플레이어 인벤토리를 모든 리전에서 동시에 읽고 쓰는 저지연 NoSQL로 운영하려 한다. 적절한 서비스는?
문제 4
한 연구 기관이 외딴 지역(저대역폭)의 200TB 데이터를 S3로 옮겨야 한다. 네트워크로는 수개월이 걸린다. 적절한 방법은?
문제 5
한 회사가 루트 도메인 shop.com을 CloudFront 배포에 연결하려는데 CNAME 설정이 거부된다. 올바른 해결책은?
문제 6
한 SaaS가 전 세계 사용자에게 네트워크 지연이 가장 낮은 리전으로 트래픽을 라우팅하려 한다. 적절한 Route 53 정책은?
문제 7
한 금융사가 규제 준수를 위해 백업이 보존 기간 내 루트 사용자조차 삭제할 수 없도록 변조 불가여야 한다. 적절한 통제는?
문제 8
한 팀이 온프레미스 데이터센터의 200대 VM을 코드 변경 없이 AWS EC2로 영구 이전하려 한다. 적절한 도구는?
문제 9
한 회사가 DR 비용을 낮추되, 데이터는 다른 리전에 지속 복제하고 앱 서버는 평소 꺼두었다가 장애 시 빠르게 부팅하려 한다. 이 전략과 이를 자동화하는 서비스의 조합은?
문제 10
한 아키텍트가 멀티 리전 Active-Active에서 페일오버 시 헬스 체크에 의존하지 않고 명시적으로 리전 트래픽을 즉시 전환하며, 보조 리전의 준비 상태를 상시 점검하려 한다. 적절한 도구는?
문제 11
한 회사가 Oracle 데이터베이스를 Aurora PostgreSQL로 옮기되 다운타임을 수 분 이내로 최소화하려 한다. 그런데 마이그레이션 시작 후 CDC가 변경을 따라잡지 못한다. 올바른 접근과 문제 원인의 조합은?
문제 12
한 회사가 단일 AZ 장애에도 RDS의 쓰기가 무중단이고 RPO가 0이어야 하며, 동시에 us-east-1 리전 전체 장애에도 다른 리전에서 서비스를 이어가야 한다. 가장 적절한 조합은?