CloudWatch의 Cost explorer 분석하기

AWS CloudWatch는 단순한 로그 저장소가 아닙니다. 로그 수집, 메트릭 모니터링, 경보, 대시보드, 쿼리 분석까지 한 번에 제공하는 완전관리형 관제 플랫폼입니다. 하지만 그 강력함만큼, 잘못 사용하면 보이지 않는 비용 누수가 발생해 ‘비용폭탄’으로 다가올 수 있습니다.

예를 들어 로그 한 줄을 저장하는 것에서 끝나는 것이 아니라, 그 로그가 처리되고, 쿼리 분석되고, 지표로 변환되어 모니터링되며, 알람과 대시보드로 이어지는 다단계 과금 구조가 동시에 작동합니다. 특히 UsageType 항목에 따라 지표 수집량, 로그 처리량, API 호출, 대시보드 시간, 알람 평가 주기, 로그 스캔량 등 수많은 비용 요인이 누적되면, 작은 사용량이라도 큰 비용으로 이어질 수 있습니다.

따라서 CloudWatch를 비용 폭탄이 아닌, 효율적인 모니터링 투자 자산으로 만들기 위해서는, 비용 구조를 정확히 이해하고, 실제 사용 데이터를 기반으로 한 점검과 최적화가 필수입니다.

이 글에서는 AWS Cost Explorer를 활용해 CloudWatch의 비용 구조를 정확히 진단하고 분석하는 구체적인 방법을 단계별로 제공합니다. 이를 통해 현재 어떤 UsageType과 Resource가 과도한 비용을 유발하고 있는지 식별하고, 실제 절감으로 연결될 수 있는 개선 전략을 함께 고민할 수 있습니다.

CloudWatch의 현재 비용 진단하기

AWS CloudWatch의 비용을 정확하게 파악하려면 AWS Cost Explorer를 활용해 항목별 사용량과 비용을 세부적으로 분석해야 합니다. CloudWatch는 Logs, Metrics, Dashboards, Alarms, Insights 쿼리 등 다양한 구성 요소에 따라 별도로 과금되므로, 이를 구분해 확인해야 최적의 비용 절감 전략을 수립할 수 있습니다.

아래 단계에 따라 CloudWatch 비용을 체계적으로 추적하고 관리할 수 있습니다.

Cost Explorer 접속 방법

AWS 콘솔 상단 검색창에 Cost Explorer를 입력해 선택합니다.

‘Cost Explorer 열기’를 클릭해 비용 분석 도구에 진입합니다.

Group By 설정

CloudWatch 비용 분석의 정밀도를 높이기 위해 Group By 항목을 ‘UsageType’, ‘Resource’, ‘Linked Account’, ‘Region’ 등으로 설정해서 데이터를 세부적으로 추적할 수 있습니다.

먼저, UsageType 기준 분석은 Logs, Metrics, Dashboards, Alarms, Insights 쿼리, Events 등 각 기능별 비용 구조를 파악하는 데 필수적입니다. 이를 통해 어떤 기능이 가장 많은 비용을 차지하는지 빠르게 파악할 수 있습니다. UsageType별 상세 설명은 아래 섹션에서 이어서 정리하겠습니다.

그다음으로 Resource 기준 분석의 중요성이 매우 높습니다. Resource ID(예: 로그 그룹 이름, 지표 이름, 알람 이름)로 그룹화하여 비용을 분석하면 어떤 리소스가 비용을 과도하게 유발하고 있는지 구체적으로 확인할 수 있습니다.

예를 들어

특정 로그 그룹이 대량의 로그를 수집해 DataProcessing-Bytes 비용이 급증하는 경우

불필요하게 생성된 고해상도 지표가 MetricMonitorUsage 비용을 증가시키는 경우

사용하지 않는 알람이 지속적으로 비용을 유발하는 경우

이처럼 Resource 기반 분석은 CloudWatch 비용 절감 작업의 핵심 출발점이 됩니다.

마지막으로 Linked Account, Region으로 그룹화하면 계정별/리전별 비용 편차를 확인할 수 있어, 특정 프로젝트 또는 환경에서 과도하게 비용이 발생하는지 진단하고 책임 비용 구조 관리(Chargeback/Showback)를 연계할 수 있습니다.

필터링 설정

Group By는 비용 데이터를 원하는 기준(UsageType, Resource, Linked Account, Region 등)으로 묶어서 시각화하는 기능입니다. 예를 들어, UsageType으로 그룹화하면 Logs, Metrics, Dashboards, Alarms별로 비용 비중을 한눈에 파악할 수 있고, Resource ID로 그룹화하면 어떤 로그 그룹, 어떤 지표, 어떤 알람이 비용을 유발하는지 구체적으로 확인할 수 있습니다.

반면, Filter(필터링)는 비용 데이터를 특정 조건으로 제한하여 분석 범위를 좁히는 역할을 합니다.

예를 들어

Service = AWS CloudWatch로 설정해 CloudWatch 관련 비용만 확인

특정 기간, 특정 계정, 특정 리전에 대한 비용만 확인

UsageType = Logs만 선택해 로그 수집/저장/쿼리 비용만 분석

즉,

Group By = 데이터를 구분해 시각적으로 비교·분석하기 위한 기준

Filter = 분석 범위를 좁혀 불필요한 데이터를 제외하고 정확한 원인 분석을 위한 조건

이라고 이해하면 됩니다.

일별/월별 트렌드 분석 설정

기간은 Cost Explorer 상단 메뉴에서 이번 달, 지난 6개월, 사용자 지정 범위 등을 선택하여 분석합니다.

일별 분석: 특정 일자에 Logs Insights 쿼리 과도 실행, 로그 폭증, 알람 과다 생성 등 비용 급증 이벤트 탐지

월별 분석: CloudWatch 구성 요소별 장기 비용 추세, 특정 UsageType 및 프로젝트별 비용 편차 확인

예를 들어, 특정 시점 이후 DataProcessing-Bytes(로그 수집), DataScanned-Bytes(Logs Insights 쿼리) 항목에서 비용이 급증했다면, 애플리케이션의 로그 출력 증가, 잘못된 쿼리 반복 호출, VPC Flow Logs 설정 변경 등으로 인해 비용이 상승했을 가능성을 추적해볼 수 있습니다.

Cost Explorer 항목 설명

다음은 AWS Cost Explorer나 청구 내역에서 자주 확인할 수 있는 CloudWatch 및 관련 서비스의 Usage Type 항목들에 대한 설명입니다. 각 항목은 CloudWatch 또는 연계 서비스의 기능별 사용량 혹은 과금 대상을 구체적으로 나타내며, 비용 최적화 전략 수립에 중요한 기준이 됩니다.

APN2-DataProcessing-Bytes

이 항목은 CloudWatch Logs에서 수집된 로그를 처리하는 과정에서 발생하는 데이터 처리량(바이트 단위)에 대한 과금입니다. 예를 들어 VPC Flow Logs, Lambda 로그, ECS 로그 등 다양한 로그가 CloudWatch Logs로 수집될 때, AWS 내부에서 이를 구조화하고 색인화하는 데 필요한 처리 비용이 포함됩니다.

이 비용은 수집량과는 별도로 “처리량” 기준으로 과금됩니다. CloudWatch Logs가 로그를 수집한 후, 내부적으로 분석·색인·분리·파싱 등의 처리 작업을 수행합니다. 이 처리 작업 중 발생하는 내부 데이터 흐름량(압축 해제, 포맷 정규화 등)을 처리량(Bytes)으로 계산합니다.

로그 압축이나 필터링 없이 많은 양의 로그를 그대로 전송하면 불필요한 비용이 빠르게 증가할 수 있습니다. 로그의 종류에 따라 저장비용보다 처리비용이 더 많이 발생하는 경우도 있습니다.

APN2-VendedLog-Bytes

이 항목은 AWS에서 자동으로 제공하는 관리형 로그(Vended Logs)의 수집에 따른 비용입니다. 대표적으로 VPC Flow Logs, ELB Logs, CloudTrail Logs, Route 53 Logs와 같은 로그가 해당됩니다. 이 로그들은 사용자가 명시적으로 직접 전송하지 않아도, 서비스 설정만으로 CloudWatch에 자동 수집됩니다.

단, 전송되는 로그의 바이트 단위 저장량에 따라 요금이 발생하며, 저장기간과 저장형식(압축 여부)에 따라 최적화가 필요합니다.

APN2-CW:MetricMonitorUsage

이 항목은 CloudWatch Metrics 모니터링 비용, 즉 지표(metric) 단위의 수집 및 보존 비용에 대한 사용량을 나타냅니다. EC2, RDS, ELB 등 AWS 리소스는 기본적으로 1분 단위의 Standard Metrics를 제공합니다.

하지만 사용자 정의 지표(Custom Metrics) 또는 고해상도 지표(High-Resolution Metrics)를 추가 설정하면, 이 항목을 통해 과금이 발생합니다. 특히 고해상도 지표는 1초 단위 수집으로 높은 비용이 발생하므로 꼭 필요한 경우에만 설정하는 것이 좋습니다.

APN2-S3-Egress-Bytes

이 항목은 CloudWatch Logs 데이터를 Amazon S3로 전송할 때 발생하는 네트워크 전송(Egress) 요금입니다. 예를 들어, 로그 보존 정책에 따라 CloudWatch에서 S3로 로그를 아카이빙하거나, Athena 또는 Glue와 연동하기 위해 로그를 이동하는 경우 발생합니다.

S3는 저장 요금 외에도 리전 간 전송, 퍼블릭 전송 등 전송 유형에 따른 요금이 별도로 발생하기 때문에 이 항목을 확인하여 네트워크 비용이 갑자기 증가하는 경우를 점검해야 합니다.

APN2-CW:Requests

이 항목은 CloudWatch의 API 호출량에 따른 과금입니다. 예를 들어, PutMetricData, ListDashboards와 같은 API 호출이 여기에 포함됩니다. GetMetricData은 별도의 항목으로 계산됩니다. AWS Lambda, 배치 작업, 자동화 스크립트 등에서 CloudWatch API를 반복적으로 호출하면 이 항목의 요금이 누적될 수 있습니다. 자동화된 모니터링 또는 알림 시스템을 운영 중이라면, API 호출량이 과도하지 않도록 조정하는 것이 필요합니다.

DashboardsUsageHour-Basic

이 항목은 CloudWatch Basic Dashboard 사용 시간에 따른 과금입니다. CloudWatch에서는 사용자 맞춤형 대시보드를 통해 지표를 시각화할 수 있으며, 이 항목은 사용자가 매월 최대 50개를 사용하는 3개 이하의 기본 대시보드를 사용하면 무료로 제공됩니다. 지표 수를 초과하면 한개당 $3/월 과금됩니다.

DashboardsUsageHour

이 항목은 CloudWatch의 유료 대시보드 사용 시간에 따른 실제 과금 대상입니다. 기본 제공 대시보드(3개)를 초과하는 추가 대시보드는 대시보드 1개당 $3/월(시간 단위로 계산)으로 과금됩니다. 이 항목을 통해 “대시보드 몇 개를 초과해 유료 사용 중인지”, “활용률 대비 비용이 정당한지”를 파악할 수 있습니다. 활용도가 낮은 대시보드는 삭제하거나, 공유 목적을 분리해 다른 시각화 도구로 이전하는 것도 절감 전략이 될 수 있습니다.

APN2-CW:GMD-Metrics

GMD는 GetMetricData의 약자로, 사용자가 CloudWatch에서 GetMetricData API를 호출해 대량의 지표 데이터를 요청할 때 발생하는 과금 항목입니다. 보통 CloudWatch Dashboard, 외부 분석툴(Grafana, Datadog 등)과 연동, 또는 수동으로 메트릭을 수집·조회할 때 사용됩니다. 요청량에 따라 과금되며, 표준 지표 무료 제공 범위를 초과한 요청에 대해 유료로 전환됩니다.

APN2-CW:AlarmMonitorUsage

이는 CloudWatch Alarm 모니터링 기능에 대한 과금 항목입니다. 설정된 Alarm이 지표를 지속적으로 모니터링하고 조건을 평가하는 데 발생하는 리소스 사용량을 의미합니다. Alarm 수, 평가 빈도(주기), 모니터링 대상 지표의 해상도에 따라 비용이 결정됩니다.

APN2-TimedStorage-ByteHrs

이 항목은 CloudWatch Logs의 로그 저장소에 저장된 로그 데이터에 대한 저장 시간 기준 비용입니다. ByteHrs는 1시간 동안 저장된 바이트 수를 의미하며, 장기 보관할수록 누적 비용이 증가합니다. 예를 들어, 1GB의 로그를 하루(24시간) 저장하면 24GB-시간(byte-hrs)로 계산되며, 그에 따라 월별 GB 단가($0.03~$0.06/GB 기준 리전별 상이)로 과금됩니다. 저장 기간은 로그 그룹별로 지정 가능하며, 3일~무제한까지 설정할 수 있습니다.

APN2-DataScanned-Bytes

이 항목은 CloudWatch Logs Insights 또는 CloudWatch Logs 쿼리 기능을 사용할 때 스캔된 로그 데이터의 총량을 기준으로 과금됩니다. 예로 10GB 로그 파일에서 특정 키워드를 찾기 위해 전체 로그를 스캔한 경우, 10GB가 과금 대상이 됩니다. 현재 AWS는 Logs Insights 기준으로 $0.005/GB 스캔당 과금하고 있으며, 쿼리 최적화 또는 시간 범위 제한이 없을 경우 비용이 빠르게 누적될 수 있습니다.

APN2-Logs-LiveTail

이 항목은 CloudWatch Logs의 실시간 로그 스트리밍 기능(Live Tail) 사용 시 발생하는 과금입니다. Live Tail은 콘솔 상에서 로그 흐름을 실시간으로 확인할 수 있게 해주는 기능이며, 이 역시 내부적으로 지속적인 GetLogEvents API 호출과 로그 전송을 통해 작동합니다. 초 단위로 로그를 따라가는 구조이기 때문에 세션 길이와 동시 사용자 수에 따라 과금량이 커질 수 있습니다.

Cost Explorer 분석 예시

CloudWatch 사용량은 단순히 “로그를 얼마나 쌓았는가?”만으로 결정되지 않습니다. 아래는 CloudWatch를 Usage Type으로 그루핑한 실제 사례입니다.

2024-11 ~ 2025-01까지는 1,1001,300달러 수준에서 안정적으로 유지되다가, 2025-02에 세 배 이상 급증한 것을 확인할 수 있습니다.

2024-11: $1,155.69

2024-12: $1,312.43 (▲ +$156.74)

2025-01: $1,149.68 (▼ -$162.75)

2025-02: $3,828.61 (▲ +$2,678.93, 폭발적 증가)

특히 로그 처리 비용인 APN2-DataProcessing-Bytes 에 한해서만 증가했음을 확인할 수 있습니다. 이렇게 단계를 좁혀나가면서 비용이 이상적으로 급증한 부분을 좁혀나갈 수 있습니다.

반대로 AWS 서비스 로그 수집 비용인 APN2-VendedLog-Bytes 은 비용이 점점 감소하는 추세입니다. VPC Flow Logs, ELB Access Logs 등 AWS 서비스 로그 수집량이 줄었으며 이는 불필요하게 수집하고 있던 로그를 제외해 비용이 감소되었을 가능성이 높습니다.

그 외 지표 모니터링 비용인 APN2-CW:MetricMonitorUsage, API 요청 비용인 APN2-CW:Requests, 그리고 S3에서 CloudWatch로 내보내는 데이터 전송 비용인 APN2-S3-Egress-Bytes 3 항목이 이어서 주요 비요 항목으로 구성되고 있음을 확인할 수 있습니다.

이 경우 APN2-DataProcessing-Bytes의 급증 ($2,895 증가)했기 때문에 특정 서비스의 로그 레벨 조정여부나 불필요한 Subscription Filter의 활성화 여부를 확인하는 것이 좋습니다.

결론

CloudWatch는 강력한 모니터링 도구이지만, “어떻게 쓰느냐”에 따라 비용이 천차만별로 달라집니다.

이번 글을 통해 확인한 것처럼, CloudWatch 비용은 단순 로그 저장량이 아닌, DataProcessing-Bytes(로그 처리), MetricMonitorUsage(지표 모니터링), DataScanned-Bytes(쿼리 스캔량), AlarmMonitorUsage(알람 모니터링), DashboardsUsageHour(대시보드 사용시간) 등 다양한 UsageType에 의해 세분화되어 청구됩니다.

위에서 설명한 12가지 주요 Usage Type을 이해하고 분석하면, “어디에서 얼마를 쓰고 있는지”, “무엇을 줄이면 바로 비용이 떨어질지”가 명확히 보입니다. 또한, Resource ID 기반으로 분석하면 “어떤 로그 그룹, 어떤 지표, 어떤 알람”이 비용을 유발하고 있는지 정확히 파악할 수 있어 불필요한 비용을 줄이는 핵심 지표가 됩니다.

CloudWatch 비용 최적화는 크게 두 가지로 요약됩니다.

비용 구조의 정확한 이해와 분석 (UsageType/Resource/Region/Account별 분석)

비용 절감을 위한 구조적 개선 (불필요한 로그/지표/알람 제거, 구독 필터 정리, 고해상도 설정 최적화)

CloudWatch는 무심코 쓰면 비용이 새어나가지만, 정밀하게 관리하면 강력한 모니터링과 비용 최적화를 동시에 달성할 수 있습니다.