第2章：CloudTrail核心概念
CloudTrail 的核心，说白了就四个词：事件、轨迹、日志文件，以及管理事件 vs 数据事件。
我刚开始接触 CloudTrail 的时候，也被这几个概念绕得晕。后来在一次事故复盘里，因为搞混了「事件」和「日志文件」，差点把审计周期拖了两天。从那以后我就明白了——概念不清，后面全是坑。
2.1 事件：CloudTrail 的最小记录单元
事件就是一条操作记录。只要有人在 AWS 里做了点什么——创建 EC2、修改 S3 桶策略、调用 Lambda——CloudTrail 就会生成一个 JSON 格式的事件。
一个典型的事件长这样：
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"arn": "arn:aws:iam::123456789012:user/admin"
},
"eventTime": "2025-03-01T12:34:56Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "RunInstances",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.1",
"requestParameters": { ... },
"responseElements": { ... }
}
这里有几个字段我建议你重点关注：
- eventSource / eventName：谁家的 API，哪个动作。
- userIdentity：谁干的（用户、角色、Root 等）。
- sourceIPAddress：从哪发起的请求。这个字段在排查异常访问时特别好用。
- requestParameters / responseElements：具体改了啥、结果如何。
eventVersion 字段。老版本的事件字段格式可能不一样，解析脚本容易出 bug。我曾经因为忽略版本差异，导致自动化分析漏掉了半个月的异常登录。
2.2 轨迹：把事件送到哪里去
事件本身就在 CloudTrail 服务里存着（默认保留 90 天）。但你真想长久审计，就得建一个轨迹（Trail）。
轨迹就是个管道。你告诉 CloudTrail：「把事件给我送到 S3 里，顺便通知 CloudWatch Logs。」
轨迹有两种：
- 单区域轨迹：只记录一个区域的事件。适合小规模场景。
- 多区域轨迹：把全球所有区域的事件都汇到同一个 S3 桶里。我个人的习惯是——只要预算允许，一律用多区域。否则你审计的时候发现「这个区域怎么没记录」，那才叫尴尬。
轨迹可以实时投递，也可以启用日志文件验证（Log File Validation）。一旦开启，CloudTrail 会在日志文件旁生成一个 .digest 文件，用来校验日志是否被篡改。
我建议你在所有生产环境都打开这个功能——代价很小，但能让审计报告更有说服力。
2.3 日志文件：最终落地的 JSON 文本
CloudTrail 会把多条事件聚合成一个日志文件，写入 S3。文件路径很有规律：
bucket-name/AWSLogs/account-id/CloudTrail/region/yyyy/mm/dd/
文件名类似：123456789012_CloudTrail_us-east-1_20250301T1200Z_nz8x2b3c.json.gz
注意几个点：
- 默认是 gzip 压缩。你直接下载是打不开的，得先解压。
- 文件里是一组 JSON 对象，每行一个事件。嗯，不是标准 JSON 数组，是 JSON Lines 格式。
- 同一个区域同一个小时内的事件会打包成一个文件。如果事件量很少，也可能没文件生成——这不算错误。
我自己遇到过一个问题：某天突然发现 S3 里少了几个小时的文件，排查半天发现是 CloudTrail 的投递权限配错了——那个 S3 桶的 KMS 密钥被轮转但忘了更新轨迹。所以，权限和密钥配置一定要定期检查。
2.4 管理事件 vs 数据事件
这是很多人最迷糊的地方。我直接给你画个表：
| 对比维度 | 管理事件 | 数据事件 |
|---|---|---|
| 记录对象 | 控制平面的操作（创建/删除/修改资源） | 数据平面的操作（读写对象/调用函数/查询数据库） |
| 典型例子 | RunInstances、DeleteBucket、CreateUser |
GetObject、Invoke、PutItem |
| 费用 | 免费（S3 存储费另算） | 收费（每百万事件 $0.10） |
| 默认是否开启 | 是（90 天可查） | 否（需要专门配置轨迹） |
| 常见场景 | 合规审计、权限滥用排查 | 数据泄露追溯、异常行为检测 |
管理事件默认就开着，数据事件你得主动买。为什么？因为数据事件的量级太大了——一个 S3 桶一天可能被读几百万次，全记下来成本爆炸。所以 AWS 把数据事件做成可选，按量付费。
那怎么选？我的建议：
- 管理事件 → 必开，全域、多区域，免费为啥不开？
- 数据事件 → 按敏感级别开。比如只记录包含 PII 的 S3 桶，或者只记录生产环境的 Lambda 调用。
整体关系图
下面这张图把上面几个概念串在一起。你看一眼就能明白事件怎么流转、轨迹怎么连接、最终日志怎么落盘。
从图中你能看到：事件从 AWS 服务产生，经过 CloudTrail 收集，再通过轨迹的配置，决定哪些事件被投递到 S3 或 CloudWatch Logs，最后由下游工具做审计分析。