Why S3 Intelligent-Tiering Isn't Enough (And What To Do Instead)

Whenever we talk to a team about S3 costs, the first question is usually: “Why not just turn on Intelligent-Tiering?” It's a fair question. Intelligent-Tiering is AWS's own answer to storage tiering, it requires no analysis, and it can't produce retrieval-fee surprises. For many buckets it's genuinely better than doing nothing.

But “better than nothing” and “optimal” are far apart. Here's where the gap comes from.

1. The monitoring fee punishes small objects

Intelligent-Tiering charges $2.50 per million monitored objects per month. That sounds negligible until you do the division: for objects averaging 100KB, the monitoring fee alone is equivalent to ~$0.025/GB-month — more than the entire cost of just leaving the data in Standard. This is why AWS excludes objects under 128KB from auto-tiering entirely: below that size the fee can never pay for itself. Buckets full of thumbnails, logs, JSON documents, or ML features — exactly the buckets that grow uncontrollably — benefit the least.

2. It reacts to inactivity; it doesn't model costs

Intelligent-Tiering's logic is a timer: 30 consecutive days without access moves an object to the IA tier, 90 to Archive Instant Access. It never asks whether the move is economically correct for that object's actual pattern. An object read reliably once every 45 days will ping-pong: demoted at day 30, promoted on the day-45 read, demoted again at day 75 — capturing little savings while the monitoring fee accrues. A cost model that sees “8 reads per year, like clockwork” would simply price both tiers over a year and pick the cheaper one.

3. The deep-archive tiers are opt-in and blunt

The 20x savings of Deep Archive territory require explicitly opting into the Archive Access and Deep Archive Access tiers, with age thresholds (90+ / 180+ days without access) applied bucket-wide. Opt in aggressively and objects that occasionally get read land in tiers with hours-long restore times — a production incident waiting to happen. Most teams therefore never opt in, leaving the biggest savings untouched. Per-object decisions based on access history — “this object has never been read since upload, archive it; this one gets read quarterly, keep it instant” — capture those savings without the risk.

4. One bucket, one policy

Intelligent-Tiering configuration applies per bucket (or per filter). But buckets are organizational units, not access-pattern units. A single “media” bucket typically contains hot serving assets, warm originals, and ice-cold processed intermediates. Any single policy is wrong for at least one of them.

What optimal looks like

None of this is a knock on AWS — Intelligent-Tiering has to be safe for every customer without seeing retrieval intent, so it's conservative by design. But if you have access history, you can do strictly better:

• Per-object decisions from real read frequencies, not bucket-wide timers.
• Full cost modeling — storage price, retrieval fees, transition request costs, and minimum-duration penalties, compared across all eight classes.
• Direct use of the cheap tiers — Glacier Instant Retrieval and Deep Archive as first-class destinations for objects whose history justifies them, without monitoring fees.
• Reversibility — objects that warm back up get promoted, because the model keeps watching.

That's the loop TierPilot runs: your access logs are aggregated and anonymized inside your own account, our optimizer scores every object against every tier, and the in-account operator executes only moves with provable positive ROI. Intelligent-Tiering is a good default. A cost model with your actual data isn't a default — it's an answer.