Skip to content

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)

  1. No-Reboot 옵션의 데이터 정합성: 운영 중인 EC2에서 AMI를 생성할 때 NoReboot=true를 주면 서비스 다운타임은 없지만 메모리 캐시 플러시가 안 될 수 있으므로, DB 인스턴스는 유지보수 시간에 생성하거나 사전 sync 처리를 권장한다.
  2. KMS 암호화 키 권한: 스냅샷/AMI가 커스텀 KMS 키로 암호화되어 있다면, 타 계정 복구나 인스턴스 기동 시 해당 KMS 키 사용 권한이 부여되어 있는지 확인해야 한다.

게시된 시간: 2026-08-05 13:00:36수정한 시간: 2026-08-15 13:57:00

Built with VitePress. | 📡 RSS Feed