[AWS RDS][운영] DB 인스턴스를 삭제하기 전에 deletion protection, final snapshot, retained automated backup을 어떤 순서로 확인하나

IT 리서치 노트

[AWS RDS][운영] DB 인스턴스를 삭제하기 전에 deletion protection, final snapshot, retained automated backup을 어떤 순서로 확인하나

AWS RDS 인스턴스를 삭제할 때 운영팀이 가장 자주 섞는 값은 deletion protection, final snapshot, retained automated backups 세 가지다. 2026년 8월 18일 기준 AWS 공식 문서를 다시 보면 삭제 전제조건, 복구 가능성, 비용, replica 영향이 각각 다른 문단에 흩어져 있다. 이 글은 삭제 버튼을 누르기 전에 어떤 순서로 확인하고 무엇을 메모해야 incident 후 복구와 비용 설명이 덜 꼬이는지 정리한 runbook이다.

목차

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

1. 개요

결론부터 말하면 RDS 삭제 전 점검 순서는 deletion protection 해제 확인 → final snapshot 필요 여부 결정 → retained automated backups 유지 여부 결정 → replica·비용·삭제 시간 메모 순으로 가는 편이 가장 안전하다. final snapshot과 retained automated backups는 둘 다 백업처럼 보이지만 복구 시점과 비용 구조가 다르므로 한 질문으로 묶으면 안 된다.

즉 삭제 전 runbook의 핵심은 “백업을 남길까”가 아니라 “삭제 호출을 가능하게 하는 값, 삭제 뒤 수동 복구 값, 삭제 뒤 PITR 값, 삭제 후 비용 값”을 분리하는 데 있다. 콘솔과 CLI를 같이 쓰는 팀일수록 이 네 칸을 같은 표에 둬야 한다.

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

실무에서 주로 막히는 지점은 네 가지다. 첫째, 삭제가 안 되는데 snapshot이나 retention부터 바꾸며 시간을 쓴다. 실제 원인은 deletion protection이 켜진 경우가 많다. 둘째, final snapshot을 남기지 않아도 retained automated backups가 있으면 언제든 같은 복구가 된다고 오해한다. 셋째, retained automated backups와 manual/final snapshot의 과금 구간을 한 메모에 섞어 비용 설명이 꼬인다. 넷째, read replica가 있는 원본 인스턴스를 지우면서 replica 승격과 topology 변화 기록을 빼먹는다.

AWS 공식 문서는 삭제 전 prerequisites에서 deletion protection을 먼저 보라고 적고, considerations에서는 final snapshot, retained automated backups, manual snapshot 미삭제, replica 승격, deleting 상태 지속 시간을 따로 설명한다. 이 구조를 그대로 operational order로 바꾸지 않으면 콘솔에서 Delete를 눌렀다가 “어차피 백업은 남았겠지” 같은 추정으로 이어지기 쉽다. 특히 incident 직후 복구 경로를 설명해야 할 때 snapshot 복구인지 PITR 복구인지 분리되어 있지 않으면 대응 시간이 길어진다.

또 하나의 문제는 비용과 복구 판단을 같은 승인 단계에서 섞는 것이다. retained automated backups는 retention 기간 동안 PITR 창을 남길 수 있지만, 그 사실만으로 final snapshot을 대체하는 것은 아니다. 반대로 final snapshot을 만들었다고 해서 retention 기간과 자동 백업 비용이 자동 정리되는 것도 아니다. 삭제 전에 콘솔에서 옵션을 확인하고, CLI 명령을 저장하고, 비용 메모를 남기고, replica 유무를 조회하는 네 동작을 분리해야 재발이 줄어든다.

• 증상: Delete 버튼이 막히거나 API가 거부된다.
• 오류: final snapshot과 retained automated backups를 같은 복구 수단처럼 기록한다.
• 실패: replica 승격 영향과 deleting 상태 장기화를 삭제 후에야 확인한다.
• 재발: 비용, 복구, retention 기간을 같은 승인 문장으로만 남긴다.

증상	먼저 조회할 값	바로 해야 할 동작
삭제 호출이 막힘	deletion protection	콘솔 설정과 modify-db-instance 값을 확인한다
복구 창구가 불명확	final snapshot, retained backup	snapshot 복구와 PITR 복구를 별도 메모로 남긴다
비용 설명이 꼬임	retention 기간, snapshot 잔존	삭제 후 남는 리소스를 비용표에 따로 적는다

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

가장 짧은 실행 순서는 다섯 단계다. 먼저 콘솔이나 CLI에서 deletion protection 상태를 조회한다. 다음으로 final snapshot을 만들지, 이미 있는 manual snapshot을 복구 근거로 삼을지 결정한다. 세 번째로 retained automated backups를 유지할지 말지 정하고 retention 기간을 같이 적는다. 네 번째로 read replica가 있으면 승격 영향과 삭제 후 topology를 메모한다. 마지막으로 실제 삭제 명령 또는 콘솔 선택값을 운영 로그에 남긴다.

1. 콘솔에서 protection 토글을 확인하고 필요하면 수정한다.
2. snapshot 복구 기준을 정하고 final snapshot 이름을 저장한다.
3. retention 기간과 retained automated backups 유지 여부를 입력한다.
4. replica, deleting 예상 시간, 비용 메모를 조회하고 저장한다.
5. CLI 명령이나 콘솔 체크값을 incident note에 복사해 남긴다.

삭제 승인 메모 예시

db_instance=mydbinstance
deletion_protection=false
final_snapshot=create:mydbinstance-final-2026-08-18
retain_automated_backups=true
retention_period_days=7
read_replica_count=1
delete_window=planned-2026-08-18T21:30+09:00

실제 작업에서는 콘솔 값을 확인하고, describe-db-instances 결과를 조회하고, CLI 명령을 저장하고, 삭제 후 남는 snapshot과 automated backup 비용을 메모하고, replica 승격 여부를 팀 채널에 공유하는 순서를 고정하는 편이 좋다. 이 다섯 동작은 모두 “확인”, “조회”, “저장”, “입력”, “공유” 같은 행동 단위로 적혀 있어야 하고, 삭제 승인서에는 최종 선택값이 숫자나 이름으로 남아야 한다.

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

첫 공식 화면은 삭제 전제조건이다. AWS는 DB 인스턴스를 지우기 전에 deletion protection이 꺼져 있어야 한다고 바로 적어 둔다. 실제 운영에서 삭제 버튼이 비활성화되거나 API 호출이 막힐 때 가장 먼저 확인할 값이 여기다.

RDS 삭제 전에는 deletion protection이 꺼져 있어야 하며, 콘솔 생성 인스턴스는 기본적으로 이 옵션이 켜질 수 있다.

즉 삭제 runbook의 첫 줄은 snapshot 여부가 아니라 protection 상태다. 이미 final snapshot과 retained automated backup 차이를 정리한 글을 읽었다면, 이번 글은 그 앞단에서 삭제 자체를 막는 토글부터 다시 고정하는 체크리스트다.

두 번째 공식 화면은 final snapshot 판단 구간이다. 여기서는 마지막 스냅샷을 남길지, 남기지 않으면 무엇을 복구 근거로 삼을지 읽어야 한다. 실수는 대부분 snapshot을 안 남긴 상태에서 later restore 경로를 막연히 기대할 때 생긴다.

final DB snapshot은 삭제 뒤 수동 복구 근거가 되며, snapshot을 만들지 않으면 retained automated backup이나 기존 manual snapshot이 대안이 된다.

운영자는 삭제 전에 콘솔에서 snapshot 이름을 입력하고, 복구 테스트 대상이 manual snapshot인지 automated backup인지 구분하고, 비용 기록까지 같이 남겨야 한다. snapshot을 남길지 말지만 적고 복구 창구를 안 적어 두면 incident 후 재현이 길어진다.

세 번째 공식 화면은 retain automated backups 선택지다. 이 옵션은 final snapshot과 별개라서 실무자가 자주 섞는다. retention 기간 동안 PITR 창을 남길지, 삭제와 동시에 같은 리전 자동 백업을 비울지 분리해서 읽어야 한다.

Retain automated backups 옵션은 final snapshot과 별개이며, retention 기간과 삭제 뒤 복구 가능 구간을 따로 결정한다.

이미 멈춘·삭제된 인스턴스의 backup storage 비용이 남는 지점을 다룬 글이 비용 측면을 설명했다면, 이번 글에서는 삭제 직전 화면에서 어떤 토글을 어떤 순서로 읽어야 비용과 복구를 함께 통제할 수 있는지에 초점을 둔다.

현장 점검은 네 줄 표로 줄여 두는 편이 가장 빠르다. 삭제를 누르기 전에 protection, snapshot, retained backup, replica 영향을 같은 표에서 확인하면 누락이 줄어든다.

RDS 삭제 전 점검 순서를 protection, snapshot, retained backup, replica 영향 기준으로 나눈 표다.

삭제 승인 회의나 운영 메모에서는 이 표를 그대로 열고 콘솔에서 값 확인, CLI 조회, 로그 저장, 비용 체크를 순서대로 진행하면 된다. 특히 replica 승격과 삭제 시간 지연은 마지막에 읽지 말고 삭제 전에 분리해야 한다.

CLI에서도 final snapshot 경로와 no-final-snapshot 경로를 분리해 저장하는 편이 안전하다. 한 줄 명령만 남기면 나중에 어떤 조합으로 삭제했는지 복기하기 어렵다.

final snapshot 생성 경로와 retained automated backups 유지 경로를 분리한 RDS CLI 예시다.

운영자는 삭제 전에 명령 파일을 저장하고, 출력 로그를 남기고, 콘솔 값과 CLI 값이 같은지 확인하고, 비용 태그와 incident note를 같이 적어 두는 편이 좋다.

5. 주의사항과 리스크

첫 번째 리스크는 deletion protection 해제 여부를 빼먹고 삭제 작업창만 계속 새로고침하는 것이다. 두 번째는 final snapshot과 retained automated backups를 같은 백업 계층처럼 취급하는 것이다. 세 번째는 비용 문서에는 snapshot만 적고, 실제 복구 문서에는 automated backup만 적어 팀 메모가 서로 어긋나는 것이다. 네 번째는 read replica가 standalone으로 승격되는 흐름을 삭제 후에야 발견하는 것이다.

삭제 직전에는 콘솔 메뉴, CLI 명령, 비용 표, replica 상태, deleting 예상 시간 다섯 칸을 같이 확인해야 한다. 운영팀은 값을 입력하고, 명령을 실행하고, 로그를 저장하고, 결과를 조회하고, 다시 설정을 확인하는 과정을 같은 템플릿으로 반복해야 incident 회고가 짧아진다.

• final snapshot과 retained automated backups는 복구 범위와 비용이 다르다.
• replica 영향과 deleting 시간은 삭제 후가 아니라 삭제 전에 읽는다.
• 수동 승인 메모에는 protection, snapshot, retention, replica를 모두 적는다.

6. 결론

RDS 삭제는 Delete 버튼 한 번의 문제가 아니라 protection, snapshot, retention, replica를 순서대로 끊어 보는 작업이다. 먼저 deletion protection을 확인하고, 그다음 final snapshot과 retained automated backups를 अलग게 결정하고, 마지막으로 비용과 replica 영향을 메모하면 삭제 후 복구와 설명이 훨씬 짧아진다.

• 삭제 전제조건은 protection 상태다.
• snapshot 복구와 PITR 복구는 별도 메모로 남긴다.
• 비용과 replica 영향은 삭제 직전 체크리스트에 포함한다.

7. 참고 링크

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