EBS 스냅샷과 AWS Backup 차이 클라우드 백업 3-2-1 규칙 적용 방법

EBS 스냅샷과 AWS Backup 차이를 이해하는 것은 클라우드에서 데이터를 잃지 않기 위한 기본 준비입니다. 클라우드는 사업자가 하드웨어를 이중화해두니 백업이 필요 없다고 생각하기 쉽지만, 사용자의 실수로 삭제한 데이터나 랜섬웨어로 암호화된 파일, 잘못된 배포로 망가진 데이터베이스는 사업자가 대신 되돌려주지 않습니다. 이런 상황에서 서비스를 되살릴 수 있는 유일한 방법이 제대로 설계된 백업입니다.

 

EBS 스냅샷과 AWS Backup 차이 클라우드 백업 3-2-1 규칙 적용 방법

서버 디스크를 가끔 수동으로 스냅샷 찍어두는 것만으로 백업을 끝냈다고 생각하기 쉽습니다. 하지만 스냅샷이 언제 찍혔는지 관리되지 않고, 서버와 같은 계정·같은 리전에만 있다면 계정 자체에 문제가 생겼을 때 백업도 함께 사라질 수 있습니다. 그래서 백업은 찍는 것보다 어디에, 얼마나 떨어뜨려, 어떻게 복구하느냐가 더 중요합니다.

 

이 글에서는 EBS 스냅샷의 동작 원리, AWS Backup의 중앙 관리 기능, 두 방식의 장단점을 비교하고, 3-2-1 백업 규칙을 클라우드에 적용하는 방법과 복구 테스트가 왜 중요한지까지 다룹니다.

 

간단히 요약하면 EBS 스냅샷은 EC2에 연결된 디스크 볼륨의 특정 시점 사본을 만드는 기능이고, AWS Backup은 EBS를 포함한 여러 AWS 서비스의 백업을 정책 기반으로 한곳에서 자동화하고 관리하는 서비스입니다. 운영 환경이라면 AWS Backup으로 백업 계획을 세우고, 다른 리전이나 다른 계정으로 사본을 복제해 3-2-1 규칙에 가깝게 구성하는 것이 좋습니다.

 

EBS 스냅샷은 디스크 볼륨의 특정 시점 사본입니다

EBS(Elastic Block Store)는 EC2 인스턴스에 연결해 사용하는 블록 스토리지, 즉 가상 디스크입니다. EBS 스냅샷은 이 볼륨의 데이터를 특정 시점 기준으로 복사해 저장하는 기능입니다. 스냅샷에서 새 볼륨을 만들면 스냅샷을 찍은 시점의 상태로 디스크를 되살릴 수 있습니다.

 

EBS 스냅샷은 증분 방식으로 저장됩니다. 첫 번째 스냅샷은 사용 중인 데이터 블록 전체를 저장하지만, 이후 스냅샷은 이전 스냅샷 이후 변경된 블록만 저장합니다. 그래서 스냅샷을 자주 찍어도 저장 공간이 매번 전체 용량만큼 늘어나지 않습니다. 중간 스냅샷을 삭제하더라도 이후 스냅샷에서 복원하는 데 필요한 데이터는 유지되도록 관리됩니다.

 

스냅샷은 AWS가 관리하는 저장소에 리전 단위로 보관되며, 다른 리전으로 복사하거나 다른 AWS 계정과 공유할 수 있습니다. 오랫동안 보관만 하는 스냅샷은 EBS 스냅샷 아카이브 계층으로 옮겨 저장 비용을 줄일 수 있지만, 복원에 시간이 걸리고 최소 보관 기간이 있다는 점을 고려해야 합니다.

 

주의할 점은 스냅샷이 기본적으로 충돌 일관성(crash-consistent) 상태라는 것입니다. 전원이 갑자기 꺼졌을 때와 비슷한 상태로 저장되기 때문에, 데이터베이스처럼 메모리에 쓰기 중인 데이터가 많은 애플리케이션은 복원 후 복구 과정이 필요할 수 있습니다. 애플리케이션 일관성이 중요하다면 쓰기를 잠시 멈추거나 운영체제 기능과 연동된 백업 방식을 사용해야 합니다.

 

EBS 스냅샷은 변경된 블록만 저장하는 증분 방식이라 효율적이지만, 기본적으로 충돌 일관성 상태이므로 데이터베이스 서버는 애플리케이션 일관성까지 고려한 백업 방식이 필요합니다.

 

스냅샷을 자동으로 관리하는 Data Lifecycle Manager

스냅샷을 수동으로 찍으면 잊어버리기 쉽고, 오래된 스냅샷을 정리하지 않으면 저장 비용이 계속 쌓입니다. 이를 해결하기 위해 Amazon Data Lifecycle Manager를 사용할 수 있습니다. 태그를 기준으로 대상 볼륨이나 인스턴스를 지정하고, 매일 몇 시에 스냅샷을 만들고 몇 개까지 보관할지 정책을 정하면 자동으로 생성과 삭제가 이루어집니다.

 

Data Lifecycle Manager는 EBS 스냅샷과 EBS 기반 AMI 관리에 특화된 도구입니다. EC2 중심의 환경에서 간단하게 자동 스냅샷을 구성하기에 좋습니다. 다만 데이터베이스나 파일 시스템 같은 다른 서비스의 백업은 각각 따로 설정해야 한다는 한계가 있습니다.

 

실수로 스냅샷을 삭제하는 상황에 대비하려면 EBS 휴지통(Recycle Bin) 기능도 함께 설정해두면 좋습니다. 보존 규칙을 만들어두면 삭제된 스냅샷이 정해진 기간 동안 휴지통에 남아 있어 복원할 수 있습니다.

 

AWS Backup은 여러 서비스의 백업을 한곳에서 관리합니다

AWS Backup은 EBS, EC2, RDS, Aurora, DynamoDB, EFS, S3 등 여러 AWS 서비스의 백업을 중앙에서 관리하는 서비스입니다. 서비스마다 다른 콘솔에 들어가 따로 설정할 필요 없이 하나의 백업 계획으로 일정, 보관 기간, 복사 대상을 정할 수 있습니다.

 

백업 계획은 규칙과 리소스 할당으로 구성됩니다. 규칙에서는 매일 새벽 백업, 35일 보관, 매월 1회 백업은 1년 보관처럼 주기와 보관 기간을 정하고, 리소스 할당에서는 태그나 리소스 유형으로 백업 대상을 지정합니다. 새로 만든 서버에 정해진 태그만 붙이면 자동으로 백업 대상에 포함되어 누락을 줄일 수 있습니다.

 

백업 데이터는 백업 볼트(Backup Vault)라는 저장 공간에 보관됩니다. 볼트마다 접근 정책과 암호화 키를 따로 지정할 수 있고, AWS Backup Vault Lock을 설정하면 정해진 보관 기간 동안 관리자 권한을 가진 사용자도 백업을 삭제하거나 변경할 수 없게 만들 수 있습니다. 랜섬웨어나 내부자의 악의적인 삭제에 대비하는 중요한 기능입니다.

 

또한 AWS Backup은 백업 사본을 다른 리전이나 AWS Organizations 안의 다른 계정으로 자동 복사하는 기능을 제공합니다. 원본 계정이 탈취되더라도 별도 계정에 보관된 백업은 영향을 받지 않도록 분리할 수 있습니다.

 

AWS Backup은 여러 서비스의 백업을 하나의 정책으로 자동화하고, Vault Lock과 교차 계정 복사로 백업 자체를 삭제 위험으로부터 보호할 수 있다는 점이 가장 큰 장점입니다.

 

EBS 스냅샷과 AWS Backup 비교

두 방식의 차이를 정리하면 다음과 같습니다.

 

비교 항목	EBS 스냅샷 (수동·DLM)	AWS Backup
대상 서비스	EBS 볼륨, EBS 기반 AMI	EBS, EC2, RDS, DynamoDB, EFS, S3 등 다수
관리 방식	서비스별 개별 설정	백업 계획으로 중앙 관리
자동화	Data Lifecycle Manager 정책	백업 계획 규칙 + 태그 기반 할당
삭제 방지	휴지통 보존 규칙	Vault Lock으로 변경 불가 보관
리전·계정 간 복사	스냅샷 복사·공유 기능	백업 계획에서 자동 복사 설정
적합한 환경	EC2 위주의 단순한 구성	여러 서비스와 계정을 쓰는 운영 환경

 

AWS Backup으로 EBS를 백업해도 내부적으로는 EBS 스냅샷이 생성됩니다. 즉 두 방식은 경쟁 관계가 아니라, AWS Backup이 스냅샷을 포함한 여러 백업 기능을 정책 기반으로 묶어 관리해주는 상위 도구라고 이해하면 됩니다.

 

클라우드 백업에 3-2-1 규칙을 적용하는 방법

3-2-1 규칙은 데이터 백업에서 오랫동안 사용되어 온 기본 원칙입니다. 데이터 사본을 원본 포함 3개 이상 유지하고, 2가지 이상의 서로 다른 저장 매체나 방식에 보관하며, 그 가운데 1개는 원본과 물리적으로 떨어진 곳에 두라는 의미입니다.

 

클라우드에 적용하면 다음과 같이 구성할 수 있습니다. 원본 데이터는 운영 리전의 EBS나 RDS에 있고, 첫 번째 백업은 같은 리전의 백업 볼트에 자동 저장합니다. 두 번째 백업은 다른 리전의 백업 볼트로 복사해 리전 단위 장애에 대비합니다.

 

여기서 한 단계 더 나아가면 백업 사본을 별도의 AWS 계정으로도 복사합니다. 계정 권한이 탈취되는 상황은 리전 장애보다 훨씬 현실적인 위험이기 때문에, 운영 계정과 권한이 분리된 백업 전용 계정을 두는 것이 효과적입니다. 최근에는 여기에 변경 불가능한 사본 1개와 복구 검증 오류 0개를 더한 3-2-1-1-0 규칙도 자주 언급됩니다.

 

클라우드에서의 3-2-1 규칙은 같은 리전 백업, 다른 리전 사본, 다른 계정 사본으로 구성하고, Vault Lock으로 최소 한 개 사본은 변경할 수 없게 보호하는 방식으로 실천할 수 있습니다.

 

백업보다 더 중요한 복구 테스트

백업이 있다는 사실과 복구할 수 있다는 사실은 다릅니다. 실제 사고가 났을 때 백업 파일이 손상되어 있거나, 복원 절차를 아는 사람이 없거나, 복원에 예상보다 훨씬 오랜 시간이 걸리는 경우가 적지 않습니다. 그래서 정기적인 복구 테스트가 반드시 필요합니다.

 

복구 테스트는 스냅샷이나 백업에서 새 볼륨이나 데이터베이스를 만들어 실제로 애플리케이션이 정상 동작하는지 확인하는 방식으로 진행합니다. 이 과정에서 복원에 걸린 시간을 기록해두면 서비스의 복구 목표 시간을 현실적으로 설정하는 근거가 됩니다. AWS Backup의 복원 테스트 기능을 사용하면 정해진 주기로 복원을 자동 실행하고 결과를 확인할 수 있습니다.

 

복구 절차는 문서로 남겨두는 것이 좋습니다. 어떤 백업을 선택해야 하는지, 복원 후 어떤 설정을 다시 연결해야 하는지, 누구에게 보고해야 하는지를 정리해두면 긴급 상황에서도 담당자가 흔들리지 않고 대응할 수 있습니다.

 

복구해본 적 없는 백업은 믿을 수 없는 백업이므로, 최소 분기에 한 번은 실제로 복원해보고 걸린 시간과 문제점을 기록해두어야 합니다.

 

EBS 스냅샷과 AWS Backup 핵심 정리

EBS 스냅샷은 EC2 디스크 볼륨의 증분 시점 사본이고, AWS Backup은 EBS를 포함한 여러 서비스의 백업을 정책으로 자동화하고 중앙에서 관리하는 서비스입니다. 단순한 EC2 환경은 Data Lifecycle Manager로도 충분하지만, 운영 환경에서는 AWS Backup의 Vault Lock과 교차 리전·교차 계정 복사를 활용하는 것이 안전합니다. 3-2-1 규칙에 따라 사본을 분산하고 정기적으로 복구 테스트를 해야 백업이 제 역할을 할 수 있습니다.

 

질문 QnA

EC2 인스턴스를 종료하면 스냅샷도 함께 삭제되나요?

아니요, EBS 스냅샷은 인스턴스나 볼륨과 별도로 보관되므로 인스턴스를 종료해도 남아 있습니다. 반대로 필요 없는 스냅샷은 직접 삭제하지 않으면 저장 요금이 계속 발생합니다.

RDS의 자동 백업이 있는데 AWS Backup을 따로 써야 하나요?

RDS 자동 백업은 보관 기간에 제한이 있고 인스턴스를 삭제할 때 함께 정리될 수 있습니다. 장기 보관이나 다른 계정·리전 복사가 필요하다면 AWS Backup이나 수동 스냅샷을 함께 사용하는 것이 좋습니다.

백업 비용은 어떻게 계산되나요?

백업 데이터가 차지하는 저장 용량, 보관 계층, 다른 리전으로 복사할 때의 데이터 전송량, 복원 작업 등에 따라 요금이 발생합니다. 정확한 금액은 서비스별 요금 페이지에서 확인해야 합니다.

스냅샷을 찍는 동안 서버를 멈춰야 하나요?

서버를 멈추지 않고도 스냅샷을 만들 수 있습니다. 다만 데이터 일관성이 중요한 경우에는 쓰기를 잠시 멈추거나 애플리케이션 일관성 백업 옵션을 사용하는 것이 안전합니다.

 

백업은 평소에는 비용처럼 느껴지지만 사고가 나는 순간 서비스를 살리는 유일한 수단이 됩니다. 얼마나 자주 찍느냐보다 얼마나 떨어뜨려 보관하고, 실제로 복구할 수 있는지 확인했느냐가 백업의 가치를 결정합니다.

 

지금 운영 중인 서버와 데이터베이스 목록을 적어보고, 각각 마지막 백업이 언제였는지, 다른 리전이나 다른 계정에 사본이 있는지 확인해보세요. 그리고 가장 중요한 데이터 하나를 골라 이번 주에 실제로 복원 테스트를 해보시길 권해드립니다.

 

함께 읽으면 좋은 글: S3 스토리지 클래스 차이 / AWS 리전과 가용 영역 차이

참고 자료: Amazon EBS 스냅샷 안내, AWS Backup 안내

 

※ 본 글은 2026년 9월 기준 Amazon EBS 스냅샷, Amazon Data Lifecycle Manager, AWS Backup 공식 문서를 참고해 작성했으며, 지원 서비스와 기능, 요금은 변경될 수 있으니 최신 내용은 AWS 공식 페이지에서 확인해 주세요.