CloudWatch Logs 요금 절감: 저장이 아니라 수집이 본체입니다
CloudWatch 요금이 커졌을 때 범인은 거의 항상 Logs이고, Logs 안에서도 수집(ingestion)입니다. 결론을 먼저 적으면, 수집 요금이 GB당 약 $0.50으로 저장 요금(GB-월당 약 $0.03)의 17배이므로, 절감은 오래된 로그 삭제가 아니라 들어오는 양을 줄이는 데서 나옵니다. 보존 기간을 아무리 줄여도 이미 수집된 GB의 $0.50은 돌려받지 못합니다. 로그 레벨 조정, Infrequent Access 클래스, 목적지 변경이 실제로 돈이 되는 순서입니다. 요금이 갑자기 늘어난 경우의 전체 점검은 원인 10가지에서 다뤘습니다. 요금은 us-east-1 기준입니다.
한눈에 보는 요금 구조 #
| 항목 | 단가 | 비고 |
|---|---|---|
| 수집 (Standard) | 약 $0.50/GB | 월 5GB 무료, 볼륨 구간별 인하 (10TB 초과분부터 $0.25 이하) |
| 수집 (Infrequent Access) | 약 $0.25/GB | Standard의 절반, 실시간 기능 제약 |
| 저장 | 약 $0.03/GB-월 | 압축 후 크기 기준 |
| Logs Insights 쿼리 | 약 $0.005/스캔 GB | 스캔 범위에 비례 |
| S3 내보내기·구독 전달 | 별도 전달 요금 | 대량 보관은 S3 쪽이 저렴 |
수집이 본체인 이유 #
하루 10GB를 수집하는 서비스를 놓고 계산하면 구조가 바로 보입니다. 월 수집 300GB에 약 $150, 저장은 3개월 치를 쌓아 둬도 월 $27 수준입니다. 보존 기간을 1년에서 1개월로 줄이면 저장 요금은 몇 달러 단위로 줄지만, 로그 레벨을 조정해 수집량을 30% 줄이면 매달 $45가 사라집니다. 절감 대상은 축적분이 아니라 유입량입니다.
그런데도 보존 기간 설정은 그것대로 해 둬야 합니다. 로그 그룹의 기본 보존은 무기한이라, 방치된 로그 그룹은 저장 요금이 조용히 우상향합니다. 계정 전체 로그 그룹에 보존 기간(프로덕션 30〜90일, 감사 로그는 요건대로)을 일괄 설정하는 것은 상시 점검 목록에 넣어 둘 기본기입니다. 장기 보관 요건이 있으면 CloudWatch에 쌓지 말고 S3로 내보내 아카이브 클래스로 내리는 쪽이 자릿수로 쌉니다.
수집량이 큰 조직에는 볼륨 구간 인하가 적용됩니다. Standard 기준 월 10TB까지 $0.50, 그다음 20TB는 $0.25, 그 위 구간은 $0.10, $0.05까지 내려갑니다. 월 수십 TB를 넣는 규모라면 실효 단가가 절반 아래로 떨어지므로, 단가 협상 없이도 청구서의 기울기가 완만해집니다.
Infrequent Access와 인텔리전트 티어링 #
로그 클래스를 Infrequent Access(IA)로 만들면 수집 단가가 절반($0.25/GB)이 됩니다. 대가는 실시간 기능입니다. IA 로그 그룹은 Live Tail, 메트릭 필터, 구독 필터, 알람 연동 같은 실시간 처리를 쓸 수 없고, Logs Insights 조회는 됩니다. 즉 알람의 근거가 되는 로그는 Standard, 문제가 났을 때 검색해 보는 용도의 로그는 IA라는 분리가 기준입니다. 디버그 로그, 접근 로그, 배치 작업 로그가 IA의 전형적인 대상입니다.
2026년 7월에는 인텔리전트 티어링이 추가되어, 액세스 패턴에 따라 Standard, Infrequent Access, Archive Instant Access 세 계층으로 자동 분류됩니다. 로그 그룹마다 클래스를 수동으로 정하기 어려운 규모라면 이 기능이 분류 작업 자체를 대신해 줍니다. 신설 기능이므로 요건(대상 로그 그룹, 계층 조건)은 적용 전에 문서로 확인합니다.
Lambda는 별도의 선택지가 하나 더 있습니다. 2025년부터 Lambda 로그에 구간별 인하 요금이 적용되고, 로그 목적지를 CloudWatch 외에 S3나 Data Firehose로 직접 지정할 수 있습니다. 호출량이 많은 함수의 로그를 분석 파이프라인(S3 + Athena 등)으로 바로 보내면 CloudWatch 수집 요금을 통과하지 않습니다. 로그를 CloudWatch에서 봐야 할 이유가 없는 함수부터 옮기는 것이 순서입니다.
수집량 자체를 줄이는 기본기 #
- 로그 레벨: 프로덕션에서 DEBUG를 상시로 켜 두는 것이 최대 낭비 패턴입니다. 평시 INFO, 조사 시에만 레벨을 내리는 운영으로 바꾸면 그 자체로 수십 %가 줄어드는 경우가 많습니다.
- 구조화와 중복 제거: JSON 구조화 로깅으로 한 이벤트를 한 줄에 담고, 스택 트레이스 중복 출력이나 요청 전체 본문 로깅 같은 대용량 패턴을 걷어냅니다.
- 샘플링: 전 요청 로깅이 필요 없는 고트래픽 경로(헬스 체크, 정적 자산)는 제외하거나 샘플링합니다. ALB·VPC Flow Logs 같은 인프라 로그도 필요한 필드와 대상만 남기도록 설정할 수 있습니다.
- Insights 쿼리 습관: 쿼리 요금은 스캔 GB에 비례하므로, 시간 범위를 좁히고 로그 그룹을 특정하는 습관이 조회 비용을 줄입니다.
절감 순서 #
- 어느 로그 그룹이 얼마나 넣는지부터 봅니다: Cost Explorer와 로그 그룹별 IncomingBytes 메트릭으로 수집량 상위를 찾습니다. 상위 몇 개가 대부분을 차지하는 분포가 보통입니다.
- 보존 기간을 일괄 설정합니다: 무기한 보존을 제거합니다. 저장 요금은 크지 않지만 방치하면 계속 자랍니다. 장기 보관은 S3로 내보냅니다.
- 수집량 상위의 레벨·중복·샘플링을 정리합니다: 유입을 줄이는 것이 단가 구조상 가장 큰 절감입니다.
- 실시간 기능이 필요 없는 로그를 IA로 내립니다: 알람·메트릭 필터 의존 여부를 확인하고, 검색용 로그는 절반 단가로 옮깁니다. 규모가 크면 인텔리전트 티어링으로 자동화합니다.
- Lambda 대량 로그는 목적지를 바꿉니다: CloudWatch를 경유할 이유가 없는 함수 로그는 S3·Firehose 직송으로 수집 요금 자체를 우회합니다.
정리 #
- CloudWatch Logs의 본체는 수집 요금(GB당 약 $0.50)입니다. 저장(GB-월 약 $0.03)의 17배이므로, 절감은 유입량 축소에서 나옵니다.
- 보존 기간 무기한이 기본값이라는 점은 별도의 함정입니다. 전 로그 그룹에 보존 기간을 설정하고 장기 보관은 S3로 내립니다.
- IA 클래스는 수집 단가가 절반입니다. 알람 근거 로그는 Standard, 검색용 로그는 IA로 나누고, 규모가 크면 2026년 도입된 인텔리전트 티어링으로 자동 분류합니다.
- Lambda 로그는 S3·Firehose 직송이 가능해져 CloudWatch 수집 요금을 우회할 수 있습니다. 호출량 많은 함수부터 검토합니다.
- DEBUG 상시 출력, 스택 트레이스 중복, 헬스 체크 전량 로깅이 3대 낭비 패턴입니다. 수집량 상위 로그 그룹에서 먼저 걷어냅니다.