背景
1 | On November 21, 2025, Amazon Simple Storage Service (Amazon S3) will stop returning Owner.DisplayName for all request responses. Owner.DisplayName is a legacy field that most modern applications do not rely on as it has been superseded by AWS Account IDs and IAM ARNs. Until November 21, 2025, S3 will progressively remove this field from request responses. After this date, Owner.DisplayName will not be returned for any requests made to Amazon S3. The Owner.DisplayName parameter is supported only in eight AWS Regions on the Amazon S3 APIs listed below under recommended actions. If you have applications that rely on this behavior to validate ownership of objects, we recommend using canonical IDs (unique identifier for AWS accounts), AWS account ID (12 digit identifier) or IAM ARNs (full resource naming) as a direct replacement of Owner.DisplayName. This change affects the following AWS Regions: US-EAST-1 Region, US-WEST-1 Region, US-WEST-2 Region, AP-SOUTHEAST-1 Region, AP-SOUTHEAST-2 Region, AP-NORTHEAST-1 Region, EU-WEST-1 Region, and SA-EAST-1 Region. |
AWS 通知：从 2025-11-21 起，S3 不再返回 Owner.DisplayName 字段（逐步在此之前移除）。
建议替代：使用 owner canonical ID（Owner.ID）、AWS Account ID（12位） 或 IAM ARN 来校验对象归属或替代 DisplayName。
解决办法
其实一开始想了好几个解决办法的，大致分为这几种
开发自查
一开始我们想的让开发自己查一下，但是由于项目实在太多，而且开发任务很近，就此作罢
Lambda确认
一个一个检查现有的Lambda function，虽然能查到一些东西，但是有局限性，比如
- function过多，一个一个查浪费大量时间
- 除了Lambda，可能还有别的地方例如通过sdk查询的，没有办法查完整
CloudTrail查询
由于AWS同时提供了可能会受影响的API，所以其实只要通过CloudTrail查询记录即可
最后决定用该方法查询
| API 名称 | CloudTrail 事件名 | 类型 | 说明 |
|---|---|---|---|
REST.GET.ACL |
GetBucketAcl, GetObjectAcl |
Management event | 因为属于访问资源的访问控制列表（ACL），不算对象级数据操作 |
REST.GET.BUCKET |
ListObjects, ListObjectsV2 |
Data event | 属于读取对象列表（对象级操作） |
REST.GET.BUCKETVERSIONS |
ListObjectVersions |
Data event | 同样是列出对象版本（对象级操作） |
REST.GET.LOGGING_STATUS |
GetBucketLogging |
Management event | 属于查看 bucket 属性的管理操作 |
REST.GET.SERVICE |
ListBuckets |
Management event | 属于查看账户下所有 bucket（管理级） |
REST.GET.UPLOAD |
ListParts |
Data event | 对象上传分片信息（对象级别） |
REST.GET.UPLOADS |
ListMultipartUploads |
Data event | 同上，属于对象上传过程的一部分 |
实现
如果不能用Organization Trail
需在每个子账号：
手动登录查看 Event history（仅管理事件，保留 90 天）；
若要 Data Event，则在该子账号创建/配置 Trail 启用 Data Events；
或者在每个子账号建立一个 “Audit Role”，在管理账号用 AssumeRole 脚本逐个查询 CloudTrail 事件（自动化但需跨账号权限与脚本）。
如果用了Organization Trail
那我们这里需要确认有没有集成CloudWatch Log,在Trail的详情里如图所示
如果看到这个配置了，就说明已经开启了集成CloudWatch Log
这时候我们就可以去CloudWatch里面查找事件了
CloudWatch
问题记录
管理账号的Event history中没看到别的账号的event
- CloudTrail Event History 只显示 Management Account 本账号或 organization trail 可以看到的事件。
- Event History 页面本身只显示最近 90 天的事件。
- 更重要的是，Event History 不会自动展示 Organization 中所有子账号的事件，它只显示事件的摘要，组织级的事件需要 通过 Trail 指向的 S3 或 CloudWatch Logs 来访问。
也就是说，即便你在 Management Account 创建了 Organization Trail，Management Account 的 Event History 界面不会直接显示子账号的事件。
没有Data Event
organization自带了一个organization trail， 但是这个trail只有management event，并不会收集data event
如果想要收集data event的话，需要在管理账号中修改配置，添加data event
如果我在管理账号创建 Organization Trail，会不会自动收集到所有子账号的 Data Events？
是的（条件）：
管理账号创建的 Organization Trail，并在该 trail 中启用了 DataEvents（例如 AWS::S3::Object），则会自动收集整个 Organization 下所有子账号的 Data Events（子账号无需做任何额外配置）。
关键是：创建时需设置 –is-organization-trail / IsOrganizationTrail: true，并 put-event-selectors 加入 S3 DataResources：
1 | aws cloudtrail put-event-selectors \ |
验证：
1 | aws cloudtrail describe-trails --trail-name OrgTrail -> IsOrganizationTrail: true |
S3 存储路径下会看到各账户的日志 AWSLogs/
知识点
- Organization Trail的日志会存在Log Archived这个account中，而不是管理账号
费用
CloudTrail / Organization Trail 的计费（简要）
Management events：第一个副本（写入 S3 的 trail）免费。
Data events：按事件数量计费（例如 S3/Lambda Data Event，通常为每 100,000 条 ~ $0.10 —— 以 AWS 公布的当期价格为准）。
Organization Trail 本身不单独收费，但Data Event 的计费会在管理账号中结算（所有子账号的 data event 汇总到管理账号计费）。
注意：如果对子账号也单独创建了另一个 trail 收集相同的 data events，会产生重复计费（每个 trail 都计费）。
