排查AWS S3非GET（Tier1）请求账单与指标不符问题

一、定位异常请求来源的具体方法 #

• 启用S3服务器访问日志
  在目标S3桶的「属性」面板中找到「服务器访问日志」，启用后指定日志存储的目标位置（可选择同桶的特定前缀或另一个S3桶）。日志会记录每一次请求的完整信息：请求类型、发起IP、时间戳、请求资源、响应状态等，能精准定位Tier1请求的来源。注意日志生成有延迟，通常需要等待数分钟到数小时。

• 核对AWS账单明细
  进入AWS账单控制台，找到S3服务的账单详情，展开「请求」分类下的Tier1请求条目，查看是否存在其他区域的S3桶产生的请求——可能你忽略了在其他区域创建的桶，或者默认区域下的隐性桶（比如CloudFormation、Lambda部署包存储桶）。同时检查是否有其他AWS服务（如Lambda、Glue、CodePipeline）在后台调用S3的Tier1操作，比如Lambda更新部署包时会触发PutObject请求。

• 利用CloudTrail事件溯源
  若未启用CloudTrail，先在控制台开启它。之后筛选S3服务的事件，操作类型选择PutObject、PostObject、CopyObject、ListObjects等Tier1请求类型，查看事件的发起主体（IAM用户/角色）、时间和目标资源。重点排查是否有第三方服务、内部应用误用凭证，或IAM角色被意外赋予了S3写入权限。

• 检查IAM权限与访问密钥
  在IAM控制台查看所有用户和角色的访问密钥，核对密钥的最后使用时间，排查是否有泄露或未授权使用的情况。同时检查桶策略和IAM策略，确认是否存在疏漏导致匿名用户或未授权实体拥有S3写入权限。

二、CloudFront是否会产生S3 Tier1请求？ #

CloudFront本身不会直接触发S3的Tier1请求，但存在几种间接情况：

• 若CloudFront分发配置了日志存储到S3，每次生成日志文件时会触发PutObject请求，这类请求属于Tier1，且日志生成频率较高，容易累积大量请求。
• 如果使用了Lambda@Edge函数，函数逻辑中若包含S3的写入/复制/列表等操作，会直接产生Tier1请求。
• 其他CloudFront配置操作（如更新缓存策略、修改分发设置）不会触发S3的Tier1请求；使用OAC/OAI访问S3源站时，仅会产生GET类Tier2请求。

内容的提问来源于stack exchange，提问作者Julien BERNARD