Archival Storage's Retrieval-Time Trade-off
The core idea behind archival storage is a bargain: give up fast access and you pay far less to keep bytes around.
//
Busque em todas as páginas da documentação
The core idea behind archival storage is a bargain: give up fast access and you pay far less to keep bytes around.
This page explains that bargain. It is the mental model you need before you pick a Glacier class or write a single line of restore code - why the cheapest storage is the slowest to read, and how the SDK lets you buy speed back one request at a time.
S3's archival storage classes - Glacier Instant Retrieval, Glacier Flexible Retrieval, and Deep Archive - cost a fraction of S3 Standard per gigabyte. That discount is not free. You pay it back in retrieval time, retrieval fees, or both.
The colder the class, the cheaper it is to store and the more it costs to read. Glacier Instant Retrieval keeps millisecond access. Glacier Flexible Retrieval and Deep Archive put your data behind a restore step that takes minutes to hours.
Retrieval tiers add a second dial. For the classes that need a restore, you choose Expedited, Standard, or Bulk - trading money for speed on each request.
The whole design assumes you rarely read the data. If you read it often, the retrieval costs erase the storage savings. Picking the right class is really about answering one question: when I finally need this back, how long can I wait?
Every storage class is a point on a curve. At one end, S3 Standard charges the most per gigabyte but serves any object instantly at a low request cost. At the other end, Deep Archive charges a tiny fraction per gigabyte but makes you wait hours and pay a retrieval fee to get an object back.
Archival storage lives at the cold end of that curve. It exists for data you are legally or operationally required to keep but expect never to read: compliance records, raw sensor dumps, finished-project media, database backups older than a quarter. The value is in having it, not in reading it.
GLACIER_IR) - cheaper storage than Standard-IA, but objects stay instantly readable in milliseconds. There is no restore step. Use it for archives you occasionally need right now.GLACIER) - cheaper still, but objects are offline. You must issue a restore and wait minutes to hours before you can download them.DEEP_ARCHIVE) - the cheapest S3 storage there is, and the slowest. Restores are measured in hours, and there is no fast Expedited option.The pattern is consistent: each step down in storage price is a step up in the time or money it takes to read the data back.
For GLACIER and DEEP_ARCHIVE, "retrieval" does not move the object back to Standard permanently. A restore creates a temporary, readable copy that lives for a number of Days you specify, after which it disappears and the object stays archived. GLACIER_IR skips this entirely - it is always readable, so no restore is ever needed.
The trade-off is not abstract - it changes the code you write. For GLACIER_IR, a get_object just works, exactly like Standard. For GLACIER and DEEP_ARCHIVE, a bare get_object fails with InvalidObjectState. You must first call restore_object, wait for the restore to finish, and only then download.
# --- Python (boto3) ---
import boto3
s3 = boto3.client("s3")
# Ask S3 to make an archived object readable for 3 days, using the Standard tier.
s3.restore_object(
Bucket="my-bucket",
Key="archive/2021-ledger.parquet",
RestoreRequest={"Days": 3, "GlacierJobParameters": {"Tier": "Standard"}},
)// --- TypeScript (AWS SDK v3) ---
import { S3Client, RestoreObjectCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({});
// Ask S3 to make an archived object readable for 3 days, using the Standard tier.
await s3.send(new RestoreObjectCommand({
Bucket: "my-bucket",
Key: "archive/2021-ledger.parquet",
RestoreRequest: { Days: 3, GlacierJobParameters: { Tier: "Standard" } },
}));The retrieval-time trade-off is exactly the gap between those two paths: instant read versus request-then-wait-then-read.
Once an object needs a restore, you get a second choice - how fast. Each tier is a different price-for-speed point, stated here as approximate because AWS quotes ranges, not guarantees.
| Tier | Glacier Flexible | Deep Archive | Cost |
|---|---|---|---|
| Expedited | ~1-5 minutes | not available | Highest per GB |
| Standard | ~3-5 hours | ~12 hours | Moderate |
| Bulk | ~5-12 hours | ~48 hours | Lowest per GB |
Expedited buys minutes for the Flexible class but does not exist for Deep Archive. Bulk is the cheapest way to pull large volumes back when you can wait. The dial only exists because the underlying storage is cold - it is the mechanism for buying speed back on demand.
Archival classes also carry minimum storage durations: 90 days for both Glacier classes, 180 days for Deep Archive. Delete or overwrite an object before that window and you are billed as if it stayed the full minimum. So the trade-off is not only about read latency - it is about commitment. You are betting the data will sit untouched long enough for the storage discount to pay off.
The savings are real only when reads are rare. If a Deep Archive object is read once a month with Bulk retrieval, the retrieval fees plus the temporary-copy storage can exceed what S3 Standard would have cost outright. The rule of thumb: the colder the class, the fewer times per year you should expect to read the data. Estimate reads per object per year before you tier, not after the bill arrives.
Because restores take minutes to hours, any system that reads archival data must be asynchronous. You issue a restore, then poll head_object for the Restore header to flip from ongoing-request="true" to a completed state, or better, let an S3 event notify you when the restore finishes. A synchronous "user clicks, file downloads" flow simply cannot sit on top of GLACIER or DEEP_ARCHIVE - design for the wait from the start.
Every class maps cleanly to an answer to "how long can I wait to read this back?"
GLACIER_IR (or don't archive at all).GLACIER with Expedited.GLACIER or DEEP_ARCHIVE with Standard or Bulk.DEEP_ARCHIVE with Bulk.Answer that first, and the class, tier, and code path all fall out of it.
get_object a Glacier object like any other." Only for GLACIER_IR. GLACIER and DEEP_ARCHIVE require a restore first, or the get fails with InvalidObjectState.Days you set. The object stays in its archival class; the copy expires.Because it trades away fast access. The storage is priced for data you almost never read, so AWS keeps it on the slowest, cheapest media and charges a retrieval fee plus hours of latency when you do need it back.
Glacier Instant Retrieval (GLACIER_IR). It keeps millisecond access with no restore step, at a storage price below Standard-IA. The other two, GLACIER and DEEP_ARCHIVE, require a restore.
How fast a restore of a GLACIER or DEEP_ARCHIVE object completes, and what it costs. Expedited is fastest and priciest, Bulk is slowest and cheapest, Standard sits between. GLACIER_IR needs no tier because it is always readable.
Approximately: Expedited 1-5 minutes (Flexible only), Standard 3-5 hours for Flexible and about 12 hours for Deep Archive, Bulk 5-12 hours for Flexible and up to 48 hours for Deep Archive. AWS states these as ranges, not guarantees.
When you read the data often, or delete it before the class's minimum storage duration (90 days for Glacier classes, 180 for Deep Archive). Retrieval fees and early-delete charges can exceed the storage discount, so estimate reads per year first.
Not for GLACIER or DEEP_ARCHIVE - restores take minutes to hours, so the flow must be asynchronous: request a restore, then wait for an event or poll head_object. Use GLACIER_IR if you need an instant, synchronous read.
No. It creates a temporary readable copy that lasts for the number of days you specify, then expires. The object itself stays in its archival storage class the whole time.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última atualização: 23 de jul. de 2026