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.*$优先丢弃高频低价值日志，例如 health check、静态资源 200、重复 debug、过长 payload。生产环境默认 INFO，排障时临时提高到 DEBUG，比长期全量 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, environmentpod_id、request_id 这种高基数字段更适合进入日志或 trace，不适合做 CloudWatch custom metric 维度。
Metrics 降本 2：聚合后再上报
不要每个实例、每个租户、每个接口都直接 PutMetricData。可以在应用或 collector 层做聚合，例如每 60 秒上报一次 p50/p95/p99、count、error_count。
PutMetricData API 本身也可能产生请求费用，常见价格约 $0.01/1,000 requests。把 10 秒上报改为 60 秒上报，通常不会影响大多数业务告警，却能减少 API 请求和指标数量。
Metrics 降本 3：正确使用 EMF
Embedded Metric Format 可以从结构化日志中提取指标，适合把日志和指标打通。但 EMF 不是”免费指标”。它仍然会产生日志摄入费用，并可能生成 custom metrics 费用。
使用 EMF 时要注意：
- 不要把 user_id、order_id、container_id 放进 dimensions。
- 控制 namespace 数量。
- 对高频事件先聚合再输出 EMF。
- 定期检查实际生成了多少 unique metrics。
Metrics 降本 4：告警与 Dashboard 也要治理
告警常见问题是每个维度组合都建一个 alarm，最后变成几千个 alarm。更推荐：
- 关键 SLO 建少量聚合告警。
- 明细问题通过 dashboard 或日志排查。
- 对相关 alarm 使用 composite alarm 降低噪音。
- 删除无人查看的 dashboard。
Dashboard 本身单价不一定高，但频繁自动刷新会带来 GetMetricData API 成本，特别是大屏和轮询系统。
什么时候考虑 S4 Metrics？
如果 CloudWatch Custom Metrics 的主要问题是高基数带来的成本，而业务又确实需要保留较细粒度的指标，可以评估 S4 Metrics 这类替代方案。它的定位是降低 CloudWatch 自定义指标的 cardinality 成本，不是替代所有可观测性系统。适合先从非核心 namespace 或成本最高的指标族做 A/B 试点。
一个可执行的 7 天计划
第 1 天：用 Cost Explorer 找出 CloudWatch Top usage type。 第 2 天：列出所有 log group 的大小和 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 的开发方）。