CloudWatch 东京费用：读懂指标、日志与查询账单
按东京区域单价拆解 CloudWatch 指标、日志、告警与查询费用，用可复算账单找到增长来源，解释保留期、序列数量与查询范围怎样影响预算。
CloudWatch 账单上涨时，先找到涨得最多的那一项，往往比换监控平台更有效。日志写入贵，缩短保留期只能减少存储；自定义指标太多，删几个仪表板也解决不了主要问题。
东京区域的 Standard 日志写入是 US$0.76/GB，存储是 US$0.033/GB-month，Logs Insights 按扫描量收取 US$0.0076/GB。同样出现在“日志费用”里，背后是三份不同的工作。业务主要运行在 AWS、现有监控已经够用时，我更倾向先整理这些用量，再决定是否增加平台。
观测云编辑部。本文于 2026 年 10 月 27 日核验 AWS 东京区域公开价格。以下是美元单价和假设用量的计算，不是客户账单或性能测试结果。
东京区域单价与免费额度
本文使用 ap-northeast-1 的 AWS 2026 年 10 月 7 日价格表。CloudWatch 总费用由不同项目的用量相加，启用额外功能还会增加相应费用。
| 计费项目 | 公开美元单价 | 需要统计的数量 |
|---|---|---|
| 自定义指标：前 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 个指标时，前三个免费。超过 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 |
价格表为空，按实际账单操作拆分 | 调用方、轮询间隔 |
| 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;
继续用 CloudWatch，还是扩展调查范围
如果主要任务是监控 EC2、RDS、Lambda，并在 AWS 内完成通知，CloudWatch 有充分的保留理由。沿用基础指标与已有集成，把涨价项追到来源，通常比搬迁整个平台更容易落实。
当费用问题需要与其他云上的服务、应用性能一起解释时，统一调查入口才开始有额外价值。观测云的 AWS Billing 集成可以接入账单数据做分析，让日常费用检查和运行监控在同一平台展开。账单数据按接口和采集周期更新，读取时应与实时请求数据区分。
这类接入不会自动消除 AWS 账单。保留 CloudWatch 指标查询或日志路径，就仍有对应的 AWS 用量。把 AWS 内已经能完成的工作，与确实需要跨环境解释的问题分开，才能判断新增平台的费用是否值得。日本市场 AWS 监控方案可以据此进一步了解。
日本项目若按日元编制预算，应使用实际账单币种、换汇规则和税率。本文小计未包括 Application Signals、X-Ray、RUM、Synthetics、各类 Insights 和数据传输等额外费用；启用哪些能力，就把相应项目加入同一月份再核算。
