EBS 스냅샷과 AMI: AWS 백업 전략 수립을 위한 기술적 비교 분석
1줄 요약
스토리지 비용(S3 스냅샷 요율)은 동일하지만, 장애 발생 시 **복구 시간 목표(RTO)**를 단축하고 완전한 인스턴스 복원을 원한다면 AMI를, 순수 데이터 볼륨 복제 및 특정 파일 추출이 목적이라면 EBS 스냅샷을 DLM 정책으로 설정하는 것이 정석이다.
1. 백업 아키텍처 비교: Snapshot vs AMI
EBS 스냅샷과 AMI는 백업 대상과 복구 범위에서 근본적인 차이가 있다.
- EBS 스냅샷 (Volume-Level): 블록 스토리지 볼륨 자체의 변경 블록 복사본. 인스턴스 타입, 네트워크(ENI/VPC), 보안 그룹 등 메타데이터는 포함되지 않는다.
- AMI (Instance-Level Image): 하나 이상의 EBS 스냅샷에 **인스턴스 메타데이터(블록 디바이스 매핑, 커널, 아키텍처)**를 패키징한 상위 템플릿.
[AMI 구조도]
┌───────────────────────────────────────────────┐
│ Amazon Machine Image (AMI) │
│ ├─ Root 볼륨 스냅샷 (OS/바이너리) │
│ ├─ Additional Data 볼륨 스냅샷 │
│ └─ 블록 디바이스 매핑 / 인스턴스 구성 메타데이터 │
└───────────────────────────────────────────────┘2. 복구 절차(RTO) 및 사용 시나리오
| 구분 | EBS 스냅샷 (EBS Snapshot) | AMI (Amazon Machine Image) |
|---|---|---|
| 복구 절차 | 1. 스냅샷으로 새 볼륨 생성 2. EC2 인스턴스 생성/지정 3. 볼륨 Attach & OS 마운트 | 1. AMI 선택 후 즉시 RunInstances 실행 |
| 복구 시간(RTO) | 수동 개입 필요 (상대적으로 지연) | 수 분 내 원클릭 자동 복구 |
| 주요 사용처 | 데이터 볼륨 마이그레이션, 특정 디렉토리 파일 복구 | 인스턴스 전체 재해 복구(DR), Auto Scaling 템플릿 |
3. 비용 및 Data Lifecycle Manager(DLM) 자동화
스토리지 과금 구조
AMI는 내부적으로 동일한 EBS 스냅샷 기술(증분 백업 및 S3 저장)을 사용하므로, 스냅샷과 AMI 간 스토리지 비용 차이는 0원이다. 변경된 블록 용량만큼만 S3 요율로 과금된다.
AWS DLM 기반 자동화 표준 정책
AWS Data Lifecycle Manager(무료 서비스)를 활용하여 다음과 같이 이원화된 보존 주기를 구성한다.
yaml
# AWS DLM 정책 구성 표준
1. 인스턴스 DR 정책 (AMI 기반):
- 대상: EC2 태그 `Environment=Production`
- 주기: 매일 03:00 KST
- 보존: 최근 7일치 유지 후 자동 소거
2. 대용량 데이터 볼륨 정책 (Snapshot 기반):
- 대상: EBS 태그 `Role=Database-Data`
- 주기: 매 12시간
- 보존: 14개 스냅샷 유지4. 핵심 체크포인트 (Gotchas)
- No-Reboot 옵션의 데이터 정합성: 운영 중인 EC2에서 AMI를 생성할 때
NoReboot=true를 주면 서비스 다운타임은 없지만 메모리 캐시 플러시가 안 될 수 있으므로, DB 인스턴스는 유지보수 시간에 생성하거나 사전sync처리를 권장한다. - KMS 암호화 키 권한: 스냅샷/AMI가 커스텀 KMS 키로 암호화되어 있다면, 타 계정 복구나 인스턴스 기동 시 해당 KMS 키 사용 권한이 부여되어 있는지 확인해야 한다.
게시된 시간: 2026-08-05 13:00:36수정한 시간: 2026-08-15 13:57:00