CloudWatch 도쿄 요금: 메트릭·로그·조회 비용이 늘어나는 이유
도쿄 CloudWatch 요금을 메트릭 시계열, 로그 수집·보존·조회로 나누어 계산하고 월간 예제와 UsageType으로 비용 증가 원인을 찾습니다.
CloudWatch 청구액이 늘었다면 가장 많이 증가한 항목부터 찾는 편이 빠릅니다. 로그 수집 비용이 큰데 보존 기간만 줄이면 저장 비용만 낮아집니다. 커스텀 메트릭이 원인이라면 대시보드 몇 개를 지워도 큰 차이가 없습니다.
도쿄 리전의 Standard 로그 수집은 US$0.76/GB, 저장은 US$0.033/GB-month, 여기서 다루는 Logs Insights는 스캔한 데이터에 대해 US$0.0076/GB입니다. 모두 로그 비용이지만 줄이는 방법은 다릅니다. AWS 안에서 필요한 모니터링을 이미 하고 있다면, 플랫폼을 바꾸기 전에 수집·보존·조회 범위를 정리하는 것이 합리적입니다.
Guance 편집팀. 2026년 10월 27일 AWS 도쿄 공개 단가를 확인했습니다. 아래는 USD 단가와 가정한 사용량으로 계산한 예제이며, 고객 청구서나 성능 실측 결과가 아닙니다.
도쿄 단가와 무료 사용량
대상 리전은 ap-northeast-1입니다. 2026년 10월 7일 AWS 가격표에서 아래 단가를 확인할 수 있습니다. 추가로 활성화한 CloudWatch 기능은 별도 요금이 붙습니다.
| 항목 | 공개 USD 단가 | 집계할 수량 |
|---|---|---|
| 사용자 지정 메트릭: 첫 10,000개 | 0.30 | 메트릭-월 |
| 다음 240,000개 | 0.10 | 해당 구간의 메트릭-월 |
| 다음 750,000개 | 0.05 | 해당 구간의 메트릭-월 |
| 1,000,000개 초과 | 0.02 | 해당 구간의 메트릭-월 |
| 일반 API | 1,000건당 0.01 | 요청 수 |
| GetMetricData | 1,000개당 0.01 | API 호출 수가 아닌 요청 메트릭 수 |
| Metric Streams | 1,000회당 0.003 | 메트릭 업데이트 수 |
| 표준 해상도 알람 | 0.10 | 알람 메트릭-월 |
| 고해상도 알람 | 0.30 | 알람 메트릭-월 |
| 복합 알람 | 0.50 | 복합 알람-월 |
| 유료 Basic 사용자 지정 대시보드 | 3.00 | 대시보드-월, location=Any SKU |
| Standard 로그 수집 | 0.76 | 수집 GB |
| 로그 저장 | 0.033 | GB-month |
| Logs Insights | 0.0076 | 스캔 GB |
| Live Tail | 0.01 | 유료 분 |
무료 사용량도 항목별로 적용됩니다. 일반 API 월 100만 무료 요청에는 GetMetricData, GetInsightRuleReport, GetMetricWidgetImage가 포함되지 않습니다. 무료 알람 메트릭 10개는 메트릭을 직접 지정하는 표준 해상도 알람에 적용되며, Metrics Insights 쿼리 알람·고해상도 알람·복합 알람은 별도로 계산합니다. 무료 사용량 적용 조건
Basic 사용자 지정 대시보드는 각각 50개 이하의 메트릭을 참조하면 3개까지 무료입니다. 50개를 넘는 Extended 대시보드도 월 US$3.00이지만 이 무료 혜택은 적용되지 않습니다. 자동 대시보드는 무료입니다. 유료 대시보드 SKU는 location=Any이므로 도쿄 전용 항목이 아닌 전체 가격표에 있습니다.
Standard 로그 수집·저장·Logs Insights에는 각각 Global 0–5 GB 무료 SKU가 있습니다. Live Tail은 월 1,800분이 무료입니다. 아래 계산에는 AWS가 무료 사용량을 배분한 뒤의 과금 수량을 넣으며 크레딧, 세금, 계약 조정은 별도로 처리합니다.
메트릭 이름이 적어도 시계열은 많아질 수 있다
CloudWatch는 이름, 네임스페이스, 차원 조합으로 메트릭을 구분합니다. 이름이 모두 request_count여도 서비스, 엔드포인트, 상태 값이 달라지면 서로 다른 시계열이 됩니다. 메트릭과 차원
예를 들어 서비스 20개가 각각 엔드포인트 10개와 상태 5개의 조합을 모두 전송하면 이름 하나에서 시계열 1,000개가 생깁니다. 실제로 전송하지 않는 조합은 빠집니다. 이 가정만으로도 이름만 세면 부족한 이유를 알 수 있습니다. 계속 늘어나는 요청 ID를 차원으로 넣기 전에는 그 단위로 집계할 필요가 있는지부터 판단하는 편이 좋습니다.
구간 단가는 전체 사용량이 아니라 각 구간의 수량에 적용됩니다. 12,000 메트릭-월이면 처음 10,000개에 US$0.30, 나머지 2,000개에 US$0.10을 적용해 메트릭 비용은 US$3,200입니다.
M = 과금 사용자 지정 메트릭-월
metric_cost(M)
= min(M, 10,000) * 0.30
+ min(max(M - 10,000, 0), 240,000) * 0.10
+ min(max(M - 250,000, 0), 750,000) * 0.05
+ max(M - 1,000,000, 0) * 0.02
예상 소계
= metric_cost(M)
+ 일반API과금요청 * 0.00001
+ GetMetricData요청메트릭 * 0.00001
+ MetricStreams업데이트 * 0.000003
+ 표준알람메트릭월 * 0.10
+ 고해상도알람메트릭월 * 0.30
+ 복합알람월 * 0.50
+ 과금Basic대시보드월 * 3.00
+ Standard로그수집GB * 0.76
+ 로그저장GB-month * 0.033
+ LogsInsights스캔GB * 0.0076
+ LiveTail유료분 * 0.01
M은 과금 커스텀 메트릭-월입니다. 시간에 비례하는 메트릭·알람·대시보드는 월 단위로 집계한 수량을 쓰고, 중간 계산은 그대로 유지한 채 표시 금액만 센트 단위로 반올림합니다.
US$3,281.71 예제에서 먼저 줄일 항목 찾기
다음 수량은 적용 가능한 무료 사용량을 차감한 가정입니다. 다른 CloudWatch 기능, 관련 AWS 서비스, 세금과 크레딧은 포함하지 않았습니다.
| 입력 | 과금 수량 | 식 | 소계(USD) |
|---|---|---|---|
| 사용자 지정 메트릭 | 12,000 메트릭-월 | 10,000 × 0.30 + 2,000 × 0.10 | 3,200.00 |
| 일반 API | 2,000,000건 | 2,000,000 × 0.00001 | 20.00 |
| GetMetricData | 메트릭 1,500,000개 | 1,500,000 × 0.00001 | 15.00 |
| Metric Streams | 업데이트 2,000,000회 | 2,000,000 × 0.000003 | 6.00 |
| 표준 알람 | 50 메트릭-월 | 50 × 0.10 | 5.00 |
| 고해상도 알람 | 5 메트릭-월 | 5 × 0.30 | 1.50 |
| 복합 알람 | 2 알람-월 | 2 × 0.50 | 1.00 |
| 유료 Basic 대시보드 | 2 대시보드-월 | 2 × 3.00 | 6.00 |
| Standard 로그 수집 | 30 GB | 30 × 0.76 | 22.80 |
| 로그 저장 | 50 GB-month | 50 × 0.033 | 1.65 |
| Logs Insights | 100 GB 스캔 | 100 × 0.0076 | 0.76 |
| Live Tail | 유료 200분 | 200 × 0.01 | 2.00 |
| 선택한 항목의 공개 단가 소계 | 3,281.71 |
메트릭이 US$3,200이고 나머지를 모두 합해도 US$81.71입니다. 이 경우에는 불필요한 차원, 중복 수집으로 생긴 추가 시계열, 아무도 쓰지 않는 메트릭부터 살펴야 합니다. 로그 보존 기간을 줄여도 가장 큰 비용은 그대로입니다.
메트릭-월만 바꾸고 다른 수량을 고정하면 차이가 더 분명합니다.
| 메트릭-월 | 메트릭 소계 | 다른 항목 고정값 | 합계(USD) |
|---|---|---|---|
| 8,000 | 2,400.00 | 81.71 | 2,481.71 |
| 12,000 | 3,200.00 | 81.71 | 3,281.71 |
| 300,000 | 29,500.00 | 81.71 | 29,581.71 |
사용하지 않는 시계열을 줄이는 것과 진단에 필요한 해상도를 낮추는 것은 구분해야 합니다. 비용을 줄인 뒤에도 기존 알람과 장애 조사가 제대로 작동해야 합니다.
수집·저장·조회 비용은 각각 다르게 줄인다
수집량이 늘었다면 원본 로그 수준과 중복 전달을, 저장량이 늘었다면 로그 그룹의 보존 기간을 살펴봅니다. Logs Insights 비용은 조회 시간 범위, 선택한 로그 그룹, 같은 쿼리의 반복 실행이 단서가 됩니다.
예를 들어 과금 대상 로그 1,000 GB를 이미 수집했다면 US$760의 수집 비용은 발생한 상태입니다. 이후 보존 기간을 줄여 낮아지는 것은 저장 비용입니다. 이 단가에서 1,000 GB를 스캔하는 쿼리 한 번은 US$7.60입니다. 얼마나 오래 보관하는지와 한 번에 얼마나 조회하는지는 서로 다른 항목에 영향을 줍니다.
이는 Standard 로그와 표의 Logs Insights 항목에 해당하는 단가입니다. Infrequent Access, Vended Logs, S3/Firehose 전달, 데이터 보호에는 별도의 가격 조건이 있습니다. 보존 기간도 감사와 장애 조사에 필요한 범위를 먼저 확보한 뒤 줄여야 합니다.
UsageType에서 실제 작업까지 따라가기
Cost Explorer에서 CloudWatch를 선택하고 길이가 같은 기간을 Usage Type부터 보고 필요에 따라 API Operation, Region으로 그룹화를 바꾸면 원인을 좁힐 수 있습니다. 도쿄 항목에는 주로 APN1-이 붙지만 대시보드와 무료 사용량은 리전 비종속 항목일 수 있습니다. CloudWatch 청구 분석
| 비용 단서 | UsageType | 가격표 operation 또는 청구 단서 | 먼저 확인할 것 |
|---|---|---|---|
| 사용자 지정·상세·임베디드 메트릭 | APN1-CW:MetricMonitorUsage |
가격표는 빈 값; CUR은 MetricStorage, MetricStorage:AWS/<Service>, MetricStorage:AWS/Logs-EMF 등 |
네임스페이스, 차원, 생성 주체 |
| 일반 API | APN1-CW:Requests |
가격표는 빈 값; 실제 청구 operation으로 분해 | 호출 주체, 폴링 주기 |
| GetMetricData | APN1-CW:GMD-Metrics |
GetMetricData |
쿼리 횟수와 요청 메트릭 수 |
| Metric Streams | APN1-CW:MetricStreamUsage |
MetricUpdate |
스트림, 필터, 업데이트 수 |
| 알람 유형 | APN1-CW:AlarmMonitorUsage 등 |
가격표는 빈 값; UsageType으로 구분 | 평가 메트릭, 해상도, 유형 |
| Metrics Insights 쿼리 알람 | APN1-CW:MetricInsightAlarmUsage |
가격표는 빈 값; 본 모델에서 제외 | 쿼리가 분석하는 메트릭 수 |
| Basic 사용자 지정 대시보드 | DashboardsUsageHour-Basic |
DashboardHour |
사용자 지정, ≤50 메트릭, 무료 수량 |
| Standard 로그 수집 | APN1-DataProcessing-Bytes |
PutLogEvents |
로그 그룹, 원본, GB |
| 로그 저장 | APN1-TimedStorage-ByteHrs |
가격표는 빈 값; CUR 단서 HourlyStorageMetering |
보존 기간, GB-month |
| Logs Insights | APN1-DataScanned-Bytes |
StartQuery |
시간 범위, 로그 그룹, 스캔 GB |
| Live Tail | APN1-Logs-LiveTail |
StartLiveTail |
세션의 유료 분 |
Price List의 operation과 CUR의 line_item_operation은 다른 필드입니다. 앞의 값이 비어 있어도 뒤의 값에서 발행 주체를 찾을 수 있습니다. 로그는 그룹과 작성 서비스까지 추적합니다. 콘솔을 연 사람 수보다 계속 데이터를 만드는 애플리케이션이 지출을 더 잘 설명합니다. 리소스 수준 데이터를 활성화하면 Cost Explorer의 리소스 보기는 최근 14일을 대상으로 하므로 장기 분석에는 CUR을 사용합니다.
다음 Athena SQL은 항목별 합계의 예입니다. 테이블명과 UTC 기간을 자신의 CUR 스키마에 맞게 바꾸면 됩니다.
SELECT
line_item_usage_type,
line_item_operation,
SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS unblended_cost
FROM <cur_table>
WHERE line_item_product_code = 'AmazonCloudWatch'
AND line_item_usage_start_date >= TIMESTAMP '<start_utc>'
AND line_item_usage_start_date < TIMESTAMP '<end_utc>'
AND line_item_line_item_type NOT IN
('Tax', 'Credit', 'Refund', 'EdpDiscount', 'Fee', 'RIFee')
GROUP BY 1, 2
ORDER BY 3 DESC;
AWS 안에서 끝나는 작업이라면 CloudWatch를 유지할 이유가 있다
EC2, RDS, Lambda를 모니터링하고 AWS 안에서 알림을 처리하는 것이 주된 일이라면 CloudWatch를 계속 쓰는 것이 합리적입니다. 기본 메트릭과 기존 연동을 유지하면서 증가한 비용을 원본까지 추적하는 편이 전체 플랫폼 이전보다 작은 변경입니다.
반면 AWS 비용을 다른 클라우드의 서비스나 애플리케이션 성능과 함께 설명해야 한다면 통합된 조사 화면의 가치가 생깁니다. Guance의 AWS Billing 연동은 청구 데이터를 가져와 분석할 수 있어 비용 점검과 운영 모니터링을 같은 플랫폼에서 진행할 수 있습니다. 청구 데이터는 API와 수집 주기에 따라 갱신되므로 실시간 요청 데이터와 같은 속도로 해석해서는 안 됩니다.
CloudWatch 쿼리나 로그 전달을 유지하면 해당 AWS 비용도 남습니다. AWS만으로 처리할 수 있는 일과 여러 환경을 함께 봐야 하는 일을 나누면 추가 플랫폼에 지불하는 이유가 분명해집니다. 일본 시장 AWS 모니터링 가이드에서 이 구성을 더 살펴볼 수 있습니다.
일본 프로젝트에서 엔화 예산을 잡을 때는 실제 청구 통화, 환산 규칙과 세금을 사용합니다. 이 소계에는 Application Signals, X-Ray, RUM, Synthetics, 각종 Insights와 데이터 전송 등이 빠져 있습니다. 사용하는 기능을 같은 청구 기간에 맞춰 더해야 계정 수준의 예상 비용이 됩니다.
