Glacier and Deep Archive save money when three conditions all hold: the data is accessed rarely, it will sit for longer than the minimum storage duration, and it is not made of huge numbers of tiny objects. Indicative S3 list rates in the US regions run about 0.023 dollars per GB per month for Standard, 0.004 for Glacier Instant Retrieval, 0.0036 for Glacier Flexible Retrieval, and 0.00099 for Deep Archive. Deep Archive is the cheapest storage AWS sells, but it charges retrieval fees, enforces a 180 day minimum, and adds per object metadata overhead, so archiving the wrong data can cost more than leaving it in Standard. Match the class to the access pattern, not just the age.
Here is how the four archive tiers really price, and the traps that catch buyers.
What do the archive classes actually cost?
The four cold classes trade retrieval speed for storage price. The table below uses indicative US region list rates; confirm against the current S3 pricing page before you model.
| Class | Storage per GB month | Retrieval time | Minimum duration |
|---|---|---|---|
| S3 Standard | about 0.023 dollars | Immediate | None |
| Glacier Instant Retrieval | about 0.004 dollars | Milliseconds | 90 days |
| Glacier Flexible Retrieval | about 0.0036 dollars | Minutes to hours | 90 days |
| Glacier Deep Archive | about 0.00099 dollars | Hours | 180 days |
The storage saving from Standard to Deep Archive is roughly 23 times. That headline is real, and it is also where the trouble starts, because the saving is on storage alone.
What does it cost to get the data back?
Retrieval is where archive economics turn. Glacier Instant Retrieval reads in milliseconds but carries a higher per GB retrieval fee than the others. Glacier Flexible Retrieval offers Expedited reads in roughly 1 to 5 minutes, Standard in about 3 to 5 hours, and Bulk in 5 to 12 hours, each at a different price. Deep Archive reads in about 12 hours for Standard retrieval and up to 48 hours for Bulk. Faster tiers cost more per GB retrieved.
The practical rule: archive classes assume you almost never read the data. If you expect to retrieve a meaningful share of an archive each month, the retrieval fees can exceed what you saved on storage. Deep Archive is for data you keep because you must, not data you browse.
What are the hidden traps?
Two costs catch buyers more than retrieval, and both reward large objects over many small ones.
Minimum storage duration. Glacier classes bill a minimum of 90 days and Deep Archive 180 days. Delete or overwrite an object early and you still pay for the remaining minimum. Archiving data that churns inside those windows generates early deletion charges that can dwarf the storage saving.
Per object overhead. Each archived object carries extra metadata billed at Standard rates, on the order of tens of KB per object across the index and metadata. For a few large objects this is noise. For billions of tiny objects it is the whole bill: the overhead per object, charged at the Standard rate, can exceed the Deep Archive storage cost of the object itself. Archiving a swarm of small files is the classic way to spend more, not less.
There are also transition request costs: lifecycle moves are billed per thousand objects transitioned, so moving a billion objects has a one time cost worth modelling before you flip the policy.
A worked example: when archiving backfires
A Fortune 500 retailer planned to push 4 billion small thumbnail objects, averaging well under 100 KB each, from S3 Standard to Deep Archive to chase the 23 times storage discount. Modelling the move first, the per object metadata overhead charged at Standard rates plus the transition request cost for 4 billion objects came to more than the projected annual storage saving, before a single retrieval. We instead aggregated the thumbnails into large packed archives and moved those, which preserved the discount because the overhead now applied to thousands of objects rather than billions. The redesigned archive cut the relevant storage line by more than 80 percent. Figures are verified against billing data and anonimised.
The pattern that backfires is always the same: many tiny objects, short lifetimes, or frequent reads. Fix it by packing small objects together, archiving only data that will sit past the minimum, and modelling retrieval before you commit.
How should you decide what to archive?
Score data on three axes before moving it: access frequency, expected lifetime, and object size. Rarely read, long lived, large objects belong in Deep Archive. Rarely read but occasionally needed fast belongs in Glacier Instant Retrieval. Anything that churns inside 90 or 180 days, or arrives as a swarm of tiny files, should be aggregated or left in a warmer class. Automate the transitions with lifecycle policies, but model the move first. This sits inside the wider AWS storage review playbook and the cross class trade in S3 storage classes and lifecycle policies. For the full estate, see the AWS cost optimization guide.
Frequently asked questions
Get the buyer side cloud cost playbook
We model archive moves before you make them, separate the data that genuinely belongs in Deep Archive from the data that will cost you more there, and redesign the ones that backfire. It is the same discipline behind the 31 percent median reduction we see in the first 90 days, with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.