S3 Glacier Deep Archive is by far the cheapest way to keep data in AWS. Everyone knows that part. What tends to catch teams off guard is the other side of the deal: retrieval has rules of its own, and the worst time to discover them is during an incident.

This article is about those rules.

Retrieving is not reading

In a normal bucket, reading an object is one request and done. In deep archive, the object is not available for reading — it has to be restored first, which creates a temporary copy accessible for a window you choose.

That is two steps, and the first is not instant:

You request the object's restoration.
Hours later, it becomes available for download for N days.
After that window, the temporary copy disappears — the archived object stays, but you have to ask again.

Anyone writing automation that treats archive storage like a normal bucket finds this out in production, with the retrieval failing because the object "is not ready".

The hours matter more than they seem

Deep Archive offers two retrieval tiers:

Standard — the object becomes available in roughly 12 hours.
Bulk — roughly 48 hours, at a considerably lower cost.

Twelve hours is a long time when someone deleted a file by mistake and needs it today. Forty-eight is an eternity. Neither is "backup you restore quickly" — and that is fine, as long as expectations match. The mistake is selling deep archive as if it were the only layer of protection.

The design that works is tiered: a recent copy in fast-access storage for day-to-day incidents, and deep archive for long retention, compliance and the catastrophic scenario. Archive is your insurance policy, not your working tool.

The 180-day minimum

Objects in Deep Archive carry a 180-day minimum charge. Write today and delete in thirty days, and you pay as though you had stored it for six months.

That makes the tier terrible for data that changes often, and excellent for what genuinely does not. A poorly calibrated lifecycle policy — one that moves data there too early and expires it soon after — manages the feat of increasing the bill while trying to cut it.

The per-object cost hiding in the invoice

Every archived object carries separately billed metadata: 32 KB at the archive tier's rate and 8 KB at the standard class rate. That is 40 KB per object, regardless of actual size.

For large files, noise. For archives with millions of small files, that line can exceed the cost of the data itself — and it is why archiving object by object rarely pays off in that scenario. Grouping files into larger bundles before sending solves all three at once: fewer requests, metadata once per bundle, and the 180-day minimum applied to few objects.

The question that separates backup from hope

There is an enormous difference between "the data is archived" and "I know I can get it back". The first is a statement about the past. The second requires a test.

An honest recovery drill answers:

How long between asking and having the file in hand?
Does the recovered content match the original?
Who is allowed to run this at three in the morning?
How much did that recovery cost?

If you have never run that drill, what you have is not a verified backup — it is a presumed one. And the time to find out the difference is not during the incident.

A permissions trap

Retrieval uses a different operation from reading. Granting read permission on objects is not enough: the restore operation has to be allowed too. It is common for the access policy to be correct for writing and incomplete for retrieving — and nobody notices, because the write path runs every day and the retrieval path never does.

Test recovery with the same identity that will actually perform it, not with an administrative credential.

Practical summary

Deep archive is long retention, not fast recovery: expect 12 h standard, 48 h bulk.
Restoring is an asynchronous request followed by an availability window — automation has to handle that explicitly.
There is a 180-day minimum charge; an over-aggressive lifecycle costs more, not less.
There is 40 KB of billed metadata per object: in archives of small files, grouping before sending changes the order of magnitude of the bill.
Test the recovery, with the real identity, and time it.

Prices and timings vary by region and change over time — confirm against AWS's official documentation before committing to any design.

NubliVault packs files before archiving and keeps a searchable manifest, which lets you recover an individual file without downloading the whole bundle — and follow the retrieval cycle from the console. See how it works.