CloudFront 배포를 정리하려는데 '삭제'가 바로 되지 않는다. 배포를 비활성화하는 단계가 빠졌을 수 있다. CloudFront는 사용자의 요청을 여러 엣지 위치에서 받는 배포 서비스이므로, 단순히 목록에서 한 줄을 지우는 작업으로 생각하면 순서가 헷갈린다.
CloudFront 배포는 왜 바로 삭제하지 못할까?
배포가 활성화된 동안에는 요청을 처리할 수 있다. CloudFront는 삭제 전에 배포를 비활성화하도록 요구한다. 삭제를 누르기 전에 서비스 연결을 정리하고, 비활성화 상태가 반영됐는지 확인해야 한다. AWS의 배포 삭제 안내도 이 순서와 삭제 후 복구 불가를 명시한다.
예를 들어 테스트 사이트 www.example.test가 한 배포를 가리킨다고 하자. 작업은 단순히 '삭제 버튼을 두 번 누른다'가 아니다.
| 시점 | 배포 상태 | 먼저 확인할 일 |
|---|---|---|
| 사용 중 | 활성 | 도메인과 원본 연결 확인 |
| 정리 중 | 비활성화 요청·전파 | 새 요청의 목적지와 상태 확인 |
| 정리 완료 | 비활성 | 삭제할 배포를 다시 식별 |
| 삭제 뒤 | 없음 | 참조·설정·비용 항목 점검 |
그림의 두 화살표가 분리된 이유도 여기에 있다. 비활성화는 트래픽 처리 상태를 바꾸고, 삭제는 배포 설정 자체를 없앤다.
비활성화 뒤에도 삭제할 수 없다면?
먼저 배포 목록을 새로 고침해 대상의 상태를 확인한다. 방금 비활성화했다면 설정 변경이 반영 중일 수 있으므로, 상태가 끝나기 전에 삭제가 막혔다고 다른 배포를 선택하지 말자. 대상 ID가 맞는지와 삭제 권한도 확인한다. 비활성화와 삭제는 서로 다른 작업이며 권한도 다를 수 있다. 정액 요금제에 가입한 배포라면 비활성화만으로 삭제할 수 없고, 요금제 해지 후 결제 주기가 끝날 때까지 기다려야 할 수도 있다. 오류 문구가 요금제를 가리키는지 먼저 읽자.
도메인이 해당 배포를 계속 가리킨다면 비활성화만 해도 사용자 요청이 실패할 수 있다. DNS와 원본 연결을 먼저 파악하고, 대체 경로가 필요하면 준비한 다음 트래픽을 전환한다. 특히 한 배포를 여러 환경에서 공유하는지 확인하지 않은 채 테스트용이라고 단정하면 위험하다.
운영에서 삭제와 캐시 문제를 어떻게 구분할까?
오래된 파일이 보이는 문제는 배포 자체를 삭제할 이유가 아니다. 이 글의 절차는 더 이상 쓰지 않는 배포를 제거할 때의 이야기다. 캐시 갱신 문제라면 사용 중인 배포를 유지하면서 원본 파일·요청 경로·캐시 정책을 따로 진단해야 한다. 문제의 대상이 '파일 한 개'인지 '배포 전체'인지 먼저 구분하자.
삭제 전에는 배포 ID, 연결 도메인, 원본, 대체 경로와 되돌릴 수 없는 범위를 기록해 두면 좋다.
핵심 요약
CloudFront 배포 삭제는 먼저 비활성화하고, 그 상태가 반영된 뒤 대상 배포를 다시 확인하는 순서다. 사용 중인 도메인·원본을 정리하지 않고 비활성화하면 요청이 끊길 수 있다. 캐시 문제와 배포 제거를 혼동하지 말자.
