EBS 스냅샷과 EBS 기반 AMI의 생성·보존·삭제를 자동화하려면 Amazon Data Lifecycle Manager(DLM)를, 여러 AWS 서비스와 계정의 백업 정책을 함께 관리하려면 AWS Backup을 먼저 비교하세요. 스냅샷이 만들어졌다는 사실과 서비스가 복구된다는 사실은 다릅니다. 선택의 마지막 기준은 실제로 필요한 복구 절차를 운영팀이 수행할 수 있는지입니다.
이 글은 EC2에 연결된 EBS 볼륨의 정책 선택을 다룹니다. 인스턴스 스토어 데이터나 데이터베이스 전용 백업을 EBS 스냅샷과 동일하게 취급하지 않습니다. 문서·과금 항목 확인 기준일은 2026-10-10입니다. 실제 단가나 복구 소요 시간을 측정하지 않았으며 아래는 문서에 기반한 설계·검수 예시입니다.
같은 스냅샷을 쓰더라도 관리 범위가 다릅니다
| 비교 질문 | EBS DLM | AWS Backup |
| 주요 범위 | EBS 스냅샷·EBS 기반 AMI 수명 주기 | 지원되는 여러 AWS 리소스의 백업 정책 |
| 기존 생성물 관리 | 다른 방법으로 만든 스냅샷·AMI는 DLM 관리 대상이 아님 | 기존 생성물의 지원·관리 관계를 리소스별 확인 |
| 운영 초점 | 대상 태그·일정·보존·정책 상태 | 계획·리소스 할당·보관함·복원 작업 |
| 완료 판단 | 예정 스냅샷 생성과 보존 동작 확인 | 복구 지점과 복원 작업·실제 서비스 확인 |
AWS 문서는 DLM이 다른 방법으로 만든 스냅샷이나 AMI를 관리할 수 없다고 명시합니다. 기존 수동 스냅샷에 태그만 바꾸면 자동으로 같은 수명 주기에 들어간다고 가정하지 마세요. DLM 공식 범위와 제한을 확인해 생성 주체와 정리 책임을 나눠야 합니다.
원인: 백업 생성만 확인하고 보존·복원 경로를 빠뜨립니다
정책을 추가할 때 흔한 운영 문제는 같은 볼륨에 여러 일정이 겹치는 것, 리소스 태그 누락으로 대상이 빠지는 것, 복원 담당자가 KMS 또는 IAM 권한을 갖고 있지 않은 것입니다. 생성 실패와 복원 실패는 다른 단계입니다. 성공한 백업 작업만 확인하면 필요한 볼륨이 모두 포함됐는지와 복원 후 앱이 시작되는지는 알 수 없습니다.
AWS Backup의 EC2 다중 볼륨 백업은 crash-consistent 스냅샷을 설명합니다. 이를 데이터베이스가 원하는 애플리케이션 일관성과 자동으로 같다고 표현하면 안 됩니다. 여러 디스크에 데이터·로그를 나눴다면 데이터베이스 제품의 백업·정지·복구 요구를 함께 확인하세요. EBS용 AWS Backup 설명의 일관성 범위를 기준으로 추가 검증이 필요한 부분을 남깁니다.
해결 절차: 정책을 만들기 전에 대상과 관리 주체를 정합니다
- 리전·계정·인스턴스·볼륨 ID와 대상 태그를 목록으로 정리합니다. EC2 설정과 모든 필요한 데이터 볼륨의 복구 방법을 구분합니다.
- 기존 수동 스냅샷, DLM, AWS Backup 일정이 있는지 확인합니다. 새 정책을 추가하기 전에 중복 작업과 보존 책임을 대조합니다.
- 허용 가능한 데이터 손실과 복구 시간을 요구사항으로 적습니다. 이는 제품 보장 수치가 아니라 조직이 정할 목표입니다.
- EBS와 AMI의 수명 주기가 주목적이면 DLM, 다른 지원 리소스까지 통합 관리하려면 AWS Backup 후보를 평가합니다.
- 지원 리전·리소스 기능, IAM 역할, 암호화 키 접근, 보관·복사·삭제 조건을 공식 문서와 계정 설정에서 확인합니다. 잠금 설정은 삭제나 변경 제약을 이해한 뒤 적용합니다.
예를 들어 개발용 EC2의 일일 볼륨 백업과 생산 서비스의 계정 분리 보관은 다른 요구입니다. 두 환경을 한 태그 규칙으로 뭉치지 말고 복원 승인 담당자와 데이터 접근 범위를 적으세요. 이 예시는 운영 설계 예시이며 사용자의 실제 계정에 정책을 적용한 결과가 아닙니다.
확인 방법: 복구 지점에서 앱 확인까지 끊기지 않아야 합니다
AWS Backup에서 EBS를 복원할 때는 가용 영역, 볼륨 속성, 암호화와 복원 역할을 확인해야 합니다. 생성된 볼륨이 있다고 원래 인스턴스와 앱 설정까지 돌아온 것은 아닙니다. 원본을 덮어쓰지 않는 시험 환경에서 연결·파일시스템·필요 데이터·앱 동작을 검증하세요. EBS 복원 공식 절차를 실제 환경의 연결 절차와 함께 기록합니다.
| 검증 단계 | 남길 증거 |
| 대상 포함 | 필요한 볼륨 ID·정책·태그 대조 |
| 작업 성공 | 예정 시각·복구 지점·실패 원인 |
| 복원 가능 | 역할·KMS·가용 영역·볼륨 생성 |
| 앱 복구 | 시험 환경 파일/데이터·서비스 검증 |
| 시험 종료 | 복원 자원 보존/정리 결정·원본 영향 없음 |
주의사항: 관리 서비스가 같아도 비용 입력은 다릅니다
DLM의 관리 기능에 별도 추가 비용이 없다는 설명을 스냅샷 저장과 복사까지 무료라는 뜻으로 해석하지 마세요. 견적에는 저장량과 보존 기간, 리전 간 복사, 아카이브 복원, 시험 과정의 자원을 넣어야 합니다. AWS Backup 복원 테스트도 평가와 리소스별 복원 저장량 등 과금 항목이 있으며, 시험 후 자원을 유지하면 해당 자원 비용을 검토해야 합니다. 현재 공식 과금 항목에서 선택한 리전·기능을 확인하세요.
스냅샷 정리를 위해 운영 복구 지점을 일괄 삭제하지 마세요. 정책 변경 전 현재 설정과 필요한 복구 지점을 보존하고, 시험 복원은 별도 자원으로 수행합니다. 새 일정의 대상·성공 여부를 확인한 뒤 기존 정책을 정리할지 승인 절차에 따라 결정합니다. 아카이브 복원은 즉시 완료된다고 가정하지 않고 요구 시간과 비교해야 합니다.
FAQ
DLM을 쓰면 수동 스냅샷도 자동 정리되나요? 다른 방법으로 만든 스냅샷·AMI는 DLM이 관리할 수 없습니다. 생성 주체별 보존·정리 책임을 확인하세요.
EBS 복원 성공이면 EC2 전체가 복구된 것인가요? EBS 볼륨 복원과 인스턴스·앱 복구는 다릅니다. 네트워크·설정·추가 볼륨·데이터 일관성을 실제 시험 범위에 넣어야 합니다.
어느 쪽이 더 저렴한가요? 이 글에서는 실제 견적을 산출하지 않았습니다. 같은 대상·보존·복사·복원 시험 조건을 잡고 저장 및 관련 비용과 운영 책임을 비교하세요.
공식 출처와 관련 글
공식 자료 확인 기준일: 2026-10-10. 문서 확인 내용과 설계 예시이며 실제 계정·명령 실행 결과가 아닙니다.
함께 읽기: EFS와 EBS 저장소 선택 기준
