日志费用由摄取、存储、分析三块组成。而最要命的一点是：日志类在创建日志组时选，之后改不了——选了标准类再想换成低频访问类，只能重建。还有几条官方给的省钱机制多数人不知道。
日志费用是账单里最典型的「没被设计的用量」：它随功能增加而自然增长，却不像实例那样有人主动选规格、选付费方式。等你注意到它时，它往往已经是某个服务下面最大的一行。
这篇按「钱花在哪 → 哪个决定不可逆 → 官方给了哪些省钱机制」的顺序讲。日志费用也常是账单突然上涨的原因之一，定位方法见 AWS 账单突然变高怎么排查。
日志费用由三块组成：摄取、存储、分析
理解这三个维度，后面所有省法都能归类：
| 维度 | 按什么计费 | 什么时候产生 |
|---|---|---|
| 摄取（写入） | 按写入的数据量 | 应用和 AWS 服务往日志组里写日志时 |
| 存储（留存） | 按存储的数据量与时长 | 日志留下来之后持续产生 |
| 分析（查询） | 按扫描的数据量或会话时长 | 你用查询工具检索日志时 |
这三块的性质完全不同，所以省法也不同：摄取是「一次性」的，写进去就写进去了；存储是「持续」的——官方博客的原话是摄取只发生一次，但存储费用会伴随数据整个生命周期累积，合规场景下可能是数年；分析则是「你主动查才产生」。最容易失控的是中间那个，因为它在你什么都不做的时候也在涨。
创建时就定死的那个选择：日志类
这是本文最值得记住的一条，也是官方文档里明确写着、但很多人在建日志组时并不知道的一条：
⛔ 日志类（Log Class）只能在创建日志组时选择，之后无法更改。 如果你当时随手用了默认值，事后想换，只能新建一个日志组——这意味着旧的日志组也不会自动消失，你很可能两边都在付费。
两种日志类的取舍很直接：
| 日志类 | 能用的功能 | 摄取成本 |
|---|---|---|
| Standard（标准） | 完整功能：指标筛选、订阅筛选、字段索引、实时跟踪、嵌入指标等 | 基准价 |
| Infrequent Access（低频访问） | 功能较少 | 通常约为标准类的一半 |
官方博客给的判断方法很实用，照抄下来就是：
- 需要「数据一到就实时告警或处理」→ 选标准类。 这是标准类不可替代的地方。
- 数据主要是为了审计、合规而长期留存 → 选低频访问类。 官方明确说它适合大多数用例。
一个立刻能做的动作：把现有日志组按「是否需要实时告警」过一遍。新建的日志组从一开始就选对——这是零成本的。而对已有的日志组，要提醒自己：改用另一类的代价是重建，所以先算清「省下的摄取费」和「重建带来的麻烦」哪个大。具体单价以官方定价页为准。
存储会自动变便宜：智能分层
存储那一块有一项不需要你配置的机制：智能分层（Intelligent Tiering）。它按「你多久没访问过这些数据」自动把存储分成三档：
| 存储档位 | 触发条件 |
|---|---|
| 标准层 | 最近 30 天内访问过 |
| 低频访问层 | 31–90 天未访问 |
| 归档即时访问层 | 91 天以上未访问 |
两个细节值得单独讲，因为它们决定了这个机制到底有没有用：
- 被访问后会重新归类并重置计时。 也就是说，你偶尔查一次某个日志组，它的数据就会回到标准层重新开始计时。所以「例行去翻一下历史日志」这件事是有成本的——官方也建议不要频繁访问日志。
- 它与日志类是两件不同的事，别混淆。 官方特别说明过：存储档位由访问模式自动决定、对所有日志组生效，与你在创建时选的日志类无关。也就是说「日志类选错了」和「存储档位」是两个独立问题。
一个容易误会的点：日志的存储费用不是按你看到的原始日志量算的——存储会按约 0.15 的压缩比计费，也就是实际计费的 GB 明显小于原始日志量。所以从「我每天写 10GB」直接推算存储费会高估。
容易被忽略的三件事：压缩比、保留策略、用量监控
这三件事都不花钱、也不需要改架构，但直接决定存储那块的账单：
- 保留策略（Retention）决定存储的终点。 它规定日志留存多久，到期即永久删除——这是唯一能真正「截断」长期存储成本的设置。不设保留策略，等于默认无限期留存。
- 监控写入量，而不是只看账单。 官方建议在 CloudWatch 图表或仪表盘上观察工作负载产生的日志量，并明确给出了排查方向：先找出是哪个日志组导致账单突然增加。
- 从日志本身降量。 官方给的第一条建议是「只记录有业务价值的事件，并使用高效的日志语法」——把日志级别调对、去掉冗余输出，是直接减少摄取量的办法。
⛔ 保留策略是最容易被「默认值」坑到的一项：如果不主动设置，日志会一直留着并持续计费。而它恰恰是成本优化里最容易见效、风险最低的一个动作——因为你通常并不需要三年前的调试日志。设置前唯一要确认的是：有没有合规要求强制你留存更久。
VPC 流日志：官方建议发往 S3
有一条官方给的、很具体的建议值得单独拎出来：
如果你用 VPC 流日志是为了审计和合规，官方建议把它发往 S3，而不是 CloudWatch。 反过来，如果你需要指标筛选、订阅筛选、日志查询、贡献者洞察这些实时分析功能，那才应该发往 CloudWatch。
这条建议的价值在于：VPC 流日志是数据量最容易失控的一类日志（它记录网络流量），如果误以为「日志就该发 CloudWatch」，很可能在不知不觉中产生一大笔摄取与存储费用。做选择时先问一句：我要的是「事后审计」还是「实时分析」？ 前者去 S3，后者留 CloudWatch。流量本身的收费机制见 AWS 流量费为什么这么贵。
还有几处容易漏掉的计费项
官方文档还列了几项「不用就没事、用了就计费」的功能。它们单项都不大，但叠加起来很常见：
| 计费项 | 触发条件 |
|---|---|
| 日志查询 | 按扫描的数据量计费——查询的时间范围越长，扫描量越大 |
| 实时跟踪 | 按会话时长计费，所以尽量缩短单次会话 |
| 贡献者洞察规则 | 每月超过 1 条规则，或每月超过一定数量的匹配事件即计费 |
| 合成监控（Canary） | 每月运行超过一定次数即计费，且每次运行还会带动其他服务产生费用 |
| 仪表盘 | 免费方案只有有限数量的仪表盘，超出即计费 |
| 容器洞察 | 按采集的指标与摄取的日志数据计费 |
一个通用省法：查询时把时间范围设短。官方明确说，缩短查询的时间范围能减少扫描的数据量、从而降低分析费用。这个动作零成本，只是改变一下习惯。
常见问题
日志已经写进去了，还能少付存储费吗？
能，主要是三件事：设置保留策略（到期自动删除，这是最直接的）、依赖智能分层（长时间不访问会自动降到更便宜的档位）、以及避免为了「随便看看」而频繁查历史日志（访问会把数据重新拉回标准层并重置计时）。
日志类选错了怎么办？
不能在原日志组上改——官方说明它只能在创建时选择。要换只能新建日志组并把写入切过去。所以先算一笔账：新方案省下的摄取费，是否值得重建的麻烦。而新建日志组时把它选对，是完全没有成本的。
怎么查出是哪个日志组在花钱？
两条路：一是用成本分析工具按服务筛选 CloudWatch、再把维度切成资源（注意用这种方式只能看最近一段时间的用量）；二是用成本与用量报告配合查询工具，按资源 ID 聚合出「哪个日志组的哪个计费项最贵」。后者更彻底，适合做一次性的大清理。整体排查思路见 AWS 账单突然变高怎么排查。
日志存到别的地方会不会更便宜？
要分场景。官方明确建议：为审计与合规而采的 VPC 流日志，发往 S3 更合适；而需要实时筛选、告警、检索的场景，留在 CloudWatch 才用得上那些功能。也就是说这不是「哪个绝对便宜」的问题，而是「你到底要用它做什么」的问题。
日志费用算不算「折扣」能覆盖的部分？
它属于用量本身，所以降低它的方式主要是「少写一点、少留一点、少查一点」，而不是靠折扣。不过节省计划这类承诺折扣覆盖的是计算类用量，不改变日志这块的计费逻辑——所以别指望用折扣来治日志费用。折扣那一层能做什么，见 AWS 优惠全览；整体成本优化的做法见 AWS 账单看不懂？6 个可执行做法；我们自己的渠道侧做法见 AWS 折扣与代理定价，五家厂商的机制差异见 五家云厂商折扣机制对比。