S3存储桶单个对象相关成本排查：DataTransfer-Out-Bytes费用激增定位方案

绝对有办法揪出这些导致数据传输成本飙升的文件！我来分享几个实战中屡试不爽的方法，帮你精准定位问题：

CloudTrail会记录所有针对S3对象的API请求，包括GetObject这类触发数据流出的操作。你可以按以下步骤来分析：

• 确保你的S3存储桶已经开启了CloudTrail日志记录（如果没开，先去IAM控制台启用，选择包含S3事件）。
• 把CloudTrail的日志文件导入到Athena中（AWS有现成的表结构模板可以直接用）。
• 执行类似下面的SQL查询，统计每个对象的访问次数和总传输字节数：

SELECT
  useridentity.arn,
  requestparameters.bucketname,
  requestparameters.key,
  COUNT(*) AS request_count,
  SUM(responseelements.x-amz-bytes-sent) AS total_bytes_sent
FROM
  cloudtrail_logs_table
WHERE
  eventname = 'GetObject'
  AND requestparameters.bucketname = '你的存储桶名称'
GROUP BY
  useridentity.arn, requestparameters.bucketname, requestparameters.key
ORDER BY
  total_bytes_sent DESC
LIMIT 50;

这个查询会按总传输字节数从高到低排序，一眼就能看到哪些文件被请求得最多、传输量最大。

如果CloudTrail的粒度不够细，S3自带的访问日志能提供更详细的传输数据：

• 先在S3控制台给目标存储桶开启访问日志，指定一个专门的日志存储桶（别和目标桶用同一个，避免循环日志）。
• 等几个小时积累足够日志后，在Athena中创建对应S3日志的表结构（AWS文档里有现成的建表语句，直接复制即可）。
• 用下面的SQL查询来统计每个文件的总流出字节：

SELECT
  uri_key,
  SUM(bytes_sent) AS total_bytes_sent,
  COUNT(*) AS request_count
FROM
  s3_access_logs_table
WHERE
  bucket = '你的存储桶名称'
  AND operation = 'REST.GET.OBJECT'
GROUP BY
  uri_key
ORDER BY
  total_bytes_sent DESC
LIMIT 100;

这里的uri_key就是存储桶里的对象路径，排序后最靠前的就是传输成本的主要来源。

如果暂时不想碰日志分析，先通过Cost Explorer快速定位大致方向：

• 打开Cost Explorer，筛选S3的DataTransfer-Out-Bytes成本。
• 添加维度：先选“存储桶”确认是不是这个桶的问题，再添加“前缀”维度，看哪个前缀下的文件贡献了大部分成本。
• 缩小范围后，再结合前面的日志方法去具体前缀里找高传输量的文件。

• 优先检查大文件：大文件哪怕被访问几次，传输量都可能远超小文件的多次访问，先用aws s3 ls s3://你的桶名 --human-readable --summarize看看桶里的大文件列表。
• 检查公开访问权限：如果桶里的对象是公开可读的，很可能被爬虫或者第三方大量请求，去S3控制台的“权限”标签页检查桶策略和对象ACL。
• 考虑缓存优化：如果这些文件是给用户访问的，建议搭配CloudFront CDN，缓存静态资源，减少直接从S3的流出量，同时降低延迟。

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