S3 Intelligent-Tiering: when it saves and when it doesn’t

I turned on S3 Intelligent-Tiering across a 400 TB bucket expecting an instant win, and the first month's bill barely moved. The second month it moved a lot. Intelligent-Tiering is genuinely useful, but it is not free money, and on the wrong objects it can quietly cost you more than plain Standard storage.

This is my mental model for when to reach for it and when to use lifecycle rules instead.

What Intelligent-Tiering actually does

It monitors access patterns per object and moves each between tiers automatically: Frequent Access, Infrequent Access (after 30 days no access), and optionally Archive Instant Access (90 days), plus opt-in async archive tiers. There are no retrieval fees and no minimum storage duration on the core tiers, which is the headline benefit over manually using S3 Standard-IA.

The catch is the monitoring and automation charge: a per-object monthly fee (around $0.0025 per 1,000 objects). That fee is fixed regardless of object size, which is the whole story for when it pays off.

The break-even is about object size, not access

Because the monitoring fee is per object, tiny objects are where Intelligent-Tiering loses. A 128 KB object that drops to Infrequent Access saves you a fraction of a cent in storage, but you still pay the same monitoring fee as a 5 GB object.

Below 128 KB, objects are never charged the lower IA rate anyway, and you still pay monitoring. A bucket full of tiny objects on Intelligent-Tiering is a quiet loss.

Rough guidance I use:

Turning it on without surprises

You can set it as the default storage class on PutObject, or convert existing objects with a lifecycle transition. I prefer the lifecycle approach so I can scope it with a filter and exclude small objects.

{
  "Rules": [
    {
      "ID": "to-intelligent-tiering",
      "Status": "Enabled",
      "Filter": {
        "And": {
          "Prefix": "datasets/",
          "ObjectSizeGreaterThan": 131072
        }
      },
      "Transitions": [
        { "Days": 0, "StorageClass": "INTELLIGENT_TIERING" }
      ]
    }
  ]
}

The ObjectSizeGreaterThan filter (128 KB here) is the part people miss. It keeps the long tail of tiny objects out of the monitored set.

Adding the archive tiers

For data that goes truly cold, opt into the asynchronous archive tiers. These behave like Glacier (retrieval latency in minutes to hours) but stay inside the same storage class. Configure them per bucket:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket my-data-lake \
  --id archive-cold \
  --intelligent-tiering-configuration '{
    "Id": "archive-cold",
    "Status": "Enabled",
    "Tierings": [
      { "Days": 90,  "AccessTier": "ARCHIVE_ACCESS" },
      { "Days": 180, "AccessTier": "DEEP_ARCHIVE_ACCESS" }
    ]
  }'

Only enable these if your application tolerates asynchronous retrieval. A serving path that occasionally reads an object will hit a multi-hour restore and look like an outage.

How to know it is working

Do not trust intuition; look at the data. S3 Storage Lens shows the breakdown of bytes per tier, and Cost Explorer with the usage-type filter (IntelligentTieringFAStorage vs IntelligentTieringIAStorage) tells you how much actually demoted to the cheaper tier. If almost nothing demotes, your data is hotter than you thought and you are paying monitoring for nothing.

Takeaways

• The monitoring fee is per object and size-independent, so Intelligent-Tiering wins on large objects and loses on tiny ones.
• Use an ObjectSizeGreaterThan lifecycle filter (~128 KB) to keep the long tail of small files out of the monitored set.
• For predictably cold data with known timelines, plain lifecycle transitions to IA or Glacier are cheaper and more deterministic.
• Verify demotion with Storage Lens and Cost Explorer usage types before assuming the savings are real.