로그 비용을 줄이려고 보존 기간부터 짧게 설정하면 장애 조사에 필요한 기록까지 잃을 수 있다. CloudWatch Logs에서는 보존 기간, 실제 삭제 시점, 요금에 반영되는 저장 상태를 구분해야 한다. 2026년 10월 27일 AWS 공식 문서를 확인했다.
보존 설정은 로그 그룹 단위다
AWS는 기본적으로 로그를 무기한 보관한다고 설명한다. 로그 그룹 안의 스트림들은 보존 설정을 공유한다. 따라서 같은 그룹에 들어 있는 운영·개발 기록의 필요 기간이 다르다면, 기간을 바꾸기 전에 영향을 받는 스트림부터 확인해야 한다. 로그 그룹과 보존 기간
30일과 7일의 용량 비교는 청구액 계산이 아니다
가상 예시로 매일 같은 크기의 원본 로그 1 GiB가 생성된다고 하자. 30일치 원본 데이터는 30 GiB, 7일치는 7 GiB로 기간에 해당하는 원본 합계 차이는 23 GiB다. 1 GiB는 1,073,741,824바이트다. 이미 충분한 기간 동안 일정하게 생성됐고, 기간 경계는 일 단위로 단순화했다.
이 값은 원본 로그량 비교다. 압축 후 저장량, 실제 storedBytes, 월 청구량이나 절감액이 아니다. 저장 이외의 수집·조회 등 비용과 서비스별 과금 조건도 따로 확인해야 한다. 통화·세금·약정 할인은 이 계산에 포함하지 않았다.
만료 표시와 실제 삭제는 다른 시점이다
CloudWatch Logs는 보존 기간에 도달한 이벤트를 즉시 삭제하지 않는다. AWS는 보통 이후 최대 72시간이 걸리지만 드물게 더 길어질 수 있다고 안내한다. 삭제 대상으로 표시된 이벤트는 실제 삭제 전이라도 보관 저장 요금에 더 이상 포함되지 않으며 storedBytes 값에서도 제외된다. 따라서 이 값이 줄었다고 모든 오래된 로그의 물리적 삭제가 끝났다고 단정하지 않는다. PutRetentionPolicy의 삭제와 저장 지표 설명
아직 지워지지 않은 만료 로그가 있는 상태에서 기간을 다시 늘리면 삭제 시점도 영향을 받는다. 보존 기간을 줄였다가 바로 늘리는 조작을 확실한 삭제 방법으로 취급하지 말아야 한다. 반대로 이미 삭제된 기록이 기간을 늘린다고 돌아온다고 기대해서도 안 된다.
변경 전에 팀이 답해야 할 세 가지 질문
- 누가 언제 과거 기록을 찾는가? 최근 장애 조사에서 실제로 필요했던 기간과 월간 작업의 추적 범위를 담당자에게 확인한다. 모든 그룹에 7일을 일괄 적용하는 대신 목적을 구분한다.
- 보존해야 할 자료가 다른 곳에 검증되어 있는가? 별도 보관이 필요하다면 복사 작업의 성공뿐 아니라 필요한 날짜의 기록을 실제로 조회할 수 있는지 확인한다. 보존 의무가 있는 자료는 조직의 담당 기준에 따른다.
- 무엇으로 완료를 판단할 것인가? 적용된 그룹과 보존일, 영향을 받는 기간, 삭제 대상 표시와 실제 조회 결과를 구분해 기록한다. 저장 지표 하나만으로 삭제 완료와 비용 절감을 동시에 선언하지 않는다.
이는 운영 판단을 위한 점검표이며 실제 사용자 계정의 보존 설정을 바꾸거나 기록을 삭제한 결과가 아니다. 설정 단축에는 데이터 손실이 따를 수 있으므로 대상과 필요한 보존 범위를 확정한 뒤 실행해야 한다.
AI 에이전트가 공식 문서와 가상 계산을 검토했다. 이미지는 설명용 도식이며 실제 계정 화면이나 실측 결과가 아니다.
서버 내부에 쌓이는 로그는 별도 보관 정책을 가질 수 있다. Docker 로그 회전과 적용 여부 점검도 함께 확인하자.