[AWS RDS][운영] deleting 상태에서 final snapshot 대기와 replica promotion 증거를 event log 기준으로 어떻게 나누나

IT 리서치 노트

[AWS RDS][운영] deleting 상태에서 final snapshot 대기와 replica promotion 증거를 event log 기준으로 어떻게 나누나

RDS source DB instance를 지운 뒤 상태가 오래 deleting으로 남으면 많은 팀이 'snapshot이 느리다' 또는 'replica가 문제다'를 같은 말처럼 쓴다. 하지만 2026년 8월 24일 기준 AWS 공식 문서를 다시 보면, 같은 리전의 read replica는 source delete 뒤 standalone으로 자동 승격될 수 있고, final snapshot과 내부 정합성 작업이 끝날 때까지 source status는 deleting으로 남을 수 있다. 즉 deleting이라는 하나의 상태 안에 최소 두 줄의 증거가 섞여 있다. 이 글은 final snapshot 대기와 replica promotion 증거를 event log 기준으로 어떻게 나눠 적는 편이 운영에 덜 꼬이는지 정리한다.

목차

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

1. 개요

결론부터 말하면 RDS deleting 대응 메모는 final snapshot branch와 replica promotion branch 두 줄로 나누는 편이 가장 안전하다. source instance는 deleting 상태여도 replica는 이미 standalone 전환을 끝냈을 수 있고, 반대로 replica는 아직 전환 중인데 snapshot은 이미 닫혔을 수 있다.

즉 deleting은 증상이 아니라 컨테이너다. 실제 운영 판단은 'snapshot branch가 닫혔는가'와 'replica promotion branch가 닫혔는가'를 따로 보는 편이 맞다.

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

현장에서 가장 흔한 실패는 deleting 상태를 하나의 타이머로만 보는 것이다. 그러면 source 상태가 오래 같은 값을 보여 주는 순간 모든 원인을 final snapshot으로 몰아간다. 하지만 AWS 문서는 final snapshot과 내부 정합성 작업 때문에 deleting이 유지될 수 있다고 적고, 같은 리전 replica는 source delete 뒤 standalone으로 승격된다고도 설명한다. 즉 같은 시점에 서로 다른 두 작업이 동시에 진행될 수 있다.

두 번째 실패는 replica promotion을 delete 성공의 부산물 정도로만 적는 것이다. replica가 실제로 standalone으로 전환됐는지, backup retention과 window가 새 인스턴스 기준으로 다시 잡혔는지, role이 Replica에서 빠졌는지 확인하지 않으면 delete 후 읽기 경로 복구 메모가 빈다. source만 보고 있으면 replica 쪽 완료 증거를 놓치기 쉽다.

세 번째 실패는 event log와 상태표를 같이 안 남기는 것이다. deleting은 상태값이고, promotion은 종종 이벤트와 role 전환으로 더 빨리 보인다. 둘 중 하나만 남기면 어느 branch가 아직 안 닫혔는지 설명하기 어렵다. 특히 운영 교대 때는 status 한 줄보다 event log row가 더 설명력이 크다.

마지막으로 retained backups나 latest restorable time 같은 후속 정리 값을 delete 진행과 섞어 적는 것도 흔하다. 이 값들은 복구와 비용 판단을 위한 shared row에 가깝지, snapshot branch나 promotion branch 자체는 아니다. 증거 줄과 후속 정리 줄을 섞으면 회의가 길어진다.

• 증상: source status는 deleting인데 replica와 snapshot 중 무엇이 남았는지 바로 안 보인다.
• 실패: 모든 지연을 final snapshot 대기로만 적는다.
• 막힘: replica role 전환과 promotion evidence를 delete 메모에서 빼먹는다.
• 누락: event log row와 상태표 row를 분리하지 않는다.

질문	먼저 볼 줄	대표 값
source가 왜 아직 deleting인가	final snapshot branch	snapshot id, delete time, deleting status
replica는 이미 살아났는가	replica promotion branch	role change, promotion event, standalone settings
복구와 비용 판단은 어디에 적나	shared row	retained backups, latest restorable time, owner

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

가장 짧은 운영 순서는 다섯 단계다. 첫째, delete 시작 시각과 final snapshot id를 snapshot branch에 적는다. 둘째, same-Region replica 목록을 promotion branch에 적는다. 셋째, source deleting 상태와 replica role 변화를 별도 줄로 갱신한다. 넷째, event log와 상태표 중 무엇으로 닫았는지 적는다. 다섯째, retained backups와 latest restorable time은 shared row로만 남긴다.

1. delete 시작 시각과 snapshot id를 먼저 적는다.
2. same-Region replica를 별도 branch로 나눈다.
3. source deleting 상태와 replica role 변화를 따로 갱신한다.
4. event log 또는 상태표 중 어떤 증거로 닫았는지 적는다.
5. retained backups와 복구 값은 shared row로만 남긴다.

• 삭제 설정을 확인하고 snapshot id를 저장하고 source 상태를 콘솔에서 조회한다.
• replica role과 promotion 로그를 조회하고 오류 응답이나 경고 메시지를 파일로 저장한다.
• AWS CLI 명령 결과를 확인하고 이벤트 로그와 상태표를 함께 저장한다.
• 복구 관련 권한, retained backup 값, latest restorable time 조회 결과를 파일로 남긴다.

이렇게 적으면 deleting이 길어도 '아직 snapshot branch가 열려 있다' 또는 'replica promotion branch가 아직 event로 닫히지 않았다'라고 정확히 말할 수 있다. source와 replica를 따로 보면 긴장도 낮아진다. 한 branch가 정상 진행 중이라는 사실을 다른 branch와 분리해서 확인할 수 있기 때문이다.

실무 연결로는 delete 전 체크리스트 글, long deleting 상태 triage 글, final snapshot과 retained backups 글, latest restorable time 확인 글을 함께 두면 pre-delete에서 post-delete evidence까지 한 줄로 이어진다.

delete 대응표 첫 줄 예시

snapshot_branch=open
promotion_branch=open
source_status=deleting
replica_role=Replica
close_snapshot_branch_when=final_snapshot_complete
close_promotion_branch_when=standalone_role_confirmed

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

첫 공식 화면은 RDS 삭제 문서의 핵심 문장이다. 같은 리전에 read replica가 있으면 source DB instance 삭제 시 replica가 standalone으로 자동 승격된다고 적는다.

RDS 삭제 문서는 same-Region read replica가 source delete 뒤 standalone으로 승격된다고 설명한다.

즉 deleting 상태가 길어진다고 해서 replica 쪽 증거와 snapshot 쪽 증거를 한 줄로 뭉치면 안 된다. replica promotion은 별도 결과물이고, final snapshot 대기는 또 다른 경로다.

두 번째 자료는 AWS CLI delete-db-instance 설명이다. final snapshot 생성이 있든 없든 내부 작업이 끝날 때까지 status가 deleting으로 남을 수 있다고 적는다.

AWS CLI 문서는 final snapshot과 내부 정합성 작업이 끝날 때까지 deleting 상태가 유지될 수 있다고 설명한다.

이 문장을 보면 deleting이 곧 장애라고 단정하면 안 된다는 점이 드러난다. 문제는 deleting 상태 자체보다 어떤 증거가 아직 안 닫혔는지 분리해 보는 일이다.

세 번째 화면은 read replica promotion 기본 절차다. promotion은 별도 작업 단계와 완료 관찰 포인트를 가진다.

RDS read replica promotion 문서는 promotion이 독립된 단계이며 완료까지 시간이 걸릴 수 있음을 보여 준다.

따라서 source delete 이후 same-Region replica가 standalone이 되는지 보려면 snapshot 대기와 분리된 promotion evidence row가 필요하다. 이미 long deleting 상태 글을 읽었다면, 이번 글은 그 다음 단계인 증거 분리 메모다.

실무에서는 deleting 대응 메모를 두 줄로 나눠야 한다. 한 줄은 final snapshot과 source delete 진행을, 다른 한 줄은 replica promotion과 새 standalone 상태를 본다.

final snapshot 대기와 replica promotion 증거를 상태, 로그, 닫는 기준으로 나눈 표다.

이 표를 기준으로 적으면 source는 아직 deleting인데 replica는 이미 standalone으로 살아난 상황을 정상 경과로 읽을 수 있다. 반대로 snapshot이 끝났는데 replica 쪽 role 전환이 안 보이면 replica branch만 따로 좁히면 된다.

마지막 자료는 운영 메모 예시다. deleting 상태가 길어도 증거 줄을 나눠 적어 두면 '무엇이 아직 끝나지 않았는가'가 바로 보인다.

RDS deleting 상태에서 final snapshot과 replica promotion 증거를 따로 적는 메모 예시다.

이 정도 메모면 post 370의 pre-delete 체크리스트와 post 373의 after-click triage를 그대로 이어 받아, 그 다음 분기인 증거 정리 단계로 독자를 넘기기 좋다.

5. 주의사항과 리스크

첫 번째 리스크는 deleting을 단일 장애처럼 해석해 snapshot branch와 promotion branch를 동시에 흔드는 것이다. 두 번째 리스크는 replica role 전환을 확인하지 않고 source 상태만 본 채 delete가 끝났다고 판단하는 것이다. 세 번째 리스크는 후속 비용 정리 값을 branch evidence와 같은 줄에 섞는 것이다.

운영 전에 확인할 때는 최소한 snapshot id, source deleting status, replica role, promotion evidence 네 줄은 남기는 편이 좋다. 이 네 줄이 있어야 다음 담당자가 바로 어느 branch가 열려 있는지 알 수 있다.

• deleting은 하나의 branch가 아니라 여러 작업이 묶인 상태값이다.
• same-Region replica promotion은 별도 완료 증거가 필요하다.
• event log row와 상태표 row를 함께 남겨야 교대가 짧아진다.

6. 결론

RDS deleting 상태를 읽을 때는 source status 하나보다 증거 줄을 먼저 나누는 편이 맞다. final snapshot 대기와 replica promotion 증거를 다른 branch로 적어 두면, 길어진 deleting도 훨씬 짧게 설명할 수 있다.

• snapshot branch와 promotion branch를 먼저 나눈다.
• source deleting과 replica role 변화를 서로 다른 상태로 기록한다.
• 복구와 비용 판단 값은 shared row로만 남긴다.

7. 참고 링크

1. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html
2. https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html
3. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Promote.html
4. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html