对象存储按访问频率划分存储层级，是云上降本最常见的手段之一。但分层不是简单地"把冷数据挪到便宜层"，取回成本、最小存储时长和请求费用常常决定最终账单。本文以主流云厂商（AWS S3、阿里云 OSS、腾讯云 COS）的公开计费逻辑为基础，梳理三档存储的成本结构与迁移策略。
三档存储的定位
- 标准存储：面向频繁访问的热数据。单位容量价格最高，但取回免费、无最小存储时长，请求费用最低。
- 低频存储：面向月级访问的数据（如备份、日志）。容量单价明显低于标准层，但通常有 30 天最小存储时长，提前删除按剩余天数计费；取回按量收费。
- 归档存储：面向几乎不访问的长期留存（合规、审计）。容量单价最低，但取回需要解冻（分钟到小时级），且取回费用和请求费用最高，最小存储时长通常为 90 天或 180 天。
具体单价、最小存储天数和取回延迟各厂商不同，且会调整，务必以官网计费文档为准，不要套用旧文章里的数字。
成本不能只看单价
总成本 ≈ 容量费 + 请求费 + 取回费 + 提前删除费。几个容易踩的坑：
- 小文件高频访问：低频层的 PUT/GET 请求单价高于标准层。如果一个对象平均只有几十 KB 却每天被读，转低频反而更贵。
- 频繁改写的"冷数据"：对象每次覆盖写入都会重置最小存储时长计时，反复覆盖的低频/归档对象可能被持续计费。
- 取回量大的归档数据：归档取回按 GB 计费，一次大规模恢复可能超过多年省下的容量费。
- 生命周期规则不清理碎片：未完成的分片上传、多版本历史版本会持续占容量。
判断是否值得分层，可先估算：年访问次数 × 单次取回成本，与容量差价对比。访问次数极低才适合归档。
迁移策略
1. 用生命周期规则自动流转
主流对象存储都支持基于前缀/标签的生命周期规则，典型配置：
- 上传后 30 天未访问 → 转低频
- 90 天未访问 → 转归档
- 到期后删除或转深度归档
规则基于"最后修改时间"或"最后访问时间"，后者需要开启访问追踪（如 S3 的 Intelligent-Tiering 或各家的访问日志分析），否则只能按对象年龄粗略判断。
2. 先观察再迁移
开启存储清单（Inventory）或访问日志，统计各前缀的读取频率、对象大小分布。很多团队发现 80% 的容量集中在少数几个从不读取的前缀上，优先处理这些收益最大。
3. 谨慎使用智能分层
AWS S3 Intelligent-Tiering、阿里云 OSS 的同类型功能可按访问模式自动升降层，适合访问模式不可预测的场景。注意它有监控与自动化费用，且对极小对象不划算。
4. 迁移时的操作要点
- 跨层转换通常通过生命周期规则或复制任务完成，不要用脚本逐个 GET+PUT，请求费会很高。
- 归档层对象无法直接读取，恢复前先确认解冻时间是否满足业务 RTO。
- 迁移后保留原数据一段时间，避免规则误删。
落地建议
先在测试桶上用生命周期规则跑一遍，用账单的"存储分层"明细验证效果，再推广到生产。分层优化的目标是让总账单下降，而不是让容量单价下降——这两者经常不是一回事。