S3自动优化策略：即使不了解访问模式也能降低成本

在AWS上初学S3时，通常会从S3 Standard开始。因为它最常见、性能好、可用性高，最重要的是易于理解。然而，进入实际运营环境后，情况会有些不同。最初以为会频繁访问的数据，几周后可能几乎不再被读取；反之，原以为只用于存储的数据，却可能因为分析任务或客户请求而突然再次被频繁读取。

此时，困扰便开始了。

“我应该继续将这些数据保留在Standard中吗？”

“30天后可以将其移至Standard-IA吗？”

“如果发送到Glacier，成本会降低，但如果以后需要立即读取怎么办？”

“如果按文件夹设置生命周期策略，它会同样应用于所有对象，但如果每个对象的访问模式不同怎么办？”

S3 Intelligent-Tiering就是这样一种能减轻这些困扰的存储类。顾名思义，S3会监控对象的访问模式，并根据访问频率自动将其移动到适当的内部层。用户无需为每个对象手动判断‘这是频繁访问的数据’、‘这是30天后不常查看的数据’或‘这是90天后主要用于归档的数据’。

一句话总结如下：

S3 Intelligent-Tiering是一种存储类，它针对难以预测访问模式的数据，由S3以对象为单位监控使用频率，并自动优化成本。

S3 Standard就像‘总是放在桌上的文件’。随时可以立即查看，但将所有文件都放在桌上会产生高昂的空间成本。

Standard-IA类似于‘放在桌旁文件柜里的文件’。存储成本略有降低，但取出时可能会产生费用。

Glacier Flexible Retrieval或Deep Archive更像是‘送到仓库的文件’。存储成本非常低，但取出需要时间。

Intelligent-Tiering可以看作是‘根据文件使用频率，自动将其移动到桌面、文件柜或附近存储空间的管理员’。经常查看的文件放在桌上，一段时间未查看的文件移到文件柜，长期未查看的文件移到更便宜的存储位置。但如果突然再次需要，它会再次将其放回桌上。

S3存储类选择困难的原因

S3有多种存储类。S3 Standard适用于频繁访问的数据；对于不常访问但需要时能快速读取的数据，可以考虑Standard-IA或One Zone-IA。如果归档性质较强，还有Glacier Instant Retrieval、Glacier Flexible Retrieval、Glacier Deep Archive等选项。

问题在于，人类很难准确预测数据的未来访问模式。

例如，考虑一个Web服务的图片文件。上传后，用户会频繁查看。但随着时间推移，大多数图片几乎不再被访问。然而，有些图片可能会在搜索结果中显示、在活动页面中再次使用，或因客户咨询而再次被读取。将所有图片都放在Standard中成本高昂；而过早地将所有图片移至IA或Glacier，则可能在后续读取时面临检索费用或恢复延迟的问题。

日志数据也一样。应用程序日志、安全日志、分析日志在最初的几天或几周内可能会被频繁查询。一旦故障分析或安全事件调查完成，访问频率会急剧下降。但由于审计、取证、合规性或客户问题响应，几个月后仍有可能再次被查询。

数据湖也类似。有些分区每天用于分析查询，而有些分区则几乎不被读取。即使在同一个存储桶、同一个前缀下，每个对象的访问频率也可能不同。

在这种环境下，仅凭生命周期策略很难实现完美的优化。生命周期功能强大，但它本质上是基于规则的。例如，设定“创建30天后移至Standard-IA”、“90天后移至Glacier”等。它根据对象的年龄、前缀、标签等条件进行移动，而非数据的实际访问情况。

相比之下，Intelligent-Tiering是根据“是否实际被访问”而非“时间是否已过”来判断的。这个区别至关重要。

Intelligent-Tiering备受青睐的原因

1. 不了解访问模式也能开始使用

S3 Intelligent-Tiering最大的优点是无需了解访问模式。运维人员无需预测每个对象的使用模式。它特别适用于访问模式多变或难以预测的数据，例如新服务、数据湖、用户上传内容、备份数据和分析数据。

S3 Standard是安全的选择，但长期来看可能成本较高。Standard-IA存储成本较低，但读取时会产生检索费用。Glacier系列更便宜，但需要考虑恢复时间或最短存储期限。Intelligent-Tiering减轻了这些选择的负担。

数据最初存储在频繁访问层，如果一段时间内没有访问，则会自动移动到更便宜的内部层。如果之后再次被访问，它会再次回到频繁访问层。运维人员无需细致判断“何时移动”。

2. 以对象为单位进行判断

Intelligent-Tiering的核心是对象级优化。

如果生命周期策略按前缀设置，同一文件夹内的对象会类似地移动。但实际上，即使在同一路径下，有些对象会被频繁读取，有些则几乎不被读取。Intelligent-Tiering会单独监控每个对象的访问模式。

例如，假设有以下数据：

images/2026/01/a.jpg每天被访问
images/2026/01/b.jpg40天内无访问
images/2026/01/c.jpg100天内无访问

即使这三个对象位于相同的前缀下，Intelligent-Tiering也不会同等处理。频繁访问的对象会保留在频繁访问层，30天以上未访问的对象会移至不频繁访问层，90天以上未访问的对象会移至归档即时访问层。

这种结构在成本优化方面非常有利。因为S3是根据每个对象的访问情况进行判断，而不是由人工进行文件夹级别的笼统判断。

3. 频繁访问、不频繁访问、即时归档层可无性能损失使用

Intelligent-Tiering的自动分层可以大致理解为三种：

频繁访问层 (Frequent Access tier)
不频繁访问层 (Infrequent Access tier)
归档即时访问层 (Archive Instant Access tier)

这三个层级是自动管理的，提供低延迟和高吞吐量。这意味着即使数据移动到不频繁访问层或归档即时访问层，应用程序也无需先发出恢复请求。它可以通过常规的GET请求直接读取。

这一点与Glacier Flexible Retrieval或Glacier Deep Archive有很大不同。Glacier Flexible Retrieval或Deep Archive成本较低，但并非用于即时读取。对象必须先恢复，并且需要考虑恢复时间。相比之下，Intelligent-Tiering的归档即时访问层，顾名思义，是一个可即时访问的归档性质层级。

因此，Intelligent-Tiering非常适合“希望降低成本，但可能需要突然读取的数据”。

4. 无检索费用

Standard-IA、One Zone-IA、Glacier Instant Retrieval等存储类存储成本较低，但读取数据时可能会产生检索费用。因此，如果访问频率高于预期，检索费用可能会超过存储成本节省。

Intelligent-Tiering在内部层级之间移动后也没有检索费用。即使读取不频繁访问层或归档即时访问层中的对象，也不会收取常规检索费用。此外，Intelligent-Tiering内部层级移动时也没有额外的分层费用。

当然，S3请求费用、数据传输费用、PUT/COPY/生命周期转换费用等一般费用因素需要单独考虑。但“移至IA后每次读取都会产生检索费用”的负担不存在，这是Intelligent-Tiering的一大优势。

5. 最短存储期限负担小

Standard-IA或One Zone-IA需要考虑最短存储期限。Glacier系列也有最短存储期限。过早删除或移至其他存储类可能会产生剩余期限的费用。

Intelligent-Tiering在常规自动分层操作中没有最短存储期限的负担。这一点对于数据生命周期不确定的服务尤其有用。例如，用户上传文件何时删除未知，或分析数据存储期限随项目情况而异，这种没有最短存储期限的结构在运营上更为便捷。

Intelligent-Tiering如何监控和决策？

要理解Intelligent-Tiering的运作方式，需要区分“存储类”和“内部访问层”。

对象的存储类是S3 Intelligent-Tiering。即使对象在30天后移至不频繁访问层，或在90天后移至归档即时访问层，用户看到的存储类本身也不会变为Standard-IA或Glacier Instant Retrieval。

也就是说，对象始终属于Intelligent-Tiering存储类，只是其内部访问层发生了变化。

基本流程

当对象存储到S3 Intelligent-Tiering时，它最初会从频繁访问层开始。之后，S3会监控对象的访问模式。

如果一段时间内没有访问，则会按如下方式移动：


条件	移动结果
对象上传或转换后立即	频繁访问层
连续30天无访问	不频繁访问层
连续90天无访问	归档即时访问层
从不频繁或即时归档状态再次访问	自动返回频繁访问层

这个流程可以用伪代码表示如下：

객체가 S3 Intelligent-Tiering에 저장됨
  → Frequent Access tier에서 시작

객체 크기가 128KB 미만이면
  → 자동 티어링 대상 아님
  → 감시하지 않음
  → 감시 및 자동화 요금 없음
  → Frequent Access tier 요금으로 유지

객체 크기가 128KB 이상이면
  → S3가 객체 단위 접근 패턴 감시

30일 연속 접근 없음
  → Infrequent Access tier로 이동

90일 연속 접근 없음
  → Archive Instant Access tier로 이동

Infrequent Access 또는 Archive Instant Access 상태에서 객체 접근 발생
  → Frequent Access tier로 자동 이동

这里重要的标准是“连续未访问期限”。它不是简单地在对象创建30天后无条件移动，而是根据未访问的期限进行判断。

哪些行为被视为“访问”？

S3在判断Intelligent-Tiering的层级移动时，并非将所有API调用都同等视为访问。实际读取或写入对象数据的操作才被视为访问。

例如，通常以下操作被视为已访问对象：

从控制台下载对象
从控制台复制对象
GetObject
PutObject
CopyObject
UploadPartCopy
RestoreObject
CompleteMultipartUpload
通过S3 Batch Replication进行复制

另一方面，以下操作不被视为会将对象提升到频繁访问层的访问：

HeadObject
GetObjectTagging
PutObjectTagging
ListObjects
ListObjectsV2
ListObjectVersions
UpdateObjectEncryption

这种区别在实际操作中很重要。例如，如果仅仅是查询列表或查看元数据就导致所有对象都回到频繁访问层，那么成本优化将变得困难。因此，S3区分了实际数据访问和管理性操作。

实际读取或写入文件内容的行为被视为访问，

简单的列表查询或标签查询等管理性操作不被视为访问。

如果启用可选归档层会怎样？

Intelligent-Tiering基本提供三个自动层级。

频繁访问层 (Frequent Access tier)
不频繁访问层 (Infrequent Access tier)
归档即时访问层 (Archive Instant Access tier)

到目前为止，这些都是可即时访问的层级。但是，如果您希望获得更低的成本，并且不需要立即读取数据，则可以额外启用可选归档层。

可选归档层如下：

归档访问层 (Archive Access tier)
深度归档访问层 (Deep Archive Access tier)

归档访问层可用于至少90天未访问的对象，深度归档访问层可用于至少180天未访问的对象。根据设置，这些期限还可以调整得更长。

但是，这两个层级并非用于即时访问。如果对象进入归档访问层或深度归档访问层，则必须通过RestoreObject进行恢复才能读取。因此，如果您的应用程序需要立即读取文件，则应谨慎使用这些层级。

总结如下：


类别	是否可即时访问	说明
频繁访问	是	基本层
不频繁访问	是	30天未访问后自动移动
归档即时访问	是	90天未访问后自动移动
归档访问	需要恢复	可选启用，分钟到小时级恢复
深度归档访问	需要恢复	可选启用，用于长期存储

在运营环境中，不应无条件启用归档访问和深度归档访问，而应根据数据的使用方式来决定。特别是对于需要即时访问的数据，例如用户下载、Web服务图片、分析查询目标数据，仅使用基本的三层可能更安全。

监控费用如何计算？

Intelligent-Tiering会监控对象的访问模式并执行自动移动，因此会产生每月监控和自动化费用。以美国东部（弗吉尼亚北部）为例，监控和自动化费用为每1,000个对象每月0.0025美元。

按对象数量换算如下：


对象数量	每月监控和自动化费用
1,000个	0.0025美元
100,000个	0.25美元
1,000,000个	2.50美元
10,000,000个	25.00美元
100,000,000个	250.00美元

仅看这笔费用似乎很小。但如果对象数量增长到数亿个以上，这可能成为一笔不可忽视的费用。特别是对于对象数量非常多的结构，如小型日志文件、缩略图、IoT事件片段，必须进行计算。

但是，小于128KB的对象不属于自动分层对象，也不会收取监控和自动化费用。这些小对象可以存储在Intelligent-Tiering中，但始终按频繁访问层的费率计费。

因此，在查看成本时，不仅要看“总容量”，还要看“对象数量”。这是S3成本优化中常见的错误。存储10TB数据，但对象数量是10万个和10亿个，在监控费用方面是完全不同的。

生命周期与Intelligent-Tiering是竞争关系吗？

生命周期策略和Intelligent-Tiering并非相互竞争的功能，而是目的不同。

生命周期是基于策略的自动化。例如，它应用明确的规则，如“logs/前缀下的对象在30天后移至Standard-IA，90天后移至Glacier Deep Archive”。如果您已经了解数据的生命周期和访问模式，生命周期可能更简单、更便宜。

相比之下，Intelligent-Tiering是基于观察的自动化。S3会监控每个对象的访问模式，如果长时间没有访问，则会自动将其移至更便宜的层级。当访问模式不确定或每个对象不同时，它更具优势。

两者比较如下：


类别	生命周期	Intelligent-Tiering
标准	创建后经过天数、前缀、标签等	对象访问模式
优点	适用于可预测数据	适用于难以预测数据
缺点	无论实际访问与否都可能移动	存在监控和自动化费用
适用示例	日志、备份、法规要求长期存储数据	数据湖、用户上传、新服务数据
操作方式	人工设计规则	S3自动判断每个对象

如果访问模式明确，设计生命周期策略；

如果访问模式不确定，考虑Intelligent-Tiering。

在什么情况下选择Intelligent-Tiering？

新服务的用户上传数据

在新服务中，很难预测哪些数据会被读取的频率。用户上传的图片、文档、视频、附件在初期通常会被频繁访问，但随着时间推移，访问频率往往会降低。然而，有些内容可能会在以后再次流行，或因客户咨询而被查看。

在这种情况下，从一开始就将其发送到Standard-IA或Glacier会带来负担。使用Intelligent-Tiering，可以在初期像Standard一样快速访问，然后只有访问量减少的对象才会自动移至更便宜的层级。

数据湖和分析数据

数据湖中混合了各种数据。有些数据每天用于分析查询，而有些数据仅作为历史记录保留。访问频率可能因分区、日期、客户或服务而异。

仅凭生命周期策略准确分类所有数据会使规则变得复杂。Intelligent-Tiering以对象为单位监控访问模式，因此非常适合数据湖这种访问频率多变的环境。

安全日志和审计数据

安全日志在事件发生后会频繁查询，但随着时间推移，几乎不再被查询。然而，由于合规性或入侵事件调查，以后可能再次需要。也就是说，它接近于“平时不常看，但需要时必须立即访问的数据”。

在这种情况下，即使自动降级到归档即时访问层也能即时访问的Intelligent-Tiering可能很有用。但是，如果启用了可选的归档访问或深度归档访问，则需要恢复时间，因此应首先确认安全监控或事件响应要求。

访问模式尚不明确的迁移数据

将大量数据从本地迁移到S3时，Intelligent-Tiering也是一个很好的起点。因为通常不清楚现有文件服务器或NAS的访问模式。

盲目地将其保留在Standard中成本高昂，盲目地将其发送到Glacier可能会在以后导致业务中断。将Intelligent-Tiering设置为默认值，可以通过观察实际访问模式自动降低成本。

何时应避免使用Intelligent-Tiering？

Intelligent-Tiering并非总是最佳选择。

如果数据始终被频繁读取

如果所有对象都持续被频繁读取，Intelligent-Tiering的优势就不大。对象很可能会一直停留在频繁访问层。在这种情况下，您可能需要支付与S3 Standard相似的存储费用，并额外支付监控费用。

对于始终是热数据的情况，例如Web服务的核心静态资源、每次都被读取的模型文件、频繁引用的配置文件，Standard可能更简单。

如果访问模式明确

例如，如果数据的生命周期明确，如“此日志仅在7天内频繁查看，30天后几乎不查看，1年后删除”，那么生命周期策略可能更适合。

如果数据可以按照既定规则移动，则可能没有必要支付监控费用来使用Intelligent-Tiering。

如果存在过多非常小的对象

小于128KB的对象可以存储在Intelligent-Tiering中，但它们不属于自动分层对象。虽然不收取监控费用，但它们始终按频繁访问层的费率计费。这意味着Intelligent-Tiering不会自动大幅降低大量小对象的成本。

在存在大量小对象的环境中，对象合并、压缩、分区、日志格式改进等数据结构优化可能更为重要。

如果需要即时访问却启用了可选的深度归档层

Intelligent-Tiering的默认自动层——归档即时访问层——是可即时访问的。但可选的归档访问层和深度归档访问层需要恢复过程。如果应用程序需要立即读取对象，而您启用了深度归档访问层，则可能会出现类似故障的情况。

因此，可选归档层应仅应用于“确实可以接受恢复延迟的数据”，以确保安全。

实际应用示例

要将新上传的对象存储到Intelligent-Tiering，可以在PUT请求中指定存储类。

aws s3api put-object 
  --bucket my-bucket-name 
  --key uploads/sample.jpg 
  --body ./sample.jpg 
  --storage-class INTELLIGENT_TIERING

您也可以通过将现有对象复制到Intelligent-Tiering来更改存储类。

aws s3api copy-object 
  --bucket my-bucket-name 
  --copy-source my-bucket-name/uploads/sample.jpg 
  --key uploads/sample.jpg 
  --storage-class INTELLIGENT_TIERING 
  --metadata-directive COPY

您还可以通过生命周期策略为存储桶的特定前缀应用Intelligent-Tiering转换。例如，要将uploads/下的对象在创建0天后转换为Intelligent-Tiering，可以使用以下策略：

{
  "Rules": [
    {
      "ID": "transition-to-intelligent-tiering",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "uploads/"
      },
      "Transitions": [
        {
          "Days": 0,
          "StorageClass": "INTELLIGENT_TIERING"
        }
      ]
    }
  ]
}

应用方式如下：

aws s3api put-bucket-lifecycle-configuration 
  --bucket my-bucket-name 
  --lifecycle-configuration file://lifecycle.json

在实际操作中，最好根据前缀或标签进行划分，而不是无条件地应用于整个存储桶。例如，用户上传文件使用Intelligent-Tiering，静态Web资源使用Standard，明确的长期存储日志通过生命周期发送到Glacier Deep Archive。

成本判断的简单清单

在应用Intelligent-Tiering之前，最好问自己以下问题：

您能准确预测此数据的访问模式吗？
每个对象的访问频率是否差异很大？
以后是否有可能突然再次读取？
不可预测的检索费用是否让您感到担忧？
对象数量是否过多，导致监控费用过高？
大多数对象是否小于128KB？
如果启用了可选的归档访问或深度归档访问，您能承受恢复延迟吗？
此数据是否可以通过生命周期策略更简单、更便宜地解决？

如果对这些问题，您有很多回答是“不清楚访问模式”、“每个对象的使用频率不同”、“有可能再次读取”、“运维人员难以每次调整策略”，那么Intelligent-Tiering很可能是一个不错的选择。

反之，如果模式明确，例如“总是频繁读取”、“90天后绝对不再读取”、“存储1年后删除”，那么Standard或基于生命周期的转换可能更适合。

结论：Intelligent-Tiering是一种承认未知的设计

在云成本优化中，最危险的是错误的确定性。“我以后不会看这些数据了”的想法，实际上可能被频繁读取；“这些数据会一直需要”的想法，可能几个月都没人看一眼。

S3 Intelligent-Tiering就是一种以这种不确定性为前提设计的存储类。它不是由人工预测所有访问模式，而是由S3以对象为单位监控访问情况，并自动将其移动到适当的层级。

因此，Intelligent-Tiering不仅仅是一个“便宜的存储类”。更准确地说，它是一种“针对难以预测数据访问模式的自动成本优化策略”。

可以这样总结：

如果访问模式明确，设计生命周期策略。
如果访问模式不确定，考虑Intelligent-Tiering。
如果需要即时访问，仅使用基本自动层。
如果用于长期存储且可承受恢复延迟，则考虑可选的归档/深度归档层。
务必检查对象数量和小于128KB对象的比例。

S3成本优化的核心并非无条件选择最便宜的存储类。它是在综合考虑数据访问方式、恢复要求、请求费用和运营复杂性后，降低总体成本。从这个角度看，S3 Intelligent-Tiering是一个非常实用的选择，它让“运维人员无需准确预测未来”。

S3 Intelligent-Tiering为何备受青睐？