Day 5 - Week 10 종합 복습 — 백업·DR·고가용성을 하나의 그림으로

Week 10을 관통하는 질문은 하나였다. "원본이 사라지는 순간, 우리는 어디서 다시 시작할 수 있는가." 그리고 그 답이 두 개의 축으로 갈라졌다 — 무엇을 잃을 수 있나(RPO)와 얼마나 빨리 복구하나(RTO). 백업은 RPO를 줄이는 게임이고, 가용성·DR은 RTO를 줄이는 게임이다. 이번 주의 모든 도구는 이 두 축 위의 어느 점에, 얼마의 비용으로 도달하느냐의 선택이었다.

이 복습은 개념을 나열하지 않고, 도구들이 왜 그렇게 갈라지는지를 다시 엮는다. 그래야 시험에서 처음 보는 시나리오를 만나도 "이건 RPO 문제인가 RTO 문제인가, 같은 리전인가 리전 간인가, 데이터인가 워크로드인가"로 도구를 역산할 수 있다.

한 장으로 보는 Week 10

RPO와 RTO — Week 10 전체를 꿰는 두 축

복구 설계의 모든 결정은 두 숫자로 환원된다. RPO(Recovery Point Objective)는 "얼마나 과거 데이터까지 잃어도 되나" — 마지막 백업/복제 시점과 장애 시점의 간격이다. RTO(Recovery Time Objective)는 "장애부터 복구 완료까지 얼마나 걸려도 되나"다. 이 두 숫자가 작을수록 비용이 가파르게 오른다. RPO 0(데이터 한 건도 못 잃음)은 동기 복제(Multi-AZ)를, RTO 분 단위는 즉시 부팅 가능한 복제(DRS, Aurora Global)를 요구하고, 둘 다 평소에 돈을 태운다.

이 표가 시험 시나리오의 90%를 푼다. "데이터 손실 없이"는 RPO 0 → Multi-AZ. "리전 장애에도 1분 내 복구"는 Aurora Global DB. "평소 비용 최소 + 분 단위 복구"는 DRS. 문제에서 RPO/RTO 요구와 비용 제약을 읽어내면 도구는 거의 자동으로 결정된다.

패턴 1: DLM vs AWS Backup — 가벼움과 통합의 갈림길

같은 "자동 백업"이지만 경계가 분명하다. DLM은 EBS 볼륨·AMI 전용의 경량 스케줄러로, 태그 기반으로 스냅샷을 찍고 보존·Cross-Region 복제를 자동화하며 정책 자체는 무료다. AWS Backup은 RDS·DynamoDB·EFS·FSx·S3까지 아우르는 멀티 서비스 통합 플랫폼으로, Backup Audit Manager로 컴플라이언스까지 검증한다. EBS만이면 DLM, 여러 서비스 + 감사면 AWS Backup이다.

패턴 2: 세 가지 WORM Lock — 같은 모델, 다른 자원

Week 10에는 "발급자조차 못 푸는 불변 보관"이 세 번 등장했다. 전부 같은 WORM 모델(1990년대 금융 규제의 물리 WORM 광디스크에서 유래)을 자원만 바꿔 입힌 것이다.

핵심 공통점: Compliance 모드는 루트 계정·AWS조차 풀 수 없다. "관리자도 못 지운다"가 곧 "공격자도 못 지운다"이고, 이게 Ransomware 방어와 규제 WORM의 본질이다. Governance는 실수 방지 가드레일(권한자 해제 가능)이다.

🔍 더 깊이: 세 Lock이 "Versioning 또는 그에 준하는 불변 버전 추적"을 전제하는 데는 공통 이유가 있다. 불변성(immutability)은 "특정 버전을 고정"하는 것이지 "키를 고정"하는 게 아니다. 같은 키에 덮어쓰기가 가능하면 "변경 불가"라는 약속을 지킬 수 없으므로, 각 쓰기가 고유한 버전(version ID)을 갖고 그 버전을 개별적으로 잠가야 WORM이 성립한다. S3 Object Lock이 Versioning 필수인 것, EBS Snapshot이 본질적으로 시점별 불변 객체인 것, Backup 복구 지점이 개별 식별자를 갖는 것이 전부 같은 이유다. 그래서 규제 감사에서 "이 데이터는 생성 후 변조되지 않았다"를 증명하려면, 변경 불가 플래그만으로는 부족하고 "각 버전이 고유하게 식별·고정됐다"까지 보여야 한다 — 불변 버전 체인이 곧 변조 부재의 증거다.

📚 사례: Snapshot Lock·Vault Lock·Object Lock의 Compliance 모드가 한결같이 "cooling-off 후 발급자도 불가"를 고수하는 건 과잉처럼 보이지만, 실제 규제 감사에서 이 차이가 합격과 불합격을 가른다. 금융·의료 감사자는 "관리자가 마음먹으면 지울 수 있는가"를 묻는다 — 지울 수 있으면(Governance) 그 백업은 변조 가능으로 분류돼 WORM 요건 미충족이다. 반대로 Compliance 모드는 third-party(Cohasset Associates)가 SEC 17a-4·FINRA·CFTC 규정 충족을 검증해 줘, 감사에서 법적 근거로 제출할 수 있다. "불편할 정도로 못 푼다"가 규제 신뢰의 가격이며, 편의(Governance)와 규제(Compliance)를 자원마다 선택하게 한 게 세 Lock의 공통 설계다.

패턴 3: Multi-AZ vs Read Replica — 동기/비동기가 모든 걸 가른다

이 주의 출제 비중이 큰 동시에 오답이 몰리는 지점이다. 표면이 비슷해도 정반대다.

오답 패턴: "가용성"에 Read Replica, "읽기 분산"에 Multi-AZ를 고르는 것. Multi-AZ Standby는 읽기조차 못 받고, Read Replica는 비동기라 RPO 0이 아니다. 둘 다 필요하면 함께 쓴다.

패턴 4: 같은 리전 vs 리전 간 — DR의 경계선

쉽게 묻히는 함정: Multi-AZ는 DR이 아니다. 같은 리전 AZ 장애는 견디지만 리전 전체 장애엔 무력하다(동기 복제라 리전을 못 넘는다). 리전 단위 DR은 별도 도구다.

같은 리전 (AZ 장애 대비)        리전 간 (리전 장애 대비, = DR)
─────────────────────          ─────────────────────────────
RDS Multi-AZ (동기)            Cross-Region Read Replica (RDS)
Multi-AZ DB Cluster            Aurora Global Database (RPO<1s)
S3 (자동 다중 AZ)              S3 Cross-Region Replication
EBS Snapshot                   DLM/Backup Cross-Region Copy
                               DRS (워크로드 페일오버)

패턴 5: 데이터 vs 워크로드 — 무엇을 복구하나

S3 Replication·DLM·AWS Backup은 데이터를 복제·보관한다. 장애 시 그 데이터로 서버를 다시 세우는 건 별도 작업이다. DRS는 워크로드 전체(OS·앱·데이터)를 분 단위로 다른 곳에서 부팅 가능하게 한다. "데이터센터를 통째로 AWS로 페일오버, 평소 비용 최소"는 DRS. "S3 객체만 다른 리전에"는 CRR. "온프레미스 앱은 그대로 두고 백엔드만 S3"는 Storage Gateway.

Week 10 전체가 보여주는 메타 패턴은 "상태(state)와 변화(change)를 분리하면 시간을 다룰 수 있다"이다. EBS 증분 스냅샷(베이스 + 변경 블록), PITR(베이스 스냅샷 + 트랜잭션 로그), Aurora Backtrack(로그 되감기), S3 Versioning(버전 체인)이 모두 "전체 상태를 매번 복사하지 않고, 기준점 + 그 이후의 변화"로 데이터를 관리한다. 이 분리 덕에 임의 시점 복원, 블록 공유, 빠른 되감기가 가능하다. 함수형 영속 자료구조, Git, 이벤트 소싱이 같은 원리를 쓴다 — 상태를 불변의 스냅샷으로, 변화를 추가 전용(append-only) 로그로 두면 과거를 자유롭게 재구성할 수 있다.

---

📝 시나리오 12문제

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

운영자가 사용하지 않는 골든 AMI 수십 개를 deregister했는데 스토리지 비용이 거의 줄지 않았다. 원인과 조치는?

• AAMI 삭제는 비동기로 처리돼 백그라운드 정리에 며칠이 걸리므로 기다리면 스냅샷까지 자동 회수된다
• BAMI deregister는 부팅 레시피만 제거하고 연관 EBS 스냅샷은 그대로 남으므로, 스냅샷을 별도 삭제하거나 DLM으로 정리해야 한다
• CAMI 자체는 스토리지 과금이 없고 스냅샷 비용은 표준 단가라 줄지 않는 게 정상이다
• DAMI로 띄운 EC2 인스턴스를 종료하면 연관 스냅샷이 함께 정리된다

문제 2

회사가 RDS·EBS·DynamoDB·EFS를 하나의 정책으로 통합 백업하고 "모든 prod 리소스가 백업되는지" 자동 검증·보고하려 한다. 적합한 구성은?

• A리소스 유형마다 별도 DLM 정책을 만들어 태그 기반으로 스냅샷을 찍고 Cross-Region 복제까지 자동화
• BAWS Backup의 Backup Plan + Backup Audit Manager Framework
• CEventBridge 스케줄로 Lambda를 띄워 각 서비스의 스냅샷 API를 호출하고 결과를 DynamoDB에 기록·집계
• D수동 스냅샷을 정기적으로 찍고 스프레드시트에 백업 일시·보존 기간을 기록해 점검

문제 3

Ransomware 공격자가 운영 계정 관리자 권한을 탈취해 백업까지 삭제하는 시나리오를 막아야 한다. 규제상 백업은 발급자조차 삭제 불가여야 한다. 가장 강력한 구조는?

• A운영 계정 IAM 정책에 백업 삭제 Deny를 명시하고 SCP로 조직 차원에서 삭제 API를 차단
• BCross-Account로 별도 중앙 계정 Vault에 복제하고 그 금고에 Compliance 모드 Vault Lock 적용
• C백업 빈도를 시간 단위로 높여 삭제돼도 최근 복구 지점이 항상 남도록 RPO를 줄임
• D모든 사용자에 MFA를 강제하고 삭제 작업에 MFA Delete 조건을 부착

문제 4

오후 2시 30분에 실행된 잘못된 DELETE 직전 상태로 RDS를 되돌려야 한다. 어제 새벽 스냅샷밖에 없으면 하루치를 잃는다. 필요한 기능은?

• A어제 새벽 Manual Snapshot을 복원하고 그 이후 변경분은 애플리케이션 로그로 수동 재입력
• BPoint-in-Time Recovery(PITR) — 베이스 스냅샷 + 트랜잭션 로그 재생으로 임의 초 단위 시점을 새 인스턴스로 복원
• CMulti-AZ 페일오버로 Standby를 승격해 DELETE 이전 상태의 사본으로 전환
• DRead Replica를 promote해 복제 지연으로 아직 DELETE가 반영 안 된 사본을 독립 인스턴스로 사용

문제 5

"단일 AZ 장애에서 데이터 손실 없이 자동 복구"가 목표다. 정확한 RDS 기능은?

• ARead Replica를 같은 리전 다른 AZ에 두고 장애 시 promote해 승격
• BMulti-AZ — 다른 AZ Standby에 동기 복제, RPO 0, 자동 페일오버
• C자동 Snapshot을 짧은 주기로 찍어 AZ 장애 시 최신 스냅샷에서 복원
• DCross-Region Read Replica를 두어 AZ 장애 시 다른 리전 사본으로 전환

문제 6

운영 중 DB 읽기 부하(분석·리포트)가 폭증한다. 비용 효율적으로 읽기를 분산하려면?

• ADB 인스턴스를 더 큰 타입으로 수직 확장해 읽기·쓰기 처리량을 함께 키움
• BRead Replica 추가, 별도 endpoint로 읽기 분산
• CMulti-AZ를 활성화해 Standby에 분석·리포트 읽기 쿼리를 분산
• D자동 Snapshot 빈도를 높여 분석은 스냅샷에서 복원한 별도 인스턴스로 처리

문제 7

글로벌 사용자에게 가까운 리전에서 빠른 읽기 + 리전 단위 DR(RPO 수 초)가 필요하다. 가장 적합한 도구는?

• ARDS Multi-AZ로 다른 AZ Standby에 동기 복제해 가용성과 빠른 페일오버를 확보
• BAurora Global Database — 최대 10 Secondary 리전, 스토리지 계층 복제로 RPO 수 초·RTO 수 분
• C단일 리전에 Read Replica를 여러 개 두고 Route 53 Latency 라우팅으로 가까운 사본에 연결
• DDynamoDB를 Multi-AZ로 구성해 글로벌 읽기와 리전 DR을 함께 처리

문제 8

Lambda가 트래픽 폭증 시 RDS에 동시 수천 커넥션을 열어 DB 최대 커넥션 한도를 초과한다. 근본 해결은?

• ADB 인스턴스 타입을 키워 최대 커넥션 한도(max_connections)를 함께 높임
• BRDS Proxy — 커넥션 풀로 소수의 실제 커넥션을 재사용(multiplexing)
• CMulti-AZ를 활성화해 Standby로 커넥션 부하를 분산
• DRead Replica를 추가해 커넥션을 여러 사본으로 분산

문제 9

회사가 S3 데이터를 다른 리전 DR에 자동 복제하려 한다. 필수 전제는?

• ADataSync 태스크를 스케줄로 주기 실행해 다른 리전 버킷으로 객체를 동기화
• BS3 Cross-Region Replication + 소스·대상 양쪽 Versioning 활성화 + IAM Role
• CStorage Gateway File Gateway로 다른 리전 버킷에 객체를 캐시·업로드
• DLifecycle Policy로 객체를 다른 리전의 Glacier 계층으로 전환

문제 10

운영 데이터센터를 AWS로 DR 페일오버 가능하게 하되 평소 비용 최소화, 페일오버 시 분 단위 복구가 필요하다. 어떤 도구인가?

• AS3 Replication으로 데이터센터 데이터를 다른 리전 버킷에 복제하고 장애 시 그 데이터로 서버 재구축
• BAWS Elastic Disaster Recovery(DRS) — 블록 레벨 CDP, 평소 작은 Staging, 페일오버 시 실제 크기 launch
• CStorage Gateway로 온프레미스 볼륨을 AWS에 백업하고 장애 시 EC2로 복원
• DDataSync로 온프레미스 파일을 주기적으로 AWS로 전송해 두고 장애 시 복구에 사용

문제 11

규제상 S3 객체에 5년간 변경·삭제를 절대 불가능하게 강제해야 한다. 어떤 기능과 전제인가?

• A버킷 정책·IAM 정책으로 모든 주체에 DeleteObject·PutObject를 명시적으로 거부
• BS3 Object Lock Compliance 모드 + 5년 retention, Versioning 필수
• CCross-Region Replication으로 다른 리전에 사본을 두어 한쪽이 변경돼도 원본 보존
• DGlacier Deep Archive로 이동해 즉시 접근·수정이 어려운 콜드 계층에 5년간 보관

문제 12

DR 페일오버 시 큰 EBS 스냅샷에서 만든 새 볼륨의 첫 IO가 느려 복구가 지연된다. 비용을 고려한 해결은?

• A스냅샷을 다시 만들어 모든 블록이 완전히 채워진 새 스냅샷에서 볼륨을 생성
• B페일오버 대상 AZ에만 Fast Snapshot Restore(FSR)를 켜 미리 hydrate
• C볼륨 타입을 gp2에서 gp3로 변경해 baseline IOPS·처리량을 높임
• D복구 인스턴스 타입을 키워 더 높은 EBS 대역폭으로 초기 IO를 흡수

🔮 다음 주 예고 (Week 11)

Week 11은 성능·비용 최적화 — 운영자의 일상 업무다. Compute Optimizer로 right-sizing, Trusted Advisor의 5개 체크 카테고리, Cost Explorer·Budgets·Cost Allocation Tag로 비용 가시화, Savings Plans·Reserved Instances·Spot으로 비용 절감을 다룬다. Week 10이 "잃지 않고 빨리 복구하는" 안정성의 주였다면, Week 11은 "같은 안정성을 더 싸게" 만드는 효율의 주다.