CloudWatch Logs 보존 기간을 줄이는 작업은 표시 옵션 변경이 아니라 오래된 로그의 삭제로 이어질 수 있는 변경입니다. 로그 그룹과 필요한 보존 기간을 확인하고, 이미 삭제된 로그는 기간을 다시 늘려도 돌아오지 않는다는 점부터 검토하세요.
적용 환경: Amazon CloudWatch Logs 로그 그룹; 조직의 보존 의무와 별도 백업 여부는 담당자가 확인. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.
1. 원인: 보존 기준과 삭제 완료 시각을 혼동
한 로그 그룹 안의 스트림들은 보존 설정을 공유합니다. 기본적으로 로그는 무기한 보존되며, 보존 설정을 바꾸면 기준을 지난 이벤트는 삭제 대상으로 표시됩니다. 실제 삭제에는 통상 최대 72시간이 걸리며 드물게 더 오래 걸릴 수 있습니다.
삭제 표시된 이벤트는 보관 저장 비용과 storedBytes 계산에서 제외됩니다. 화면에 남아 보이는 것, 비용 집계, 원문 삭제 완료는 같은 순간의 지표가 아닐 수 있습니다.
2. 해결: 변경 전 체크리스트
| 항목 | 확인할 내용 |
| 그룹과 리전 | 다른 환경의 그룹을 선택하지 않았는가 |
| 필요한 기간 | 장애 조사·감사·업무 요구를 만족하는가 |
| 별도 보존 | 필요 원문을 실제로 읽을 수 있는가 |
| 변경 기록 | 이전 값·새 값·담당자·적용 시각은 무엇인가 |
특정 일수가 모든 서비스에 정답은 아닙니다. 애플리케이션 담당자에게 재현에 필요한 시간 범위를 확인하고, 필요한 자료를 별도로 보존했다면 단순 내보내기 시작 표시가 아니라 실제 파일과 읽기 가능 여부를

확인하세요.
3. 확인: 짧은 기간의 시험 그룹에서 검증
민감 정보가 없는 시험 로그를 사용해 변경 전후의 가장 오래된 이벤트와 조회 범위를 기록합니다. 기간을 단축한 직후 사라지지 않았다는 이유로 같은 설정을 계속 반복하지 마세요. 확인 시각과 이벤트 시각을 함께 남겨 지연을 판단합니다.
운영 그룹에 적용하기 전 기존 값을 기록하고 승인된 범위를 정합니다. 기간을 늘리면 앞으로 보존되는 범위는 달라질 수 있지만 삭제 완료된 원문을 복구하는 백업 기능은 아닙니다.
4. 주의와 FAQ
보존 기간만 줄이면 로그 비용이 모두 없어지나요? 수집량과 조회 등 다른 사용 항목도 있으므로 저장 기간 하나로 전체 비용을 단정할 수 없습니다.
어떤 로그를 남겨야 하나요? 서비스 장애 조사와 조직 정책에 필요한 자료를 담당자와 확인해야 합니다. 이 글은 개별 조직의 법적 보존 기간을 정하는 안내가 아닙니다.
공식 출처와 관련 글
'소프트웨어개발' 카테고리의 다른 글
| S3 파일은 없는데 용량이 남을 때: 미완료 멀티파트 업로드 점검 (0) | 2026.10.27 |
|---|---|
| systemd 설정이 반영되지 않을 때: daemon-reload·reload·restart 구분 (0) | 2026.10.26 |
| Git 커밋을 잃어버렸을 때: reflog 확인 후 복구 브랜치부터 만드는 순서 (0) | 2026.10.26 |