Archives, Not Objects

In standard S3, the unit of storage is an object living inside a bucket. Glacier, when used through its own vault API, stores archives inside vaults. An archive is any data — a single file or a bundle of files packaged together — that AWS stores as an immutable blob and identifies with a system-generated 138-character archive ID. You cannot rename an archive or edit its content in place; you can only upload a new one and delete the old one. This immutability is a deliberate design choice: cold storage is meant to be a write-once, read-rarely destination, and removing the ability to casually mutate data reduces both cost and risk.

Today, most engineers never touch the standalone Glacier vault API directly. Instead, they use S3 storage classes — S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive — which store data as ordinary S3 objects but apply Glacier’s economics and retrieval behavior underneath. The vault-based API still exists and is still used for specialized compliance and backup-vendor integrations, so understanding both models matters for interviews and for reading legacy systems.

The Three Retrieval Tiers

Glacier’s defining trade-off is retrieval latency versus storage cost. The colder (cheaper) the tier, the longer you wait to get data back and the more you pay per retrieval request.

You may likeAWS IAM→

Jobs: The Async Execution Unit

Every retrieval from Flexible Retrieval or Deep Archive is executed as a job — an asynchronous background task that AWS schedules, executes, and notifies you about, typically via Amazon SNS or by polling the job status. This job-based model is the single biggest conceptual shift from standard S3, where a GET request returns data synchronously in the same HTTP response. In Glacier, you submit a retrieval request, receive a job ID, and then either poll for completion or receive a push notification when the data is staged and ready to download.

A production Glacier deployment is rarely just “a vault.” It is a small system made of five cooperating components, each with a distinct responsibility.

flowchart TB
    subgraph Client
        A[Application / Backup Tool]
    end
    subgraph AWS_Region["AWS Region"]
        LB[S3 API Endpoint]
        subgraph S3["Amazon S3"]
            B[(S3 Bucket)]
            LR[Lifecycle Rule Engine]
        end
        subgraph GLACIER["S3 Glacier Storage Tiers"]
            IR[Instant Retrieval]
            FR[Flexible Retrieval]
            DA[Deep Archive]
        end
        JQ[Retrieval Job Queue]
        SNS[Amazon SNS Topic]
        VL[Vault Lock / Compliance Policy]
        CW[CloudWatch Metrics and Logs]
    end
    A -->|PUT object| LB --> B
    LR -->|age-based transition| B --> IR
    B --> FR
    B --> DA
    A -->|Restore Request| JQ
    FR --> JQ
    DA --> JQ
    JQ -->|job complete| SNS --> A
    VL -.enforces.-> FR
    VL -.enforces.-> DA
    JQ --> CW
    B --> CW
    

Notice that the client never talks to “Glacier” as a separate service when using S3 storage classes — it talks to the S3 API endpoint. Glacier is the storage and retrieval engine sitting underneath specific storage classes, invisible at the API surface except for the extra latency and the job-based restore flow.

Why Retrieval Isn’t Instant

Flexible Retrieval and Deep Archive achieve their extremely low storage price by storing data in a way that trades read-readiness for density and energy efficiency. Internally, AWS uses storage media and data layouts optimized for very high durability and very low cost per gigabyte rather than for random, immediate access — conceptually similar to tape libraries or purpose-built cold-storage hardware, though AWS does not publish the exact physical medium. Bringing an archive back into a “hot,” immediately downloadable state requires a background rehydration process: the archive’s shards are located, reassembled, integrity-checked against their stored SHA-256 tree hash, and copied into a temporary staging area that behaves like standard S3 for the duration of the restore.

Checksum-Verified Integrity

Every archive is split into 1 MB chunks, each independently hashed, and then combined into a Merkle-style “tree hash.” On upload, you can supply this tree hash yourself and AWS will reject the upload if it doesn’t match what was actually received — catching corruption in transit before it’s ever stored. On retrieval, the same tree hash is recomputed and compared before data is released, which is part of why Glacier’s durability claims are backed by cryptographic verification, not just replication.

The most common production pattern doesn’t send anything directly to Glacier. Instead, objects land in S3 Standard and an S3 Lifecycle configuration automatically transitions them through progressively colder tiers as they age — with zero application-level code required.

flowchart LR
    A[Day 0: Object Created in S3 Standard] -->|30 days| B[S3 Standard-IA]
    B -->|60 days| C[S3 Glacier Instant Retrieval]
    C -->|180 days| D[S3 Glacier Flexible Retrieval]
    D -->|365 days| E[S3 Glacier Deep Archive]
    E -->|7 years, policy-defined| F[Expiration / Deletion]
    

Each arrow in this diagram is a transition rule defined declaratively in the bucket’s lifecycle configuration (JSON or console-configured), scoped by object age, prefix, or tag. AWS runs these transitions as background batch operations — they are not billed as a retrieval, only as a per-object transition request fee, which is why lifecycle-driven archiving is dramatically cheaper than an application manually copying and re-uploading objects.

Glacier’s scalability story is unusual: it scales limitlessly on ingest and storage, but its “performance” dimension is really about retrieval throughput under cost constraints rather than raw speed.

Batch Restore for Scale

When teams need to restore millions of archives at once — for example, a full disaster-recovery drill — submitting individual restore requests one at a time would be slow and expensive at the request-fee level. AWS supports S3 Batch Operations paired with an S3 Inventory report to submit bulk RestoreObject calls as a managed, resumable, parallelized batch job, dramatically improving throughput for large-scale restores compared to sequential API calls from application code.

Netflix and Large-Scale Media Archiving

Netflix archives raw, unencoded source footage — often many times larger than the final streamed video — in Glacier-class storage after initial encoding pipelines complete. Because this footage is only needed again for re-mastering (new codecs, higher resolutions), Deep Archive’s 12–48 hour retrieval window is an acceptable trade-off against the enormous storage savings across petabytes of raw media.

Glacier-class data is stored redundantly across a minimum of three geographically separated Availability Zones within the chosen AWS Region, using erasure coding rather than simple full-copy replication. Erasure coding splits data into fragments plus parity fragments, such that the original data can be reconstructed even if multiple fragments are lost — achieving very high durability with less raw storage overhead than naive triple-replication.

Durability vs. Availability — A Critical Distinction

Durability (how unlikely data is to be lost) and availability (how reliably you can access it right now) are different guarantees, and Glacier’s design intentionally optimizes the former far more aggressively than the latter for its coldest tiers. During a regional service disruption, retrieval jobs may queue longer than usual — the underlying data isn’t lost, but it may be temporarily harder to reach quickly.

Glacier inherits S3’s security model — IAM policies, bucket policies, and encryption — plus a compliance-specific mechanism unique to cold storage: Vault Lock.

Because retrieval is asynchronous, monitoring Glacier well means tracking the health of the job pipeline, not just storage capacity.

Production Pattern: Restore SLA Alerting

Engineering teams commonly set a CloudWatch alarm on the age of pending restore jobs (tracked via a DynamoDB table updated by a Lambda triggered from SNS) — if a job exceeds its expected SLA window (say, 6 hours past the Standard retrieval estimate), an on-call engineer is paged, since this can indicate an AWS-side backlog or a misconfigured retrieval tier request.

You may likeAmazon CloudFront→

Glacier is rarely deployed standalone; it’s almost always one stage in a larger pipeline defined as infrastructure-as-code.