← 기술 블로그

CloudWatch 청구서가 점점 비싸진다면? Logs와 Metrics 비용 절감 실전 가이드

CloudWatch는 쉽게 ‘기본 옵저버빌리티 도구’에서 ‘청구서 블랙홀’로 변하곤 합니다. 특히 컨테이너, 마이크로서비스, Lambda, API Gateway, VPC Flow Logs를 모두 연동하고 나면, Logs ingest, 로그 보존, Custom Metrics, Alarms, Dashboards 비용이 함께 급증합니다. 비용을 절감하는 첫걸음은 모니터링을 무작정 삭제하는 것이 아니라, 돈이 어디에 쓰이고 있는지 정확히 분석하는 것입니다.

아래 요금은 us-east-1 리전의 일반적인 공개 요금을 기준으로 한 예시이며, 실제 요금은 현재 사용 중인 AWS 리전의 기준을 따릅니다. CloudWatch Logs의 표준 로그 수집은 일반적으로 약 $0.50/GB, 로그 아카이빙은 약 $0.03/GB-month입니다. Logs Insights 쿼리는 보통 약 $0.005/GB scanned이며, Custom Metrics는 처음 10,000개까지 일반적으로 약 $0.30/metric-month입니다. 표준 해상도 alarm은 보통 약 $0.10/alarm metric-month이고, 사용자 지정 dashboard는 약 $3/dashboard-month 수준입니다.

먼저 분석하기: Logs가 비쌀까, Metrics가 비쌀까?

Cost Explorer에서 Service 항목을 CloudWatch로 선택한 후, Usage type으로 세분화하여 분석합니다. 주로 비용이 많이 발생하는 항목은 다음과 같습니다.

  • DataProcessing-Bytes: 로그 수집.
  • TimedStorage-ByteHrs: 로그 보존.
  • MetricMonitorUsage: 사용자 지정 지표.
  • AlarmMonitorUsage: 경보.
  • GMD-Metrics 또는 API 요청: GetMetricData 쿼리.

많은 팀들이 dashboard 비용이 많이 나온다고 오해하지만, 실제로는 대개 로그 수집 비용이나 고기수 custom metrics 비용이 원인인 경우가 많습니다.

Logs 비용 절감 1: 보존 주기 설정하기

CloudWatch Log Group은 기본적으로 무기한 보존으로 설정되어 있을 수 있습니다. 애플리케이션 로그의 경우, 대부분의 팀은 7일, 14일, 30일 또는 90일 정도의 온라인 검색 기간만 필요로 합니다.

일괄 조회하기:

aws logs describe-log-groups \
  --query 'logGroups[*].[logGroupName,retentionInDays,storedBytes]' \
  --output table

보존 주기 설정하기:

aws logs put-retention-policy \
  --log-group-name /aws/ecs/prod-api \
  --retention-in-days 30

로그 유형별로 계층화하여 관리하는 것을 권장합니다. 프로덕션 에러 로그는 90일, 일반 애플리케이션 로그는 14일에서 30일, 디버그 로그는 3일에서 7일로 설정하고, 감사 및 컴플라이언스 로그는 S3로 전환하여 장기 보존합니다.

Logs 비용 절감 2: 수집 후 쿼리가 아닌, 수집 전에 필터링하기

CloudWatch Logs에서 가장 비용이 많이 드는 부분은 일반적으로 ingest입니다. 로그가 이미 CloudWatch에 들어온 후에 subscription filter나 Logs Insights로 필터링해 봐야 수집 비용을 줄일 수는 없습니다.

따라서 애플리케이션, sidecar, Fluent Bit, OpenTelemetry Collector 단계에서 미리 필터링해야 합니다.

[FILTER]
    Name   grep
    Match  app.*
    Exclude log ^.*healthcheck.*$

헬스 체크, 정적 리소스 200 응답, 중복 디버그 로그, 지나치게 긴 페이로드와 같이 빈도는 높지만 가치가 낮은 로그는 우선적으로 제외 처리합니다. 프로덕션 환경의 기본 로그 레벨은 INFO로 설정하고, 장애 대응 시에만 일시적으로 DEBUG로 변경하는 것이 상시 전체 디버그 로그를 남기는 것보다 훨씬 경제적입니다.

Logs 비용 절감 3: 미사용 Log Group 정리하기

Lambda, ECS, API Gateway, Step Functions 리소스가 삭제된 후에도 log group이 자동으로 삭제되지 않는 경우가 있습니다. 오랫동안 새로운 쓰기 작업이 발생하지 않은 그룹을 아래와 같이 찾아낼 수 있습니다.

aws logs describe-log-groups \
  --query 'logGroups[?storedBytes>`0`].[logGroupName,storedBytes,retentionInDays]' \
  --output table

그리고 lastEventTimestamp를 함께 확인하여 현재 여전히 사용 중인지 체크합니다. 삭제하기 전에 S3로 먼저 내보내기해 두는 것이 컴플라이언스 데이터의 오삭제를 방지하는 안전한 방법입니다.

Logs 비용 절감 4: 고트래픽 서비스 로그 연동에 신중하기

VPC Flow Logs, ALB Access Logs, WAF Logs, CloudFront Logs 등은 매우 방대할 수 있습니다. 기본값으로 이 로그들을 모두 CloudWatch에 전송하지 않도록 주의해야 합니다.

더 권장되는 방식은 다음과 같습니다.

  • 단기 장애 대응용 로그만 CloudWatch로 전송합니다.
  • 장기 액세스 로그는 S3로 저장합니다.
  • Athena/임프레션 등을 통해 이력 데이터를 조회합니다.
  • VPC Flow Logs의 경우 필요한 필드만 샘플링하거나, 핵심 subnet/ENI에 대해서만 활성화합니다.

S3 + Athena의 대화형 조회 환경은 CloudWatch Logs보다 다소 불편할 수 있으나, 장기 보존 비용을 크게 낮출 수 있어 빈도가 낮은 보안 감사 쿼리에 특히 적합합니다.

Logs 비용 절감 5: 보완책으로서 대체 솔루션 검토하기

만약 주된 문제 원인이 CloudWatch Logs의 수집 및 보관 비용이라면, 대체 솔루션을 검토해 볼 수 있습니다. 예를 들어 S4 Logs는 CloudWatch Logs의 비용 최적화에 중점을 둔 대체 제품으로, 로그 양이 많고 보존 주기가 길며 CloudWatch 고유의 쿼리 기능이 반드시 필수적이지는 않은 시나리오에 적합합니다.

다만, 이를 CloudWatch의 무조건적인 대체 수단으로 생각해서는 안 됩니다. 팀이 Logs Insights, CloudWatch Alarm 및 기존의 운영 프로세스에 크게 의존하고 있다면 마이그레이션 비용도 함께 고려해야 합니다. 보다 실무적인 방법은 트래픽은 높지만 위험도가 낮은 log group 하나를 선정해 파일럿 테스트를 진행한 뒤, 비용 계산 도구를 통해 실제 절감 범위를 추정해 보는 것입니다.

Metrics 비용 절감 1: 카디널리티(Cardinality) 제어하기

Custom Metrics 비용 상승의 주범은 고기수 지표입니다. CloudWatch는 namespace, metric name, dimension의 조합을 기준으로 요금을 책정합니다. 따라서 아래와 같은 차원 설계는 매우 위험합니다.

MetricName=Latency
Dimensions=service, endpoint, customer_id, pod_id, request_id

만약 customer_id가 10,000개이고, endpoint가 50개라면 이론적인 고유 조합 수가 순식간에 늘어납니다. 더 안정적인 방법은 장애 해결과 경보 알림에 실제로 꼭 필요한 차원만 남겨두는 것입니다.

MetricName=LatencyP95
Dimensions=service, endpoint, environment

pod_id, request_id와 같은 고기수 필드는 CloudWatch custom metric의 차원으로 설정하기보다 로그나 추적 데이터에 포함시키는 것이 훨씬 적절합니다.

Metrics 비용 절감 2: 집계 후 지표 전송하기

모든 인스턴스, 테넌트, API 엔드포인트마다 직접 PutMetricData를 호출하지 마세요. 애플리케이션이나 수집기 레벨에서 사전에 데이터를 집계하여, 예컨대 60초마다 한 번씩 p50/p95/p99, count, error_count 등의 값을 전송하는 것이 좋습니다.

PutMetricData API 호출 자체도 비용을 유발하며, 일반적으로 약 $0.01/1,000 requests 수준입니다. 전송 주기를 10초에서 60초로 변경하더라도 대부분의 비즈니스 경보에는 영향을 주지 않으면서 API 요청 횟수와 수집되는 지표 수를 크게 줄일 수 있습니다.

Metrics 비용 절감 3: EMF(Embedded Metric Format) 올바르게 사용하기

Embedded Metric Format(EMF)는 구조화된 로그에서 지표를 추출할 수 있어 로그와 메트릭 데이터를 매끄럽게 연결하기에 적합합니다. 그러나 EMF가 결코 공짜 지표는 아닙니다. 여전히 로그 수집 비용이 발생할 뿐만 아니라 custom metrics 비용이 추가로 청구될 수 있습니다.

EMF를 사용할 때는 아래 사항에 유의해야 합니다.

  • user_id, order_id, container_id 등의 값을 dimensions에 넣지 마세요.
  • namespace 개수를 제어하세요.
  • 호출 빈도가 높은 이벤트는 사전에 집계한 후 EMF 포맷으로 출력하세요.
  • 실제로 얼마나 많은 unique metrics가 생성되고 있는지 주기적으로 모니터링하세요.

Metrics 비용 절감 4: 경보(Alarm) 및 Dashboard 거버넌스(관리) 수행하기

경보 설정에서 흔히 발생하는 실수는 모든 차원의 조합마다 각각 alarm을 생성하여 결과적으로 수천 개의 alarm이 만들어지는 것입니다. 다음의 방식을 추천합니다.

  • 핵심 SLO에 대해서만 소수의 집계 경보를 생성합니다.
  • 상세한 이슈 분석은 dashboard나 로그 검색을 활용합니다.
  • 서로 관련된 alarm들은 composite alarm(복합 경보)으로 묶어 알림 피로를 줄입니다.
  • 아무도 보지 않는 dashboard는 삭제합니다.

Dashboard 자체의 단가는 그리 높지 않을 수 있으나, 페이지가 빈번하게 자동 새로고침될 경우 특히 모니터링용 대형 스크린이나 폴링 시스템에서 GetMetricData API 호출 비용이 대량으로 누적될 수 있습니다.

S4 Metrics는 언제 고려해야 할까?

만약 CloudWatch Custom Metrics의 주된 문제가 고기수(High-Cardinality)로 인한 비용 상승이고, 비즈니스상 정밀한 단위의 지표 보존이 꼭 필요한 상황이라면 S4 Metrics 같은 대체 솔루션을 검토해 볼 수 있습니다. 이 솔루션은 CloudWatch 사용자 지정 지표의 cardinality 비용을 낮추는 데 초점이 맞춰져 있으며, 전체 옵저버빌리티 시스템을 완전히 대체하는 목적이 아닙니다. 비핵심 namespace 또는 비용이 가장 많이 발생하는 지표 그룹부터 단계적으로 A/B 테스트를 진행해 보는 것을 권장합니다.

실행 가능한 7일 실천 계획

1일 차: Cost Explorer를 사용하여 CloudWatch 비용의 상위 usage type을 찾아냅니다. 2일 차: 모든 log group of 크기와 보존 주기(retention)를 나열합니다. 3일 차: 기본 무기한 보존 설정을 로그 유형에 따라 7/14/30/90일로 계층화하여 변경합니다. 4일 차: Fluent Bit 또는 OTel Collector 단에서 가치가 낮은 로그를 사전에 필터링합니다. 5일 차: 장기 보존이 필요한 로그는 S3 + Athena 조합으로 마이그레이션합니다. 6일 차: custom metrics 목록을 추출하고 고기수 차원을 정리합니다. 7일 차: S4 Logs나 S4 Metrics 등 대체 솔루션의 파일럿 도입 가치를 평가합니다.

CloudWatch 비용 최적화의 원칙은 매우 단순합니다. 가치가 높은 시그널은 남기고 가치가 낮은 노이즈는 수집하지 않는 것이며, 장기 보관이 필요한 데이터는 그에 어울리는 최적의 저장소 시스템으로 넘기는 것입니다.

고지: 본 글의 작성자는 abyo software(AWS Marketplace의 비용 최적화 솔루션인 S4 개발사) 소속입니다.

무료 도구로 AWS 절감 여력을 추정해 보세요 →