[AWS RDS][비용] final snapshot과 retained automated backup을 삭제 순서 기준으로 나누는 법

IT 리서치 노트

[AWS RDS][비용] final snapshot과 retained automated backup을 삭제 순서 기준으로 나누는 법

RDS 인스턴스를 삭제한 뒤 청구서에서 backup 항목이 남아 있으면 final snapshot을 지워야 하는지, retained automated backup을 지워야 하는지 먼저 막히게 된다. 2026년 6월 28일 기준 AWS 공식 문서를 다시 보면 이 둘은 복구 범위도 다르고 만료 규칙도 다르고 삭제 메뉴도 다르다. 이 글은 비용을 끊거나 복구 지점을 남길 때 어떤 순서로 판단해야 하는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 final snapshot과 retained automated backup은 같은 백업이 아니다. final snapshot은 만료되지 않는 snapshot 객체이고, retained automated backup은 retention period 안에서 point-in-time restore를 가능하게 하는 자동 백업 묶음이다. 둘은 독립적으로 남고, 독립적으로 비용을 만들 수 있으며, 삭제 경로도 다르다.

따라서 '인스턴스를 지웠는데도 청구가 남는다'는 증상에서 바로 snapshot 하나만 지우거나, 반대로 automated backup만 지우면 원하는 복구 지점까지 같이 잃을 수 있다. 먼저 어떤 객체가 남아 있는지, 복구 목적이 무엇인지, retention window가 아직 필요한지를 나눠 봐야 한다.

이미 멈춘 인스턴스와 삭제한 인스턴스의 backup storage 글이 왜 비용이 남는지를 다뤘다면, 이번 글은 그 다음 단계인 cleanup 순서다.

2. 어디서 실제로 막히는가

삭제 후 가장 흔한 오해는 세 가지다. 첫째, final snapshot을 만들었으니 retained automated backup은 자동으로 정리됐을 것이라고 생각한다. 둘째, retained automated backup을 지우면 final snapshot까지 같이 없어질 것처럼 느낀다. 셋째, RDS 콘솔에서 Snapshots 메뉴만 보고 비용 원인을 찾다가 Automated backups의 Retained 탭을 놓친다.

AWS 문서는 이 세 가지를 분명히 갈라 놓는다. backups overview는 final snapshot과 automated backups가 독립적이라고 설명하고, retained automated backups guide는 final snapshot은 만료되지 않지만 retained automated backups는 retention 규칙에 따라 결국 만료된다고 설명한다. delete instance guide는 인스턴스 삭제 시 retained automated backups를 남길지와 final snapshot을 생성할지를 따로 고르게 한다.

즉 이 문제는 '어떤 백업이 더 중요하냐'가 아니라 '어떤 복구 방식이 지금 필요한가'를 묻는 문제다. 특정 시점 snapshot 하나가 필요하면 final snapshot이 맞고, retention window 안의 point-in-time restore가 필요하면 retained automated backup이 맞다. 필요가 끝났는데도 남아 있으면 그때 비용 청소를 시작하면 된다.

• 증상: 인스턴스를 지웠는데 backup 항목 청구가 계속 남는다.
• 실패: final snapshot과 retained automated backup을 같은 객체로 본다.
• 막힘: Snapshots 메뉴만 보고 Automated backups의 Retained 탭을 보지 않는다.
• 누락: 삭제 시점의 retention period가 retained automated backup 수명에 영향을 준다는 점을 놓친다.

증상	먼저 볼 곳	판단 기준
삭제 후에도 PITR이 필요하다	Retained automated backups	retention window 안 복원이 필요한지 본다
특정 시점 보관만 필요하다	Final snapshot	장기 snapshot만 남기면 되는지 본다
청구를 빨리 끊고 싶다	남은 객체 목록	retained backup과 snapshot을 따로 지운다

3. 실무에서 적용하는 순서

정리 순서는 다섯 단계가 가장 안전하다. 먼저 현재 남은 객체가 final snapshot인지 retained automated backup인지 구분한다. 두 번째로 point-in-time restore가 아직 필요한지 판단한다. 세 번째로 장기 보관용 snapshot이 필요한지 판단한다. 네 번째로 필요 없는 retained automated backup을 Retained 탭이나 delete-db-instance-automated-backup으로 지운다. 마지막으로 필요 없는 final snapshot 또는 manual snapshot을 Snapshots 메뉴나 delete-db-snapshot으로 지운다.

1. 남은 객체가 무엇인지 먼저 분류한다.
2. PITR이 필요하면 retained automated backup을 남긴다.
3. 장기 snapshot이 필요하면 final snapshot을 남긴다.
4. retained automated backup은 Retained 탭 또는 전용 CLI로 삭제한다.
5. snapshot은 Snapshots 메뉴 또는 snapshot 삭제 명령으로 별도 정리한다.

• Automated backups의 Retained 탭을 열어 남은 항목을 조회한다.
• 복구 필요를 확인한 뒤 삭제할 retained automated backup을 선택한다.
• 삭제 전 DbiResourceId와 snapshot identifier를 기록하고 저장한다.
• 필요하면 CLI 명령을 실행하고, 삭제 후 목록을 다시 조회해 확인한다.

이때 삭제 순서를 한 줄로 외우면 도움이 된다. point-in-time restore window를 먼저 판단하고, 그 다음 장기 보관 snapshot을 판단하고, 마지막에 객체별 메뉴를 나눠 지운다. 목적이 끝난 retained automated backup은 비용만 남길 수 있고, 목적이 끝난 final snapshot은 무기한 남아 계속 청구될 수 있다. 삭제 전에는 목록을 다시 조회하고, 식별자를 다시 확인하고, 확인 문구를 입력하고, 삭제 명령을 실행한 뒤 결과를 한 번 더 확인하는 편이 안전하다.

점검 메모 예시

needs_pitr_window=true|false
needs_long_term_snapshot=true|false
retained_backup_present=true|false
final_snapshot_present=true|false
retained_backup_deleted=false
snapshot_deleted=false

팀 운영 관점에서는 인스턴스 삭제 체크리스트에 이 분기를 넣어 두는 편이 좋다. 삭제 요청을 받을 때 final snapshot 생성 여부와 retained automated backups 유지 여부를 함께 기록하면, 며칠 뒤 청구를 보고 다시 역추적하는 시간을 줄일 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 화면은 RDS backups overview의 핵심 문장이다. final snapshot과 automated backup을 같은 묶음으로 생각하면 삭제 순서를 계속 헷갈리게 된다.

AWS는 final snapshot과 manual snapshot이 automated backups와 독립적이라고 설명한다.

즉 인스턴스를 지울 때 final snapshot을 만들었다고 해서 retained automated backup까지 정리된 것은 아니다. 반대로 retained automated backup을 삭제해도 final snapshot은 그대로 남는다.

두 번째 자료는 retained automated backups guide다. 여기서는 retained automated backup은 결국 만료되지만 final snapshot은 만료되지 않는다고 분명히 적고 있다.

AWS는 retained automated backup은 결국 만료되지만 final snapshot은 만료되지 않는다고 설명한다.

그래서 장기 보관 지점과 단기 point-in-time recovery 지점을 나눠 봐야 한다. 복구 목적이 다르면 삭제 순서와 남길 객체도 달라진다.

세 번째 화면은 DB instance 삭제 가이드다. 인스턴스를 지우는 순간 retained automated backups를 남길지와 final snapshot을 만들지를 따로 결정한다.

DB instance 삭제 시 retained automated backups와 final snapshot은 별도 선택지로 취급된다.

이 문장을 보면 왜 콘솔에서 두 체크박스가 따로 있는지 이해가 된다. 삭제 시점의 retention period가 그대로 남기 규칙이 되므로, 지우기 전에 기간 설정도 같이 봐야 한다.

네 번째 자료는 snapshot deletion guide의 과금 경고다. retained automated backups와 snapshots는 필요 없어진 뒤에도 삭제 전까지 청구 대상이 될 수 있다.

AWS는 retained automated backups와 snapshots가 삭제 전까지 비용을 만들 수 있다고 경고한다.

이 문장이 중요한 이유는 post 52의 '왜 남아 있나'에서 한 단계 더 나아가 '그럼 어떤 순서로 지워야 하나'를 판단하게 만들기 때문이다. 비용을 끊으려면 객체 종류별 삭제 경로를 분리해야 한다.

다섯 번째 화면은 retained automated backups 삭제 경로다. console 탭이 snapshots가 아니라 Automated backups의 Retained 쪽이라는 점이 여기서 드러난다.

retained automated backup은 Automated backups의 Retained 탭 또는 delete-db-instance-automated-backup 경로로 삭제한다.

실무에서 final snapshot을 Snapshots 메뉴에서 지우고도 청구가 남는 이유가 바로 이 분기다. retained automated backup은 다른 메뉴와 다른 API를 쓴다.

CLI 기준으로는 순서가 더 선명하다. 먼저 어떤 retained automated backup이 남았는지 조회하고, 그다음 필요 없는 항목만 지우고, snapshot은 별도 명령으로 다룬다.

retained automated backup과 snapshot을 나눠 조회하고 삭제하는 CLI 예시다.

이미 backup storage가 남는 지점 글을 읽었다면, 이번 예시는 그 뒤 cleanup 단계다.

마지막 자료는 삭제 판단표다. 복구 목적, 만료 여부, 삭제 위치를 한 번에 놓으면 어떤 객체를 먼저 지울지 빠르게 결정할 수 있다.

final snapshot과 retained automated backup의 복구 범위, 만료 여부, 삭제 위치를 비교한 표다.

또 RDS stop 7일 자동 재시작 글을 같이 보면, 인스턴스를 멈춘 상태와 삭제 후 남은 객체 상태를 더 분리해서 볼 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 retained automated backup을 먼저 지워 point-in-time restore window를 잃는 것이다. 두 번째 리스크는 final snapshot이 장기 보관 기준점인데 비용 절감만 보고 급히 지워 버리는 것이다. 세 번째 리스크는 retention period가 삭제 시점 기준으로 정해진다는 점을 놓쳐, 이미 길게 잡힌 retained automated backup이 오래 남는 이유를 이해하지 못하는 것이다.

또 비용 계산도 단순하지 않다. AWS pricing은 backup storage가 무료 할당을 넘는 구간에서 청구될 수 있다고 설명한다. 따라서 객체를 지울지 말지는 단지 오늘 청구서 한 줄이 아니라, 복구 정책과 무료 할당 초과 여부를 같이 보고 결정하는 편이 맞다.

• retained automated backup을 지우면 PITR window도 같이 사라진다.
• final snapshot은 자동 만료되지 않으므로 장기 보관 기준을 정해 둔다.
• 삭제 전 retention period와 무료 backup storage 초과 여부를 같이 본다.

6. 결론

RDS 삭제 후 남는 비용을 정리할 때는 final snapshot과 retained automated backup을 같은 객체처럼 다루면 안 된다. retained automated backup은 point-in-time restore용, final snapshot은 장기 보관용으로 보고 목적이 끝난 순서대로 따로 지워야 비용과 복구 리스크를 같이 관리할 수 있다.

• PITR이 필요하면 retained automated backup을 남긴다.
• 장기 보관이 필요하면 final snapshot을 남긴다.
• 삭제 메뉴와 CLI가 다르므로 객체를 먼저 분류한다.

7. 참고 링크

1. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html
2. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.Retaining.html
3. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups-Deleting.html
4. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html
5. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteSnapshot.html
6. https://aws.amazon.com/rds/pricing/