Skip to content

AWS Updated 2026-07-04

S3 Intelligent-Tiering: when it saves money and when it just adds monitoring fees

S3 Intelligent-Tiering moves objects between access tiers automatically, but the per-object monitoring fee means it only pays off for larger objects. Here is how to decide.

S3 Intelligent-Tiering saves money when you store large objects whose access pattern you genuinely cannot predict, and it loses money when the bucket is full of small objects, because the monitoring fee is charged per object while the savings accrue per gigabyte. Average object size is the whole decision: multi-megabyte objects make the fee a rounding error, while millions of sub-megabyte objects can make the fee bigger than everything it saves. If you already know the access pattern, plain lifecycle rules do the same job for free.

What you are deciding

Intelligent-Tiering is one storage class with internal tiers. Every monitored object starts in the Frequent Access tier at Standard-like pricing. After 30 consecutive days without access it drops to Infrequent Access pricing, and after 90 days to Archive Instant Access pricing — all three keep millisecond reads, and touching an object moves it back to Frequent automatically. Two optional opt-in tiers, Archive Access and Deep Archive Access, go further but make objects asynchronous: reading them requires a restore first, which surprises applications that expect a normal GetObject to work.

What you pay for the automation: a monitoring and automation charge billed per 1,000 objects per month. What you do not pay: retrieval fees — this is the class’s genuine advantage over Standard-IA, where an unexpected read burst bills you per gigabyte. Objects smaller than 128 KB are never monitored, never charged the fee, and always billed at Frequent Access rates, so tiny objects gain exactly nothing here. There is also a 30-day minimum storage duration for the class as a whole.

So the decision is: is the per-object fee smaller than the per-gigabyte savings the automation will actually find? That depends on average object size, on how much of the data really goes cold, and on whether you could have known the pattern and written a lifecycle rule instead.

What to check first

  • Average object size. Total bytes divided by object count, per bucket or prefix. This single number decides most cases.
  • Whether the pattern is actually unknown. “Logs older than 90 days are never read” is a known pattern — that is a lifecycle rule, not Intelligent-Tiering.
  • Object lifetime. Objects deleted within 30 days are charged the minimum duration; short-lived data does not belong here.
  • Whether anything reads objects that could hit the opt-in archive tiers. If an application expects synchronous reads on everything, leave the archive tiers off.

How to verify

Get object count and total size to compute average object size:

# Count and total bytes for a bucket or prefix
aws s3 ls s3://my-bucket --recursive --summarize | tail -2

# Per-tier storage once Intelligent-Tiering is in use (CloudWatch)
aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name BucketSizeBytes \
  --dimensions Name=BucketName,Value=my-bucket Name=StorageType,Value=IntelligentTieringIAStorage \
  --start-time 2026-06-01T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 86400 --statistics Average

The StorageType dimension values IntelligentTieringFAStorage, IntelligentTieringIAStorage, and IntelligentTieringAIAStorage show how much data the automation has actually demoted — that distribution is your realized savings. In the console, S3 > your bucket > Metrics charts the same split, and S3 Storage Lens shows it fleet-wide. Model both scenarios with your region’s real prices at calculator.aws before moving anything.

The approach

  1. Compute average object size per prefix. As a working rule of thumb, objects in the multi-megabyte range and up make the monitoring fee negligible; objects in the low hundreds of kilobytes make it material. Run your own numbers — fees and storage prices vary by region.
  2. Split mixed buckets by prefix. Most real buckets contain both big media files and tiny JSON. Apply Intelligent-Tiering to the large-object prefixes and leave the small-object prefixes in Standard.
  3. Move data in with a lifecycle transition, not by re-uploading. A transition rule with an ObjectSizeGreaterThan filter shifts existing eligible objects and catches new ones.
  4. Leave the opt-in archive tiers off by default. Enable Archive Access and Deep Archive Access only for prefixes where an asynchronous restore step is acceptable, and only after checking every consumer of that data.
  5. Measure after 90 days. Compare the monitoring fee line against the tier distribution. If almost everything stayed in Frequent Access, the data was not cold and the fee bought nothing.

When this is the wrong move

If you can state the access pattern in one sentence, a lifecycle rule to Standard-IA or Glacier Instant Retrieval achieves the same savings with no monitoring fee. If the bucket is dominated by objects under 128 KB, Intelligent-Tiering is pure overhead management with no upside. If objects live less than 30 days, the minimum duration erases the point. And if the data is written once and legally retained for years without reads, go straight to a Glacier class — paying a monthly fee to “discover” that archives are cold is money down the drain.

Common mistakes

  • Enabling it bucket-wide on a bucket full of thumbnails, session files, or small logs, then watching the monitoring fee exceed the savings.
  • Turning on the opt-in archive tiers and breaking an application that expected every GetObject to return immediately.
  • Treating it as a substitute for lifecycle rules entirely — Intelligent-Tiering never deletes anything; expiration still needs its own rules.
  • Judging it after two weeks. Demotion starts at 30 days without access; the savings curve takes a full quarter to show its shape.

Keeping it under control

  • Review the tier-distribution metrics quarterly; a prefix stuck at 90%+ Frequent Access does not belong in the class.
  • Keep an ObjectSizeGreaterThan filter on every transition into Intelligent-Tiering.
  • Watch the monitoring-fee line in Cost Explorer (usage type contains Monitoring) as object counts grow.
  • Re-check any prefix whose workload changes — a new analytics job can pull an entire archive back to Frequent Access pricing.

Intelligent-Tiering is a good default for large objects with honestly unknown access, and a quiet tax everywhere else — the S3 documentation has the current per-region numbers to run before you commit. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.