S3 Storage Tiering: Pushing Cold Data Down the Ladder

S3 storage tiering is the practice of moving objects from hot, expensive storage classes to colder, cheaper ones as access frequency drops, using lifecycle rules. It cuts your recurring storage bill without deleting a single byte. Standard sits at the top of the ladder, Glacier Deep Archive at the bottom.

Class	Min storage duration	Retrieval charge	First-byte latency	Notes
S3 Standard	None	None	Milliseconds	General-purpose hot data
S3 Intelligent-Tiering	None	None (no retrieval fee)	Milliseconds	Auto-tiers; saves up to 40% / 68% / 95%
S3 Standard-IA	30 days	Per GB	Milliseconds	128 KB minimum object size
S3 Glacier Instant Retrieval	90 days	Per GB	Milliseconds	Archive with instant access
S3 Glacier Flexible Retrieval	90 days	Per GB (restore)	Minutes to hours	Formerly S3 Glacier
S3 Glacier Deep Archive	180 days	Per GB (restore)	Hours	Cheapest class on the ladder

What is S3 storage tiering?

S3 storage tiering is the practice of placing each object in the cheapest storage class that still meets its access-latency needs, then moving it downward as it cools. AWS S3 exposes six classes on a single ladder: Standard, Intelligent-Tiering, Standard-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive. You do not pick the class by hand for every object. Instead, you set lifecycle rules that transition objects after a given number of days of age or inactivity. The win is recurring: Standard carries the highest per-GB rate on the ladder, while Glacier Deep Archive is the lowest. Tiering captures that spread automatically. The catch is that colder classes add a per-GB retrieval charge and a minimum storage duration (30, 90, or 180 days), so the move only pays off for data you rarely read. Done right, it is one of the most effective recurring cost controls on an S3 bill. It changes nothing about your application, because the object key and API stay the same.

Why does cold data quietly drain your budget?

Most S3 bills are dominated by storage, not requests. A dataset that lands hot on launch day is often untouched three months later, yet it keeps sitting in Standard, accruing the highest per-GB rate on the ladder every single day. Teams rarely delete it (it might be needed) and rarely move it (the move is not automatic). That gap is avoidable waste. The structural fix is a lifecycle rule, not a cleanup sprint. Consider a 1 TB log archive read once a quarter: in Standard it costs the full hot rate 90 days out of 90; in a Glacier class the per-GB storage is substantially lower and you pay a per-GB retrieval only on the one day you actually read it. S3 Intelligent-Tiering quantifies the upside publicly: its Infrequent Access tier saves up to 40% on storage versus Standard, the Archive Instant Access tier up to 68%, and the opt-in Deep Archive Access tier up to 95%. Those are AWS-published figures, not marketing ranges.

How do lifecycle rules push objects down the ladder?

A lifecycle rule is just XML attached to a bucket. The Transition action names a storage class and a day count; S3 moves objects automatically once they cross that age. Here is AWS's own example that tiers the logs/ prefix over a lifetime (verbatim from the S3 User Guide):

<LifecycleConfiguration>
  <Rule>
    <ID>example-id</ID>
    <Filter><Prefix>logs/</Prefix></Filter>
    <Status>Enabled</Status>
    <Transition><Days>30</Days><StorageClass>STANDARD_IA</StorageClass></Transition>
    <Transition><Days>90</Days><StorageClass>GLACIER</StorageClass></Transition>
    <Expiration><Days>365</Days></Expiration>
  </Rule>
</LifecycleConfiguration>

Apply it with the AWS CLI (verbatim command form from the AWS CLI reference):

aws s3api put-bucket-lifecycle-configuration --bucket <bucket> --lifecycle-configuration file://lifecycle.json

Because RustFS is S3-compatible and lists Lifecycle Management (ILM) as Generally Available, the same S3 API call works against a RustFS endpoint. One rule, three actions: tier to IA at day 30, to Glacier at day 90, expire at day 365.

S3 Standard vs Standard-IA: when does the first step pay off?

Standard-IA trades a lower per-GB storage rate for two costs: a per-GB retrieval fee on every GET, and a 30-day minimum storage duration. The break-even is purely about read frequency. If you read an object more than about once a month, the retrieval fees erase the storage savings; keep it in Standard. If you read it quarterly or less, IA wins. AWS enforces a 128 KB minimum billable object size for IA, so transitioning a bucket of tiny files can cost more in overhead than it saves. Filter those out with <ObjectSizeGreaterThan>. The transition itself is billed as a request, so tiering millions of tiny objects has its own price. Practical rule: IA is the right first rung for objects larger than 128 KB that you access roughly once a quarter or less. Everything hotter stays in Standard; everything colder keeps falling.

Glacier tiers: at what point do milliseconds stop mattering?

Glacier is three rungs, and the only difference is retrieval time and minimum duration. Glacier Instant Retrieval gives you millisecond access at a per-GB retrieval fee and a 90-day minimum. Use it for archives you might need right now. Glacier Flexible Retrieval (the former S3 Glacier) takes minutes to hours to restore and also carries a 90-day minimum; it is the cheapest of the three for true cold storage you read a few times a year. Glacier Deep Archive is the bottom: hours-long retrieval and a 180-day minimum, the lowest per-GB rate on the entire ladder.

Tier	Minimum storage duration	Retrieval time
Glacier Instant Retrieval	90 days	Milliseconds
Glacier Flexible Retrieval	90 days	Minutes to hours
Glacier Deep Archive	180 days	Hours

The trap is the minimums. Delete or re-tier an object before its window and AWS charges you for the remaining days as a prorated fee. So Glacier only pays off for data with a real retention horizon: backups and compliance archives.

Intelligent-Tiering: automatic savings without the ops burden

S3 Intelligent-Tiering is the only class that moves data for you. You opt in, pay a small monthly monitoring and automation charge per 1,000 objects, and AWS watches access patterns. Objects not touched for 30 days drop to the Infrequent Access tier (up to 40% storage savings), and after 90 days of silence to Archive Instant Access (up to 68%). There are no retrieval charges and no minimum storage duration, which removes the biggest risk of manual tiering: getting the break-even wrong and paying penalties. Objects smaller than 128 KB are not auto-tiered; they stay at the Frequent Access rate and incur no monitoring fee. The trade-off is the monitoring charge itself. At very high object counts it can exceed what you would save, so it suits data lakes and user-generated content where access is genuinely unpredictable. For known-access patterns, explicit lifecycle rules are cheaper.

The traps that turn tiering into a loss

Tiering is not free, and four costs bite. Minimum storage durations apply: Standard-IA holds objects for 30 days, Glacier Instant and Flexible for 90, Deep Archive for 180. Delete or transition out early and AWS bills the remaining days as a prorated charge. The 128 KB minimum billable size on IA and Glacier classes means tiny objects cost more to tier than to leave alone, so filter them with <ObjectSizeGreaterThan>. Every transition is billed as a request, so moving millions of objects spikes a one-time request cost. And lifecycle only goes down the ladder: to bring an object back to Standard you must copy it explicitly with aws s3 cp or aws s3 sync, never a transition. Miss any of these and the savings go negative.

Self-hosting tiering with RustFS

If you run storage yourself, the same playbook applies. RustFS is Apache-2.0, S3-compatible object storage and lists Lifecycle Management (ILM) plus ILM Tiering (Remote S3) as Generally Available in its current Feature & Status table. A self-hosted RustFS cluster can apply S3 lifecycle rules that push cold objects to a remote S3 tier (another RustFS pool or an external S3 endpoint) once they cool, instead of holding everything on expensive local disk. Be clear on the model: RustFS does not replicate AWS's six in-place local storage classes. Its tiering is ILM-driven movement to a remote tier, not a drop-in Glacier class switch. Spin up a node to try it:

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

Default credentials are rustfsadmin/rustfsadmin; set real keys before production.

Can I move objects back to S3 Standard with a lifecycle rule?

No. Lifecycle transitions only go down the ladder. To bring an object back to Standard you must copy it explicitly with aws s3 cp or aws s3 sync, never a transition action.

What is the cheapest S3 storage class?

S3 Glacier Deep Archive: the lowest per-GB storage rate on the ladder, with a 180-day minimum storage duration and hours-long retrieval. AWS publishes the exact per-GB rates on aws.amazon.com/s3/pricing.

Does S3 Intelligent-Tiering have retrieval fees?

No retrieval charges and no minimum storage duration. You pay a small monthly monitoring and automation fee per 1,000 objects, plus standard storage. Objects under 128 KB are not auto-tiered and incur no monitoring fee.

What happens if I delete an object before the minimum storage duration?

You are charged a prorated amount equal to the storage cost for the remaining days. Standard-IA enforces 30 days, Glacier Instant and Flexible enforce 90, and Deep Archive enforces 180. Match your rules to real retention horizons.

Can RustFS do S3 storage tiering?

Yes. RustFS lists Lifecycle Management (ILM) and ILM Tiering (Remote S3) as Generally Available. It moves cold objects to a remote S3 tier through S3-compatible lifecycle rules. It does not implement AWS's local Glacier class ladder in place; tiering is movement to a remote tier.