AWS Certified CloudOps Engineer - Associate (SOA-C03) #6 Domain 2-2 신뢰성: 백업,복원과 재해 복구(DR)
#5에서 “서비스가 계속 도는” 가용성을 잡았다면, 이 글은 “데이터를 잃지 않고 되살리는” 백업과 재해 복구를 다룹니다. 신뢰성 도메인에서 가용성과 데이터 보호는 한 쌍입니다. 운영에서 가장 무거운 사고는 인스턴스가 꺼지는 것보다 데이터가 사라지는 것이라, 시험도 백업 전략과 복구 목표를 비중 있게 묻습니다.
백업의 기본 단위 #
| 자원 | 백업 수단 | 특징 |
|---|---|---|
| EBS 볼륨 | 스냅샷(Snapshot) | 증분 저장, S3에 보관, 리전 내 |
| EC2 인스턴스 | AMI | 볼륨 스냅샷 + 메타데이터. 인스턴스 재생성 |
| RDS | 자동 백업,수동 스냅샷 | 특정 시점 복구(PITR) 지원 |
| EFS,DynamoDB,기타 | 서비스별 백업 또는 AWS Backup | 중앙 관리 가능 |
EBS 스냅샷의 성질 #
EBS 스냅샷은 증분(incremental)입니다. 첫 스냅샷만 전체이고, 이후는 바뀐 블록만 저장합니다. 그래서 자주 찍어도 비용이 선형으로 늘지 않습니다. 스냅샷은 S3에 저장되며(사용자에게 직접 보이지는 않음), 다른 리전,계정으로 복사해 지리적 분산이나 격리를 구성할 수 있습니다.
RDS 백업: 자동 백업 vs 스냅샷 #
| 구분 | 자동 백업 | 수동 스냅샷 |
|---|---|---|
| 보존 | 최대 35일, 보존 기간 지나면 삭제 | 직접 지울 때까지 영구 |
| 특정 시점 복구(PITR) | 가능 | 불가(찍은 시점만) |
| 인스턴스 삭제 시 | 함께 삭제 | 남음 |
운영의 단골은 “인스턴스를 지워도 백업을 남기고 싶다“입니다. 자동 백업은 인스턴스와 함께 사라지므로, 영구 보존이 필요하면 수동 스냅샷을 따로 떠 두어야 합니다.
AWS Backup: 백업의 중앙 관리 #
서비스마다 백업을 따로 설정하면 누락과 불일치가 생깁니다. AWS Backup은 여러 서비스의 백업을 하나의 정책으로 중앙 관리합니다.
| 구성 | 역할 |
|---|---|
| Backup Plan | 백업 빈도,보존,시간 창을 정의한 정책 |
| Backup Vault | 백업이 저장되는 곳. 접근 정책,암호화 |
| Resource Assignment | 태그나 ID로 백업 대상 지정 |
핵심 효용은 다음입니다.
- 태그 기반 일괄 적용: 특정 태그가 붙은 모든 자원을 한 정책으로 백업
- 교차 리전,교차 계정 복사: 정책에 백업의 타 리전 복제를 포함
- Backup Vault Lock: 백업을 수정,삭제 불가(WORM)로 잠가 랜섬웨어,실수 삭제에 대비. 컴플라이언스 요구에 대응
- 중앙 보고: 어떤 자원이 정책을 벗어났는지 한눈에
“수십 개 계정,여러 서비스의 백업을 표준 정책으로 강제하고 규정 준수를 증명하라"는 요구의 답이 AWS Backup(+ Organizations 연동 + Vault Lock)입니다.
RPO와 RTO: 복구 목표 #
DR 전략을 고르는 기준은 두 지표입니다.
| 지표 | 정의 | 한 줄로 |
|---|---|---|
| RPO (Recovery Point Objective) | 허용 가능한 데이터 손실 시간 | “얼마나 과거로 돌아가도 되는가” |
| RTO (Recovery Time Objective) | 허용 가능한 복구 소요 시간 | “얼마나 빨리 되살려야 하는가” |
RPO가 짧을수록 백업을 자주(또는 실시간 복제) 떠야 하고, RTO가 짧을수록 대기 환경을 미리 띄워 둬야 합니다. 둘 다 짧게 하면 비용이 커지므로, 요구에 맞는 최소 비용 전략을 고르는 것이 시험의 틀입니다.
DR 전략 네 가지 #
RPO,RTO와 비용의 트레이드오프에 따라 네 전략으로 나뉩니다. SAA에서 본 틀을 운영 관점에서 다시 정리하겠습니다.
| 전략 | 평시 비용 | RTO | 구성 |
|---|---|---|---|
| Backup & Restore | 가장 낮음 | 가장 김(시간) | 백업만 타 리전에. 장애 시 처음부터 복원 |
| Pilot Light | 낮음 | 김 | 핵심(DB 복제)만 켜두고 나머지는 꺼둠. 장애 시 기동 |
| Warm Standby | 중간 | 짧음(분) | 축소판 전체 환경을 항상 켜둠. 장애 시 확장 |
| Multi-Site (Hot) | 가장 높음 | 가장 짧음(거의 0) | 양쪽을 풀 용량으로 동시 운영 |
선택의 기준은 단순합니다.
- 비용 최소가 우선이고 복구가 느려도 되면 → Backup & Restore
- 빠른 복구가 우선이고 비용을 감수하면 → Warm Standby 또는 Multi-Site
- 그 사이의 타협이 Pilot Light
“RTO 수 분, 비용은 최소화"처럼 두 조건이 함께 오면, 그 둘을 동시에 만족하는 지점(보통 Pilot Light나 Warm Standby)을 고르는 것이 정답입니다.
시험 출제 패턴 #
- 인스턴스를 지워도 백업 유지 → 수동 스냅샷(자동 백업은 함께 삭제)
- 여러 서비스 백업을 표준 정책으로 강제 → AWS Backup + 태그 기반 정책
- 백업을 삭제,변조 불가로 → Backup Vault Lock(WORM)
- 리전 장애 대비 백업 보관 → 스냅샷,백업을 타 리전 복사
- 비용 최소,복구 느려도 됨 → Backup & Restore
- RTO 수 분 필요 → Warm Standby
- RPO,RTO 거의 0 → Multi-Site
자주 만나는 함정 #
1) 자동 백업이 영구 보존된다고 생각 #
자동 백업은 보존 기간(최대 35일)이 지나거나 인스턴스를 지우면 사라집니다. 영구 보존은 수동 스냅샷입니다.
2) 스냅샷이 전체 복사라고 오해 #
EBS 스냅샷은 증분입니다. 자주 찍어도 변경 블록만 추가됩니다.
3) DR 전략을 비용만으로 고름 #
가장 싼 Backup & Restore가 항상 답은 아닙니다. RTO,RPO 요구를 먼저 읽고 그에 맞는 최소 비용 전략을 골라야 합니다.
4) 멀티리전을 기본값으로 가정 #
대부분의 가용성 요구는 Multi-AZ로 충분합니다. 멀티리전 DR은 리전 장애,규제 같은 명시적 요구가 있을 때입니다.
정리 #
이번 글에서 잡은 것:
- 백업 단위는 EBS 스냅샷(증분),AMI,RDS 백업. 스냅샷은 타 리전,계정 복사 가능
- RDS 자동 백업은 인스턴스와 함께 삭제, 영구 보존은 수동 스냅샷
- AWS Backup으로 여러 서비스를 태그 기반 정책으로 중앙 관리. Vault Lock으로 WORM
- RPO(데이터 손실 허용)와 RTO(복구 시간 허용)가 DR 전략 선택 기준
- DR 네 전략: Backup & Restore , Pilot Light , Warm Standby , Multi-Site. 비용과 RTO의 트레이드오프
- 요구를 먼저 읽고 그에 맞는 최소 비용 전략을 고르는 것이 핵심
다음: Domain 3-1 CloudFormation과 IaC #
데이터 보호까지 신뢰성 도메인을 마쳤습니다. 다음은 세 번째 도메인인 배포,프로비저닝,자동화입니다.
#7 Domain 3-1 배포: CloudFormation 깊이와 IaC에서는 CloudFormation의 스택과 템플릿 구조, 변경 집합(Change Set)과 드리프트 탐지, 여러 계정,리전에 배포하는 StackSets, 그리고 CDK,Terraform 같은 다른 IaC 도구와의 관계까지 운영 관점에서 정리하겠습니다.