[AWS RDS][운영] manual snapshot keep reason은 남겼는데 final snapshot 삭제 시각이 엇갈릴 때 어떤 closure 메모 줄을 추가하나

IT 리서치 노트

[AWS RDS][운영] manual snapshot keep reason은 남겼는데 final snapshot 삭제 시각이 엇갈릴 때 어떤 closure 메모 줄을 추가하나

Amazon RDS 정리 메모에서 manual snapshot keep reason은 잘 남겼는데, final snapshot이 실제로 언제 생성됐고 언제 유지 또는 삭제 판단으로 넘어갔는지 비어 있는 경우가 많다. 하지만 2026년 8월 26일 기준 AWS 공식 문서를 다시 보면 final snapshot은 delete workflow 안에서 따로 시간을 갖고 생성되며, manual snapshot keep reason과 같은 줄로 처리하기 어렵다. 이 글은 manual snapshot keep reason을 이미 적어 둔 상황에서 final snapshot 삭제 시각이 엇갈릴 때 어떤 closure 메모 줄을 하나 더 추가하면 되는지 정리한다.

목차

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

1. 개요

결론부터 말하면 manual snapshot keep reason을 남긴 뒤에도 final snapshot created at 또는 final snapshot disposition 줄을 하나 더 두는 편이 좋다. keep reason 줄은 왜 restore asset을 남겼는지 설명하고, final snapshot 줄은 delete workflow가 실제로 언제 끝났는지 설명한다.

이미 manual snapshot leftovers와 retained automated backup cleanup 글이 inventory 자체를 나눴다면, 이번 글은 final snapshot 시간축을 추가하는 후속편이다. restore asset 메모가 있더라도 final snapshot 생성 시각이 비어 있으면 closure note는 아직 반쪽이다.

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

가장 흔한 실패는 snapshot inventory 표에 manual snapshot keep reason만 적고 incident close를 선언하는 것이다. 이 경우 몇 시간 뒤 final snapshot이 생성되거나, 반대로 delete workflow가 오래 걸리면 실제 close 기준이 애매해진다.

두 번째 실패는 final snapshot을 manual snapshot leftovers와 같은 버킷으로 적는 것이다. 둘 다 snapshot이라는 공통점은 있지만, 하나는 deliberate restore asset일 수 있고 다른 하나는 delete workflow에서 생성된 산출물이다. 생성 시점과 삭제 판단 시점도 다르다.

세 번째 실패는 retained automated backup cleanup 줄로 final snapshot 시각을 대신하는 것이다. AWS 문서가 분명히 적듯 final snapshot과 retained automated backups는 독립 객체이므로, retained cleanup 줄이 채워졌다고 final snapshot closure까지 끝난 것은 아니다.

• 증상: manual snapshot keep reason은 있는데 final snapshot 생성 시각은 비어 있다.
• 실패: final snapshot과 manual snapshot leftovers를 같은 칸에 적는다.
• 막힘: retained backup cleanup 줄로 final snapshot 상태를 대신한다.
• 누락: final snapshot disposition과 next check가 메모에 없다.

이미 있는 줄	아직 설명 못 하는 것	추가할 줄
manual_snapshot_keep_reason	delete workflow의 final snapshot 완료 시각	final_snapshot_created_at
retained_backup_deleted_at	final snapshot을 유지할지 삭제할지 판단	final_snapshot_disposition
incident_close	snapshot 검토가 언제 다시 필요한지	final_snapshot_next_check

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

가장 실용적인 정리 순서는 다섯 단계다. 먼저 manual snapshot inventory와 keep reason을 기존처럼 적는다. 다음으로 delete-db-instance 이후 final snapshot을 생성하기로 했다면, DB status가 deleting에 머무는 동안 final snapshot 완료 시각을 기다린다. 세 번째로 final snapshot id와 created at을 메모에 추가한다. 네 번째로 이 snapshot을 keep할지 delete review로 넘길지 disposition을 적는다. 마지막으로 retained backups와 manual snapshots를 다시 섞지 않도록 next check를 남긴다.

1. manual snapshot keep reason을 기존 inventory 줄에 적는다.
2. delete workflow에서 final snapshot 생성 완료를 기다린다.
3. final snapshot id와 created at을 새 줄로 추가한다.
4. keep 또는 delete review disposition을 적는다.
5. next check를 남긴 뒤 incident close 조건을 판단한다.

실행할 때는 먼저 Snapshots 메뉴의 manual snapshot inventory와 keep reason을 확인한다. 그다음 delete-db-instance 작업 뒤 상태가 deleting에서 벗어나는 시점에 final snapshot이 실제로 생성됐는지 확인하고, snapshot id와 시각을 메모에 적는다. 이어서 이 final snapshot을 postmortem까지 유지할지, 즉시 삭제 검토로 넘길지 disposition을 정하고 next check 일자를 남긴다.

여기서는 Snapshots 메뉴, DB status 상태, final snapshot id 필드, created at 필드, next check 필드를 순서대로 조회하고 저장하는 편이 좋다. delete workflow 결과를 확인한 뒤 표에 입력하고, 필요하면 삭제 버튼을 바로 누르지 말고 keep 또는 delete review 상태를 먼저 적어 두면 나중에 로그와 결과를 비교하기 쉽다.

실무에서는 Snapshots 메뉴를 클릭하고, DB status를 확인하고, final snapshot id 필드를 입력하고, created at 값을 저장하고, disposition 결과를 기록하고, next check 파일을 저장하는 흐름이 반복된다. 각 단계의 로그, 결과, 상태를 같은 표에 적어 두면 삭제 실행 뒤 다시 조회할 때도 판단이 빨라진다.

closure line example

1. Snapshots 메뉴에서 manual snapshot 이름과 keep reason을 확인한다
2. delete-db-instance 결과에서 DB status를 조회한다
3. final snapshot id와 created at 필드를 입력한다
4. disposition, next check, incident close 상태를 저장한다

실무 메모는 최소한 manual_snapshot_keep_reason, final_snapshot_created_at, final_snapshot_disposition, final_snapshot_next_check를 포함하는 편이 좋다. 이 네 줄이 있으면 restore asset 메모와 delete workflow 메모를 서로 다른 시간축으로 설명할 수 있다.

주의

final snapshot은 retained automated backup cleanup 줄로 대체되지 않는다. manual snapshot keep reason도 final snapshot created at 줄을 대신하지 못한다. 둘은 각각 restore asset 이유와 delete workflow 완료 시각을 설명한다.

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

첫 공식 문구는 source DB 삭제 뒤에도 manual snapshot이 자동 삭제되지 않는다는 점을 다시 확인시켜 준다. keep reason을 메모에 남긴 이유가 바로 여기서 생긴다.

AWS는 DB 인스턴스를 삭제해도 manual DB snapshots는 자동 삭제되지 않는다고 설명한다.

따라서 manual snapshot keep reason을 남겨 두는 것만으로는 closure가 끝나지 않는다. final snapshot이 실제로 언제 만들어지고, 언제 삭제 대상으로 넘어가는지는 또 다른 시간축이다.

두 번째 문구는 deleting 상태와 final snapshot 생성 시각을 직접 연결한다. deleting이 끝나는 시점과 final snapshot 삭제 검토 시점이 꼭 같은 것은 아니라는 점을 여기서 분리해야 한다.

AWS는 final snapshot을 만들기로 하면 해당 snapshot이 생성될 때까지 DB 인스턴스 상태가 deleting으로 남는다고 설명한다.

실무에서 엇갈림이 생기는 이유가 여기다. 운영 메모에 manual snapshot keep reason만 적어 두면 final snapshot이 언제 생성됐고 언제 검토 대상으로 넘어갔는지 빈칸이 남는다.

세 번째 자료는 final snapshot과 retained automated backup이 독립 객체라는 설명이다. final snapshot 시각을 따로 적어야 retained backup cleanup 메모와 섞이지 않는다.

AWS는 final snapshot과 retained automated backup을 서로 독립적인 객체로 설명한다.

이 문구를 기준으로 보면 closure note에는 manual snapshot keep reason, final snapshot 생성 시각, retained backup cleanup 시각이 각각 따로 있어야 한다. 하나만 남기면 나머지 축이 비어 보인다.

네 번째 문구는 장기 보존이 필요하면 automated backup을 manual snapshot으로 복사하라고 안내한다. 즉 manual snapshot keep reason은 deliberate keep일 수 있지만, final snapshot 타이밍은 delete workflow 안쪽에서 별도로 기록해야 한다.

AWS는 장기 보존이 필요하면 automated backup을 manual snapshot으로 복사해 manual snapshot으로 관리하라고 안내한다.

이 문구 덕분에 keep reason 줄과 final snapshot 시각 줄의 역할이 분명해진다. keep reason 줄은 왜 남겼는지를 설명하고, final snapshot 줄은 delete workflow에서 실제로 어느 시점까지 기다렸는지를 설명한다.

실무에서는 restore asset 메모와 delete workflow 메모를 같은 줄에 쓰지 않는 편이 좋다. keep reason 줄을 이미 적었다면, 여기에 final snapshot 생성 시각 또는 검토 시각을 위한 closure 줄을 하나 더 추가하면 된다.

manual snapshot keep reason과 final snapshot timing을 분리한 closure 메모 줄 예시다.

이미 manual snapshot leftovers와 retained automated backup cleanup 글이 restore asset inventory를 나눴다면, 이번 표는 final snapshot 시간축을 한 줄 더 추가하는 후속편이다. 앞선 종료 신호 분리는 LatestRestorableTime 종료 글과도 이어진다.

마지막 메모 예시는 final snapshot 시각이 빠졌을 때 어떤 줄을 추가하면 되는지 보여 준다. keep reason만 남긴 메모와 비교하면 close 조건이 훨씬 분명해진다.

manual snapshot keep reason 뒤 final snapshot timing 줄을 추가한 cleanup 메모 예시다.

운영에서 필요한 것은 삭제 뒤 snapshot이 남아 있다는 사실보다, 어떤 snapshot이 intentional keep이고 어떤 snapshot은 delete workflow 산출물인지 분리해서 설명하는 일이다. final snapshot 줄이 그 차이를 짧게 남겨 준다.

5. 주의사항과 리스크

첫 번째 리스크는 final snapshot 시각 없이 incident를 닫는 것이다. 두 번째는 final snapshot disposition이 없어서 postmortem 뒤에도 삭제 결정을 다시 찾게 되는 것이다. 세 번째는 manual snapshot과 final snapshot을 같은 owner가 같은 이유로 관리한다고 가정하는 것이다.

운영 문서에는 어떤 snapshot이 deliberate keep인지, 어떤 snapshot이 delete workflow 산출물인지 드러나야 한다. 그래야 비용 점검과 복구 자산 점검이 서로 다른 사람에게 배정돼도 설명이 짧다.

• manual snapshot keep reason은 restore asset 이유를 설명한다.
• final snapshot created at은 delete workflow 완료 시각을 설명한다.
• final snapshot disposition은 다음 삭제 판단 또는 유지 판단을 설명한다.

6. 결론

manual snapshot keep reason만 남기면 restore asset 이유는 설명돼도 delete workflow의 final snapshot 시간축은 비어 있다. final snapshot created at 또는 disposition 줄을 하나 더 추가하면 snapshot 정리가 훨씬 짧아진다.

• keep reason 줄과 final snapshot timing 줄을 분리한다.
• final snapshot disposition과 next check를 같이 남긴다.
• retained backup cleanup 줄과 final snapshot 줄을 서로 대체하지 않는다.

7. 참고 링크

1. https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html
2. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.Retaining.html
3. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html
4. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteSnapshot.html