CloudWatch vs CloudTrail：监控、审计与故障调查怎么搭配

接口突然开始返回 403。CloudWatch 中的错误率告诉值班人员哪些服务受影响，CloudTrail 则可能留下故障前的一次 IAM 策略修改。把两份记录放在一起，才有机会区分代码问题与权限变化。

这也是两者通常需要配合使用的原因。CloudWatch 更接近应用和资源运行时发生的事，CloudTrail 记录受支持的 AWS 账号活动与 API 事件。名字相近，观察的对象却不完全相同。

已经能发现故障，却总要翻聊天记录猜“刚才谁改了什么”，就该补上审计记录。操作记录保存得很完整，但业务出了问题仍不知道影响范围，则还需要应用指标和日志。下面沿一次权限故障，看两边怎样接起来。

作者：观测云编辑部。资料核对于 2026-10-21。本文依据 AWS 官方文档讨论商业区域中的常见用法；示例是调查思路，没有执行故障注入或成本实测。

先找到失败请求，再找之前的操作

同样是 403，它可能只发生在一个接口、某个版本或某个区域。CloudWatch 的请求指标与应用日志可以先缩小影响范围，Application Signals 还能提供应用指标、依赖关系和 SLO。CPU 没有变化，也不能说明请求没有失败。Application Signals。

许多 AWS 服务会发布原生指标，操作系统内存、应用日志和 Trace 则可能需要 CloudWatch Agent、SDK 或其他采集方式。安装了服务并不等于这些细节都已经留下。CloudWatch Agent。

时间和资源确定后，再到 CloudTrail 找相应管理事件，沿事件名、目标资源、请求参数和成功或失败信息查看发生了什么。调用身份有时是一个角色会话，代表所用凭证；要继续追到实际操作者，还可能需要身份提供方和登录记录。

一条策略修改刚好出现在错误率升高之前，是值得调查的线索，但时间接近还不足以证明因果。对照变更内容、影响资源和请求结果，比把所有邻近事件都列为原因更有用。应用、账号、区域、资源 ID 和时区一致，也能减少看错时间顺序的情况。

事件历史里为什么没有那次对象读取

CloudTrail 事件历史默认可用，保存过去 90 天、单个区域的管理事件，查看它没有 CloudTrail 费用。它不包含数据事件、Insights 或网络活动事件，也不提供组织级统一历史。查询限于相应账号与区域，筛选能力也与完整分析服务不同。事件历史。

修改 S3 桶配置属于一类操作，读取桶里的对象属于另一类。GetObject、PutObject、DeleteObject 这些对象级操作属于数据事件，Trail 默认不记录。记录哪些资源、哪些操作，由相应选择器决定，并产生数据事件费用。数据事件与选择器。

因此，应用日志里有一条对象访问失败，事件历史却找不到它，并不奇怪。两套记录观察的对象不同。今天启用数据事件，也无法补回昨天没有记录的访问。

如果要在测试环境走一遍前面的权限故障，可以先保存正常请求的指标与日志，再执行经过授权且可回滚的变更，对照 CloudWatch 与 CloudTrail 的记录，恢复后继续观察请求结果。调查对象若是 S3 对象，数据事件要在这之前启用。这是建议的演练方式，不是本文已经运行过的测试。

九十天以后，数据留在哪里

需要持续保留审计记录时，可以配置 Trail 将选定事件投递到 S3，并按需要采用多区域或组织级范围。它与默认事件历史是独立机制，保留期限、访问控制、加密、完整性验证和交付状态也由这条路径继续承担。

文件已经进入桶，并不意味着以后一定能按时找回。谁能读、谁能删、保留多久、交付中断后怎样发现，都影响这份记录是否真能用于调查。长期保存、在线查询和按时恢复，也有不同的资源需求。

新方案还要注意 CloudTrail Lake 的变化：从 2026-05-31 起，它不再向新客户开放。已有客户可以继续使用；仅有账户级事件数据存储时，新加入组织的账号不会自动获得同样覆盖，组织级存储有不同安排。受影响的是 Lake 的新客户可用性，不是 Trail、Insights 等功能停止支持。AWS 可用性说明。

因此，新账号不能照旧教程把 Lake 当作随时可建的查询入口。AWS 当前指引建议评估 CloudWatch 等路径，具体选择要结合已有存储与查询习惯，而不是为了延续教程里的组件名称。

一次权限变更怎样变成通知

CloudTrail 留下事件以后，支持的事件路径可以交给 EventBridge 规则匹配，再投递到通知或处理目标。另一条常见路径，是将 Trail 日志发送到 CloudWatch Logs，由指标过滤器生成指标，再触发 CloudWatch 告警。CloudTrail 与 CloudWatch Logs。

两种方式的事件覆盖、延迟、权限和费用不完全相同。记录已经到达，但规则没有匹配，或者匹配了却发不到目标，值班人员仍收不到消息。通知链路要与日志交付一起运行，而不只是配置页面上的一个开关。

高频正常操作也不适合全部通知。把真正需要处理的变更与日常操作区分开，能避免团队在大量提示中错过关键事件。同一记录同时进入 S3、CloudWatch Logs 和第三方平台时，也最好由一处承担通知和升级，其他位置保留调查数据。

读取量和查询量怎样影响费用

免费查看事件历史，与 Trail 每个区域第一份管理事件副本投递到 S3 的免费规则，是两个口径。后者也不包括整个存储和查询系统。附加管理事件副本、数据事件及所选附加功能可能收费，S3 存储与请求、CloudWatch Logs、查询和通知路径也可能继续产生费用。CloudTrail 价格。

例如某个对象每天被读取一千万次，把这些读取操作纳入数据事件，与只保留少量配置修改不是同一个用量级别。选择器能收窄记录范围，但同时也放弃了被排除操作的证据。先确定必须回答哪些调查问题，比直接把所有事件都保存下来更容易控制成本。

CloudWatch 则按地区与功能计量，包括指标、API、日志摄入、存储、查询、告警与应用观测。一个日志 GB 单价无法代表长期留存和所有查询费用。CloudWatch 价格。

查询习惯也会改变预算。平时只看最近十分钟的应用错误，事故后回查一个月的权限活动，对历史数据和扫描范围的要求不同。保留什么、留多久、在哪里查，应该围绕实际使用频率安排，而不是因为某项基础功能免费，就认为整套审计也接近免费。

运行记录与操作记录各自留下

主要困难是发现故障和确定影响范围，先把 CloudWatch 中的关键请求指标、日志与告警补齐。已经能看到异常，但变更经常没有连续记录，则优先完善 CloudTrail 的事件范围与持续留存。

生产系统通常都需要这两类信息，但不必无差别启用每个附加功能。关键服务看得到运行变化，关键资源的操作也留得下来，两边能按时间和资源接续调查，就有了一个可靠的起点。之后随着真实事故暴露出的缺口再扩大范围。

在观测云中对照其他环境的日志

同一次调查还涉及其他云或应用时，可以把经过授权、采集和解析的数据放到观测云的日志分析中，按账号、资源、事件时间和操作类型筛选。这样能在同一个入口对照相关记录，不必反复复制时间与资源标识。

原始审计文件的保留与访问控制仍要继续维护。日志平台能帮助查询已经存在的数据，不能补回没有启用的数据事件；增加集中分析的费用，也应与原有存储和投递费用一起计算。