日志能回答什么
对象存储的访问日志按请求逐条记录：谁、在什么时间、对哪个对象、用了什么方法、结果如何。它由服务端异步投递到另一个桶里，因此有延迟、也可能需要额外费用，但它是回答「这个对象被谁读过」「删掉它的是谁」这类问题的唯一稳定依据。与 API 级审计日志配合使用，可以覆盖数据面与管理面两条线。
基本信息
| 日志类型 | 桶访问日志（数据面）与 API 审计日志（管理面） |
|---|---|
| 投递方式 | 批量异步写入指定的日志桶 |
| 记录粒度 | 一次请求一条记录 |
| 注意点 | 投递有延迟，日志桶容量需单独规划 |
典型使用场景
- 安全排查：定位异常删除与批量下载行为的来源
- 访问统计：按对象与请求者分析热点数据
- 成本归因：把出网流量与请求数分摊到具体业务
- 故障定位：结合请求标识串联客户端报错与服务端记录
- 合规举证：证明某次数据访问已按策略被授权
启用与查询思路
启用与查询思路
# 1) 先建好日志桶并授权服务端写入
# 2) 在业务桶上开启日志投递，指定目标桶与前缀
aws s3api put-bucket-logging --bucket demo-bucket \
--bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"log-bucket","TargetPrefix":"logs/demo/"}}'
# 3) 日志以对象形式按时间前缀堆积，可按前缀列举
aws s3api list-objects-v2 --bucket log-bucket --prefix logs/demo/2026/10/
# 4) 结合请求标识回查某次报错的完整记录关键字段读法
| 字段 | 含义 | 排查看点 |
|---|---|---|
| 请求者标识 | 发起请求的身份 | 匿名与预签名请求的来源往往不同 |
| 操作与对象键 | 执行了什么方法、针对哪个对象 | 定位批量操作的具体目标 |
| 响应状态 | 处理结果与错误类型 | 区分客户端参数错误与服务端拒绝 |
| 耗时与字节数 | 本次请求的时长与传输量 | 异常长的耗时往往指向大对象或限流 |
| 请求标识 | 串联客户端与服务端的唯一线索 | 排查报错时优先索取 |
使用建议
- 日志桶单独规划容量与生命周期，避免日志把主桶容量吃满
- 日志本身含访问路径与请求者信息，同样按敏感数据做权限收敛
- 开启分区与压缩，海量日志的查询成本主要取决于组织方式
- 把日志接入集中检索平台，临时手工翻日志在故障时效率极低
- 对异常模式设置告警，例如短时间内大量删除请求
日志是「尽力投递」的：少量记录可能延迟较久才出现，因此安全取证时不要只凭即时查询结果下结论。
桶访问日志记录数据面请求，管理面操作（改策略、改版本控制等）需要依赖 API 审计日志，两者互补才能覆盖完整审计范围。