AWS로 서비스를 운영하다 보면 EBS 스냅샷 관리가 생각보다 골치 아픈 문제라는 걸 느끼게 됩니다. 처음엔 백업 목적으로 하나씩 찍어두는데, 어느새 수십 개가 쌓이고 월말 청구서를 보면 예산 낭비가 된 것을 한번에 알게 됩니다. 저도 처음 인프라를 맡았을 때 이 부분을 간과했다가 예상치 못한 비용이 발생해서 당황했던 경험이 있습니다. 실무에서는 어떤 방법이 EBS 스냅샷 비용 절감과 관리에 도움이 되는지 한번 적어보도록 하겠습니다.
EBS 스냅샷, 왜 비용이 계속 쌓일까?
EBS 스냅샷은 AWS에서 제공하는 블록 스토리지의 백업 기능으로, 데이터 보호 및 복구를 위한 중요한 수단입니다. 하지만 사용자가 별도로 삭제하지 않으면 스냅샷은 무기한 저장되며, 이에 따라 월별 스토리지 비용이 지속적으로 발생합니다. 특히 일일 또는 주간 단위로 스냅샷을 생성하는 시스템에서는 짧은 시간 안에 수십, 수백 개의 스냅샷이 쌓이며 비용이 급증할 수 있습니다. 비용을 확인하려면 AWS 콘솔의 'Billing > Cost Explorer' 또는 'EBS > Snapshots' 메뉴에서 스냅샷 별 용량과 비용을 파악할 수 있습니다. 일반적으로 EBS 볼륨이 크고, 변경사항이 많을수록 스냅샷 용량도 증가하기 때문에, 자동화된 백업 정책을 쓰더라도 보관 주기와 삭제 정책이 명확히 설정되어야 합니다. 또한, 백업을 위해 만든 스냅샷이지만, 프로젝트 종료 후 불필요하게 방치되는 경우도 흔합니다. 이러한 스냅샷은 단기적으로는 눈에 띄지 않지만 장기적으로 수십만 원, 수백만 원의 비용을 발생시킬 수 있으므로 정기적인 검토와 정리가 필수입니다. 참고로 첫 스냅샷은 전체 용량이 저장되지만, 이후 스냅샷은 증분(변경분)만 저장됩니다. 그래서 '스냅샷 10개 = 볼륨 크기 × 10'은 아니에요. 하지만 그렇다고 안심하면 안 됩니다. 삭제된 스냅샷과 연결된 데이터는 다른 스냅샷으로 이동되면서 결국 용량은 계속 누적되거든요.
Lambda와 스케줄을 활용한 스냅샷 정리 자동화
효율적인 스냅샷 관리를 위해 인프라 담당자들이 가장 많이 사용하는 방법은 AWS Lambda와 CloudWatch Event를 활용한 자동화입니다. Lambda는 서버리스 환경에서 특정 조건에 맞춰 코드를 실행할 수 있는 서비스로, 스냅샷의 생성 및 삭제를 자동화하는 데 매우 적합합니다. 예를 들어, 특정 태그가 붙은 인스턴스의 EBS 볼륨만을 대상으로 일일 스냅샷을 생성하고, 7일 이상 된 스냅샷은 자동 삭제하는 스크립트를 작성할 수 있습니다. 이때 Boto3 (AWS SDK for Python)를 이용하면 AWS 자원에 쉽게 접근할 수 있으며, IAM 역할을 통해 필요한 권한만 부여하면 보안상으로도 안전합니다. CloudWatch Event 또는 EventBridge를 통해 Lambda 함수 실행을 매일 새벽 3시 등으로 스케줄링하면, 전혀 수동 작업 없이도 정기적인 백업과 정리가 가능해집니다. 스냅샷 생성과 삭제 시 로그를 CloudWatch Logs에 저장하면 관리 이력도 추적할 수 있어 운영 효율성이 높아집니다.
실무에서 바로 적용 가능한 스냅샷 관리 팁
실제 기업 환경에서는 '완전 자동화'보다는 '반자동 + 주기적 점검' 방식이 안정적으로 운영됩니다. 백업 실패나 리전별 제약, IAM 권한 누락 같은 예외 상황이 생각보다 자주 발생하기 때문이죠. 저도 처음엔 Lambda로 다 자동화해놓고 안심했다가, 몇 달 뒤 확인해보니 특정 볼륨은 백업이 안 되고 있더라고요. 그래서 개선한 관리 방법을 알려드리도록 하겠습니다.
먼저 서비스 중요도에 따라 스냅샷 생성 주기를 다르게 가져갑니다. 핵심 DB 서버는 매일, 개발 환경은 주 1회 정도로요. 이때 태그를 잘 활용하는 게 중요한데, 'Backup:True' 같은 태그를 달아두면 Lambda 스크립트에서 이 태그가 있는 인스턴스만 골라서 백업할 수 있어서 편합니다. 보관 주기도 업무 특성에 맞게 설정하는 게 좋습니다. 보통 운영 서버는 7일, 중요 데이터는 30일 정도로 잡고, 그 이상 된 스냅샷은 Lambda가 자동으로 삭제하도록 해두면 됩니다. 다만 완전히 손을 떼면 안 되고, 월 1회 정도는 비용 리포트를 보면서 스냅샷 수량과 용량을 직접 확인하는 습관을 들이는 게 중요합니다. 가끔 예상치 못한 스냅샷이 쌓여 있거나, 이미 삭제한 인스턴스의 스냅샷이 남아있는 경우가 있거든요. 또 AWS Budgets 기능으로 비용 알림을 설정해두면 좋습니다. 스냅샷 비용이 일정 금액을 넘어가면 메일이나 슬랙으로 알림이 오도록 해두면, 문제가 커지기 전에 미리 대응할 수 있습니다. 실제로 저는 이걸로 Lambda 스크립트 오류를 조기에 발견한 적이 있어요. 만약 팀 단위로 운영한다면, 스냅샷 관리 현황을 공유하는 간단한 문서나 대시보드를 만들어두는 것도 추천합니다. 담당자가 바뀌거나 휴가를 가도 관리를 수월하게 할 수 있습니다. 이런 방식들은 개인의 업무 부담도 줄여주고, 예산 낭비 없이 안정적인 백업 체계를 유지하는 데 효과적일 것 입니다.
사실 EBS 스냅샷 관리는 '한 번 설정하면 끝'이 아닙니다. 서비스가 커지고 인스턴스가 늘어날수록 관리 포인트도 함께 늘어나거든요. 하지만 처음부터 너무 완벽하게 하려고 하면 오히려 더 어려울 수 있어요. 일단 보관 주기 7일로 시작해서, 업무 특성에 맞게 조금씩 조정해 나가는 게 현실적인 방법이 될 것 입니다.