[AWS RDS][운영] deleting 상태 정리 뒤 promoted replica 확인과 retained automated backup cleanup을 어떤 순서로 마무리하나

IT 리서치 노트

[AWS RDS][운영] deleting 상태 정리 뒤 promoted replica 확인과 retained automated backup cleanup을 어떤 순서로 마무리하나

Amazon RDS에서 source 인스턴스가 deleting 상태를 끝내면 많은 팀이 사건이 완전히 끝났다고 생각한다. 하지만 2026년 8월 25일 기준 AWS 공식 문서를 다시 보면 same-Region read replica는 standalone으로 승격될 수 있고, final snapshot과 retained automated backup은 서로 독립적으로 남을 수 있다. 이 글은 deleting 상태 정리 뒤 promoted replica 확인과 retained automated backup cleanup을 어떤 순서로 마무리해야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 deleting 종료 뒤에는 먼저 promoted replica를 운영 대상 관점에서 확인하고, 그 다음 final snapshot·retained automated backup·manual snapshot을 비용 관점에서 별도로 정리해야 한다. source 인스턴스가 없어졌다고 해서 backup storage와 restore 객체까지 자동으로 같은 시각에 사라지는 것은 아니다.

이미 deleting 상태에서 final snapshot 대기와 replica promotion 증거 글이 삭제 진행 중 신호를 다뤘다면, 이번 글은 deleting 이후 후처리 단계다. 또 삭제 전 deletion protection, final snapshot, retained automated backup 점검 글과 이어 읽으면 삭제 전후 runbook이 하나로 묶인다.

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

실무에서 가장 흔한 오해는 deleting 완료를 곧 cleanup 완료로 보는 것이다. 하지만 source DB instance를 삭제할 때 same-Region read replica가 standalone으로 승격될 수 있고, retained automated backups와 final snapshot은 그와 별개로 남는다. 이 때문에 콘솔에서 source 인스턴스만 사라졌다고 끝났다고 판단하면 나중에 backup storage와 restore 대상이 예상보다 많이 남는다.

AWS 문서는 delete instance 뒤 same-Region read replica가 자동 승격될 수 있다고 적고 있고, retained automated backups 문서는 final snapshot과 retained automated backup이 독립적이라고 설명한다. delete retained automated backup 문서는 delete instance가 끝난 뒤에도 retained automated backup을 별도 작업으로 지울 수 있다고 안내한다. 즉 deleting 이후에는 운영 대상 확인과 비용 cleanup이 동시에 남아 있을 수 있다.

문제가 더 커지는 지점은 기록 방식이다. promoted replica를 source 인스턴스의 연장선처럼만 적거나, final snapshot과 retained automated backup을 같은 snapshot bucket으로만 적으면 restore 기준과 비용 기준이 함께 섞인다. promoted replica가 실제 서비스 대상이면 유지해야 하고, retained automated backup은 별도 cleanup 후보일 수 있다. 역할이 다르므로 메모도 별도여야 한다.

• 증상: source 인스턴스는 사라졌는데 backup storage가 계속 남는다.
• 실패: promoted replica와 final snapshot을 같은 cleanup 대상으로 본다.
• 막힘: retained automated backup과 manual snapshot을 같은 목록으로만 본다.
• 누락: deleting 이후 어떤 객체가 운영 대상이고 어떤 객체가 정리 대상인지 기록하지 않는다.

증상	먼저 볼 곳	판단 기준
삭제는 끝났는데 replica가 남아 보임	read replica 승격 상태	standalone 운영 대상으로 남길지 본다
snapshot/backup 비용이 남음	retained automated backup / manual snapshot 목록	어떤 객체가 실제 비용 대상인지 분리한다
복구 기준이 불명확	final snapshot 보존 사유	복구용 보존과 비용 cleanup을 따로 기록한다

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

가장 실용적인 후처리 순서는 여섯 단계다. 먼저 source 삭제 뒤 promoted replica가 standalone으로 살아 있는지 확인한다. 다음으로 final snapshot 이름과 복구 보존 사유를 적는다. 세 번째로 retained automated backup이 남았는지 Automated backups의 Retained 탭에서 확인한다. 네 번째로 manual snapshot과 retained automated backup을 따로 inventory 한다. 다섯 번째로 불필요한 retained automated backup이나 snapshot을 별도 삭제한다. 마지막으로 cleanup 후 무엇이 복구용으로 남았고 무엇이 과금 대상으로 사라졌는지 다시 기록한다.

1. promoted replica가 standalone으로 승격됐는지 확인한다.
2. final snapshot 보존 사유와 이름을 적는다.
3. retained automated backup 존재 여부를 별도 탭에서 확인한다.
4. manual snapshot과 retained automated backup을 따로 inventory 한다.
5. 불필요한 retained automated backup과 snapshot을 별도 삭제한다.
6. cleanup 뒤 남은 restore 대상과 비용 대상 결과를 다시 적는다.

이 순서를 쓰면 promoted replica를 복구 자산과 혼동하지 않고, backup cleanup도 restore 기준과 함께 설명할 수 있다. 운영팀은 promoted replica를 새 서비스 인스턴스로 받아야 할 수 있고, 비용 담당자는 retained automated backup과 manual snapshot을 별도로 지워야 할 수 있다. deleting 완료 직후 두 팀이 보는 대상이 다르다는 점을 메모에 바로 반영해야 한다.

post-delete 메모 예시

source_delete_completed_at=2026-08-25 11:08 KST
promoted_replica_identifier=prod-db-replica-1
promoted_replica_confirmed_at=2026-08-25 11:12 KST
final_snapshot_name=prod-db-final-2026-08-25
retained_backup_present=true
manual_snapshot_count=1
retained_backup_deleted_at=2026-08-25 11:31 KST

이렇게 적어 두면 월말 비용 회고에서도 무엇이 살아 있었는지 바로 설명할 수 있다. source DB instance 삭제와 restore 자산 cleanup은 같은 이벤트처럼 보여도 실제로는 서로 다른 후속 작업이다.

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

첫 화면은 RDS delete instance 문서다. source DB instance를 지울 때 same-Region read replica가 자동 승격될 수 있다는 문장을 먼저 확인해야 deleting 상태가 풀린 뒤 무엇을 다시 점검할지 정해진다.

RDS는 source DB instance 삭제 시 same-Region read replica를 standalone DB instance로 자동 승격할 수 있다고 설명한다.

즉 deleting이 끝났다고 바로 비용 정리가 끝난 것은 아니다. promoted replica가 실제로 어떤 인스턴스로 남았는지와, retained automated backup이나 final snapshot이 별도로 남았는지를 뒤이어 확인해야 한다.

두 번째 자료는 retained automated backups 문서다. final snapshot과 retained automated backup이 독립적이라는 설명이 있기 때문에 cleanup 순서도 이 둘을 분리해서 잡아야 한다.

final snapshot은 retained automated backup과 별개이며, retained automated backups와 manual snapshots는 삭제 전까지 비용이 남을 수 있다.

운영 메모에서 이 둘을 같은 백업 객체처럼 쓰면 청구서 설명이 무너진다. promoted replica 확인과 backup cleanup을 같은 단계로 보지 말아야 하는 이유도 여기 있다.

세 번째 화면은 retained automated backup 삭제 문서다. delete instance가 끝난 뒤에도 retained automated backup은 별도 작업으로 지워야 할 수 있다는 점을 보여 준다.

retained automated backup은 별도 delete 동작으로 제거할 수 있으며, deleting 완료와 자동으로 같은 시각에 정리되지 않을 수 있다.

이 단계가 없으면 source instance는 사라졌는데도 backup storage와 restore 가능 항목이 남아 혼란을 만든다. promoted replica가 남은 경우에는 어떤 인스턴스가 새 운영 대상인지도 같이 적어야 한다.

deleting 이후 점검은 replica, final snapshot, retained automated backup, manual snapshot 네 갈래를 같은 표로 보되, 확인 순서와 삭제 순서는 별도로 적는 편이 좋다.

deleting 상태 정리 뒤 확인 대상과 cleanup 대상을 나눠 보는 표다.

이미 deleting 상태에서 final snapshot 대기와 replica promotion 증거 글을 봤다면, 이번 표는 deleting 이후 후처리 단계다.

마지막 자료는 deleting이 끝난 직후 바로 실행할 체크리스트다. event log를 읽는 단계에서 한 걸음 더 나아가, 어떤 객체를 유지하고 어떤 객체를 지울지 복구 기준과 비용 기준을 함께 적어야 한다.

promoted replica 확인과 retained automated backup cleanup을 순서대로 끝내는 post-delete 체크리스트다.

특히 final snapshot과 retained automated backup 차이 글을 같이 보면 보존 판단이 더 빨라진다.

5. 주의사항과 리스크

첫 번째 리스크는 promoted replica를 cleanup 대상으로 오해해 운영 대상 인스턴스를 놓치는 것이다. 두 번째 리스크는 final snapshot과 retained automated backup을 같은 보존 항목으로 적어 비용 정리가 늦어지는 것이다. 세 번째 리스크는 delete instance 완료 시각만 남기고 retained automated backup 삭제 시각이나 snapshot 삭제 여부를 기록하지 않는 것이다.

후처리 뒤에는 최소한 네 가지를 다시 보는 편이 좋다. standalone replica 존재 여부, final snapshot 보존 여부, retained automated backup 삭제 여부, manual snapshot 잔존 여부다. 이 네 개는 source 인스턴스 삭제 후에도 남을 수 있는 주요 객체다.

• promoted replica는 운영 대상일 수 있으므로 cleanup 대상과 분리한다.
• final snapshot과 retained automated backup을 별도로 기록한다.
• 삭제 완료 시각과 backup cleanup 시각을 따로 남긴다.

6. 결론

RDS deleting 상태의 끝은 source 인스턴스 삭제 완료가 아니라, promoted replica와 restore 자산을 각각 정리한 시점에 가깝다. promoted replica 확인을 먼저 하고, retained automated backup과 snapshot cleanup을 그다음에 따로 끝내야 운영과 비용 설명이 둘 다 맞는다.

삭제 직후 handoff와 복구 기준까지 더 세밀하게 나눠 적고 싶다면 promoted replica handoff 뒤 retained backup 삭제 완료와 LatestRestorableTime 종료를 같은 완료 신호로 보면 안 되는 이유 글을 이어서 보면 좋다. 이번 글이 후처리 순서를 잡는 출발점이라면, 후속 글은 어떤 종료 신호를 따로 기록해야 하는지까지 확장한다.

• promoted replica를 먼저 확인한다.
• retained automated backup과 snapshot을 그다음에 정리한다.
• 운영 대상과 비용 cleanup 대상을 다른 줄로 남긴다.

7. 참고 링크

1. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html
2. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.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_DeleteSnapshot.html