S3 存储类详解：如何选择最具成本效益的方案

Amazon Simple Storage Service (S3) 是许多 AWS 工作负载的默认对象存储，因为它具有良好的可扩展性，并为不同的访问模式提供了多种存储类。然而，并非所有数据都被同等访问。将频繁访问的关键数据与不常访问的归档数据存储在同一个存储类中，可能会导致大量不必要的云支出。理解不同 S3 存储类之间的细微差别，对于设计成本优化的架构至关重要。

理解 S3 的持久性和可用性

在深入了解各个存储类之前，有必要先定义 S3 的两个核心指标：

• 持久性： 数据随时间保持完整的可能性。S3 针对给定类所使用的底层基础设施，设计为具有 99.999999999%（11 个 9） 的持久性。
• 可用性： 数据可被检索访问的时间百分比。通常按年衡量（例如 99.9%）。

这些指标会根据所选的特定存储类略有不同。

核心 S3 存储类：详细对比

AWS 提供了多种存储类，针对不同的访问频率和停机容忍度进行了优化。以下是常见选项的详细介绍。

1. S3 Standard

S3 Standard 是默认的通用存储类，最适合频繁访问的数据。

• 使用场景： 活跃数据、内容分发、动态生成的内容以及移动/游戏应用。
• 持久性： 11 个 9。
• 可用性： 99.99%（高可用性）。
• 检索时间： 毫秒级。
• 定价： 在频繁访问的层级中存储成本最高，但无检索费用。

最佳实践： 用于需要即时访问且延迟最低的数据。

2. S3 Intelligent-Tiering (S3-IT)

S3 Intelligent-Tiering 专为访问模式未知或变化的数据而设计。它会根据使用情况自动在多个访问层之间移动对象，从而在无需运营开销的情况下优化存储成本。

• 使用场景： 数据湖、访问模式不可预测的数据，或者希望在随时间优化成本的同时确保即时访问。
• 工作原理： 它会监控访问情况。如果一个对象连续 30 天未被访问，它将被移动到低频访问 (IA) 层。如果再次被访问，它将被移回高频访问层。
• 包含的层级： 高频访问、低频访问、归档即时访问（可选）。
• 成本因素： 除了存储成本（根据对象所在的层级而变化）外，还包括每对象每月的小额监控和自动化费用。

可行建议： 如果不确定数据会被多频繁地访问，S3 Intelligent-Tiering 通常能在成本节约和性能一致性之间提供最佳平衡。

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

此类适用于不常访问但需要快速检索的数据，类似于 S3 Standard-IA，但在可用性方面有重大区别。

• 使用场景： 次要备份、可重新创建的数据（例如，可以从源重新生成的数据），或者存储那些业务关键性不足以需要多 AZ 冗余的数据。
• 持久性： 11 个 9。
• 可用性： 99.5%（低于 Standard 的可用性）。
• 存储位置： 数据冗余存储在单个 AWS 可用区 (AZ) 中，而其他类则跨多个 AZ。
• 成本因素： 存储成本显著低于 Standard，但数据检索会产生费用。

⚠️ One Zone-IA 警告： 由于数据仅驻留在一个 AZ 中，如果该特定 AZ 发生灾难性事件（例如，重大电力故障或自然灾害），此层级中的数据可能会丢失。这就是为什么它只适用于非关键、易于替换的数据。

4. S3 Glacier 存储类（归档）

Glacier 存储类针对长期归档进行了优化，可接受几分钟到几小时的检索时间。

S3 Glacier Instant Retrieval (S3 Glacier IR)

它填补了低频访问和深度归档之间的空白。

• 使用场景： 每季度或更少访问一次的数据，但需要时需毫秒级检索（例如，医学影像、新闻媒体档案）。
• 检索时间： 毫秒级（与 IA 类延迟相似）。
• 成本因素： 存储成本非常低，但有检索费用。

S3 Glacier Flexible Retrieval (原 S3 Glacier)

这是一个长期归档选项，可接受几分钟到几小时的检索时间。

• 使用场景： 法规遵从性档案、极少需要的灾难恢复数据。
• 检索选项（及延迟）：
  • 加急：1–5 分钟
  • 标准：3–5 小时
  • 批量：5–12 小时
• 成本因素： 存储成本极低，但检索费用和耗时。

S3 Glacier Deep Archive

AWS S3 中成本最低的存储选项。

• 使用场景： 每年可能只访问一两次的数据，通常用于合规性。
• 检索选项（及延迟）：
  • 标准：12 小时
  • 批量：48 小时
• 成本因素： 最低的存储费率，最高的检索费用，以及最长的检索窗口。

如何选择：决策框架

选择合适的存储类取决于回答关于数据生命周期的三个关键问题：

问题	主要考量	推荐存储类路径
访问频率如何？	访问频率	频繁 $\rightarrow$ Standard；不频繁 $\rightarrow$ IA 或 Glacier
可接受的停机/数据丢失程度？	持久性/可用性	关键 $\rightarrow$ Standard/Intelligent-Tiering；可丢弃 $\rightarrow$ One Zone-IA
检索速度要求？	延迟要求	毫秒级 $\rightarrow$ Standard/Intelligent-Tiering/Glacier IR；小时级 $\rightarrow$ Glacier Flexible/Deep Archive

示例场景：公司媒体资产

一个营销团队每天上传数百个原始视频文件：

1. 当前编辑/宣传片（最近 30 天）： S3 Standard（高访问量，低延迟）。
2. 需要偶尔审查的旧资产（30 天至 1 年）： S3 Intelligent-Tiering（在初始热期后实现成本节约）。
3. 已完成、审计过的最终母版（超过 1 年）： S3 Glacier Deep Archive（成本最低，仅用于合规审计）。

示例场景：日志、备份和用户上传

一家公司通常有三种截然不同的 S3 模式。

对于应用日志，近期数据很有价值，因为工程师会在事件期间搜索它。事件窗口过后，大多数日志就变成了合规性或趋势数据。一个合理的生命周期可能是在 Standard 或 Standard-IA 中保留 30 到 90 天，将较旧的日志移动到归档层，并在固定的保留期后过期低价值的调试日志。具体数字应来自您的保留策略以及人们实际查询旧前缀的频率。

对于数据库备份，存储类应遵循恢复承诺。如果团队表示生产恢复必须在几分钟内开始，请将最新的备份保留在具有即时检索能力的类中。较旧的月度或年度副本可以转移到更冷的层级，如果它们是为了审计保留而非快速恢复。从所选类中测试恢复；一个从未被恢复过的备份策略主要是一个计费规则。

对于用户上传，访问更难预测。个人资料照片可能很小但被频繁获取。一个大的原始视频可能只被下载一次，转码后很少再被触及。将派生资产和原始文件存储在不同的前缀下，以便生命周期规则可以区别对待它们。不要让缩略图策略继承与数 GB 原始文件相同的归档规则，除非产品确实需要这样。

更改存储桶前要问的问题

在添加生命周期规则之前，请问谁读取数据、如何读取，以及如果检索延迟会发生什么。工程师通常更了解写入路径而非读取路径，因为上传是应用程序的一部分，而读取发生在之后，通过分析、支持工具、合规性导出或手动事件响应。

查找扫描旧前缀的批处理作业。一个每晚列出每个对象、打开元数据或采样旧文件的作业，可能会抵消部分来自更冷层级的成本节约。如果作业只需要清单，S3 Inventory 可能比重复列出存储桶更好。如果分析师使用 Athena 查询日志，在将数据移动到需要恢复步骤的类之前，请考虑分区布局和压缩。

注意对象大小。具有最小计费对象大小的存储类可能不适合大量小文件。在这些情况下，将数据压缩成更大的对象、使用 Parquet 进行分析或过期不必要的对象，可能比切换存储类更有效。

最后，以在事件期间可以解释的方式编写生命周期规则。一个名为 archive-old-logs-after-90-days 的前缀规则比一个静默地在 30 天后移动所有内容的存储桶级规则更容易推理。成本优化应使系统更便宜，而不会使恢复变得神秘。

另一个实际检查是所有权。在实际账户中，存储桶所有者、上传账户、复制角色和分析账户并不总是相同的。在将数据移动到归档类之前，请确认谁可以恢复它以及谁支付检索费用。具有 KMS 加密的跨账户存储桶在恢复时可能会失败，如果需要对象的角色可以列出存储桶但无法使用密钥。这在审计期间会是一个糟糕的意外。

版本控制也会改变计算方式。生命周期规则可以不同地转换或过期当前版本和非当前版本。如果应用程序每小时覆盖同一个键，非当前版本可能成为存储桶中最大的部分。单独审查它们，而不是假设当前对象计数能说明全部情况。

实施生命周期策略

手动在类之间移动对象效率低下。跨这些层级管理成本的最有效方法是使用 S3 生命周期策略。

生命周期策略允许您定义规则，这些规则会在指定天数后自动将对象转换到更冷的存储层或永久过期。

示例生命周期规则（转换）：

<Rule>
    <ID>Move_to_IA_After_30_Days</ID>
    <Status>Enabled</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

此配置会自动将 logs/ 前缀下的任何对象在创建 30 天后移动到 Glacier Instant Retrieval，从而显著降低长期存储成本，同时在需要时保持快速检索能力。

人们容易忽略的成本陷阱

存储类的决策不仅仅是每月的每 GB 比较。检索费用、请求费用、最短存储期限、最小计费对象大小、复制、生命周期转换请求和监控费用都可能改变答案。一个包含数百万个键的小对象归档与少量大型备份文件的行为可能截然不同。

例如，应用日志通常写入一次且很少读取，因此从 Standard 到 Glacier Instant Retrieval 或 Glacier Flexible Retrieval 的生命周期规则可能是有意义的。但是，如果您的事件响应流程经常使用 Athena 扫描旧日志，激进的归档可能会导致缓慢的恢复和意外的检索成本。在这种情况下，按日期分区日志、过期高噪音低价值的前缀，并将最近几个月保留在适合查询的类中，可能比盲目地在 30 天后将所有内容变冷更能节省成本。

备份有不同的形态。每月测试一次的数据库转储需要可预测的恢复行为。如果您的恢复时间目标以分钟计，那么 Deep Archive 可能不是存储唯一可恢复副本的正确位置，即使它在静止时很便宜。如果同一个转储是仅用于审计保留的第三个副本，那么 Deep Archive 可能是合理的。

媒体团队通常需要不可预测的旧资产。对于这些未知模式，Intelligent-Tiering 可以是一个很好的默认选择，尤其是当对象足够大以至于监控费用不是决定性因素时。对于大量的小缩略图，在您到处启用它之前，需要更仔细地审视费用和最小对象大小行为。

一个实用的选择方法是抽样一个存储桶，导出 S3 Inventory，按前缀、对象计数、总字节数、最后修改日期和已知访问模式进行分组，然后为每个前缀编写生命周期规则。除非存储桶确实只包含一种数据，否则避免使用一个存储桶级规则。