S3 存储成本优化实战：从计费维度拆解到 7 个可落地手段

很多团队看 S3 账单时只盯着”存了多少 TB”，但真正的 S3 成本通常由四类费用叠加：存储容量、请求次数、数据传输、管理功能。优化也应该从这四个维度拆开看，而不是简单地把所有 bucket 都迁到更冷的存储类。

以下价格以 us-east-1 为例，实际以 AWS 当区价格为准：S3 Standard 前 50TB 大约是 $0.023/GB-month；Standard-IA 大约 $0.0125/GB-month；Glacier Instant Retrieval 大约 $0.004/GB-month；Glacier Deep Archive 大约 $0.00099/GB-month。看起来 Deep Archive 便宜很多，但它有最低存储时长、取回时间和取回费用，不能盲目迁。

1. 先分清账单来源

建议先在 Cost Explorer 里按 Usage type 拆开：

• TimedStorage-ByteHrs：对象存储容量。
• Requests-Tier1/Tier2：PUT、LIST、GET 等请求。
• DataTransfer-Out-Bytes：公网或跨区域传输。
• Monitoring-Automation、Inventory、StorageLens：管理与分析功能。

一个常见误区是：存储费不高，但 LIST/GET 请求很多，或者私有子网访问 S3 走了 NAT Gateway，导致网络账单上涨。S3 优化不要只看 bucket size。

2. Intelligent-Tiering 与生命周期规则

如果对象访问模式不稳定，S3 Intelligent-Tiering 是低风险起点。它会在 Frequent、Infrequent、Archive Instant 等层之间自动移动对象，自动层之间没有取回费，但会收取监控与自动化费用，典型价格是 $0.0025/1,000 objects-month。如果对象很小、数量巨大，这笔管理费可能不划算。

生命周期规则适合访问模式明确的数据，例如日志、备份、训练样本：

{
  "Rules": [
    {
      "ID": "logs-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 730 }
    }
  ]
}

注意最低存储时长：Standard-IA 通常 30 天，Glacier Instant Retrieval / Flexible Retrieval 通常 90 天，Deep Archive 通常 180 天。短生命周期对象不适合过早转冷。

3. Glacier IR 与 Deep Archive：只给”真的冷”的数据

Glacier Instant Retrieval 适合”低频但要毫秒级读取”的归档，例如合规查询、历史报表。Deep Archive 适合几乎不会读取、可以等待数小时恢复的数据，例如多年备份。

判断标准可以很朴素：如果一个对象 6 个月内大概率不会读，Deep Archive 才值得评估；如果业务方无法接受恢复等待，就不要为了账单好看硬迁。

4. 清理旧版本与未完成 Multipart Upload

开启 Versioning 后，删除对象只会产生 delete marker，旧版本仍在计费。很多 bucket 的”幽灵成本”来自历史版本。

可以先查看版本：

aws s3api list-object-versions --bucket my-bucket --prefix app/

再用生命周期清理非当前版本：

{
  "Rules": [
    {
      "ID": "expire-old-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

AbortIncompleteMultipartUpload 很容易被忽略。大文件上传失败后，分片可能长期留在 S3 里继续计费。

5. 请求优化：LIST 比你想象中贵

在 S3 Standard 中，PUT/COPY/POST/LIST 这类请求常见价格约 $0.005/1,000 requests，GET 常见约 $0.0004/1,000 requests。单价看起来低，但对象数量上亿时，扫描式 LIST 会很贵，也会拖慢系统。

实务建议：

• 避免用 ListObjectsV2 当数据库查询。
• 对象 key 设计加入日期、租户、业务前缀，减少无意义扫描。
• 用 S3 Inventory 替代全量 LIST。
• 对热点小对象做合并或缓存，减少 GET 风暴。

6. 用 VPC Endpoint 避免 NAT Gateway 绕路

私有子网里的 EC2、ECS、Lambda 访问 S3，如果路由走 NAT Gateway，会产生 NAT 数据处理费。us-east-1 常见 NAT Gateway 价格是约 $0.045/hour 加 $0.045/GB processed，1TB/月仅 NAT 处理费就约 $45。

访问 S3 和 DynamoDB 时，优先配置 Gateway VPC Endpoint：

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxx \
  --vpc-endpoint-type Gateway

Gateway Endpoint 本身通常不收小时费，也能减少经 NAT 的流量。改完后要检查 route table，确认 S3 prefix list 指向 endpoint。

7. 压缩：应用侧压缩 vs 透明网关

压缩是最直接的容量优化，但要看数据类型。Parquet、ORC、gzip 后的日志、图片、视频通常已经压缩，收益有限；JSON、CSV、文本日志、未压缩对象、部分备份文件，可能有明显收益。

应用侧压缩的优点是架构简单、没有额外网关；缺点是要改代码、处理兼容性、迁移历史数据。另一种方式是透明压缩网关：让应用仍然使用 S3 API，把客户端指向网关，由网关负责压缩后写入 S3。

S4（Squished S3） 就属于后一类。它是包含 NVIDIA nvCOMP GPU codec 的 EC2 AMI，运行在 g4dn/g5/g6 等 GPU 实例上；S3 客户端指向透明网关后，对可压缩数据通常可以减少 50% 到 80% 的 S3 存储字节，应用无需改代码。它不是所有场景都合适：如果数据已经压缩、对象很小、请求极高但容量不大，收益可能不明显。适合评估的场景是：S3 中有大量文本/半结构化数据，容量成本是主要矛盾，同时不想改应用。

可以先用 S4 成本试算工具 做粗算；它不要求上传自己的账单 CSV，也可以用样例数据试。

最后：先测量，再改策略

推荐落地顺序：

1. 用 Cost Explorer 找到 S3 的主要 usage type。
2. 用 S3 Storage Lens 看 bucket、prefix、版本、对象大小分布。
3. 先清理版本和未完成 multipart。
4. 再做生命周期、Endpoint、请求优化。
5. 最后评估压缩或替代架构。

S3 降本不是”全部转冷”这么简单。真正有效的做法，是把数据访问模式、对象大小、请求路径和保留周期放在一起看。

开示：本文作者来自 abyo software（AWS Marketplace 上的成本优化产品 S4 的开发方）。