Glacier

## Two products, one name "Glacier" is one of AWS's most confusing names because it refers to two distinct things, ten years apart in design. **Amazon S3 Glacier, the standalone service** (launched 2012 as "Amazon Glacier") is a separate API with its own vocabulary. You create a **vault** — a container roughly analogous to a bucket — and upload a **archive**, which is an opaque blob. The service hands back an **archive ID**: a long, machine-generated string. There is no key, no prefix, no folder-like listing. If you want to know what an archive contains, you have to keep your own index somewhere else, because AWS will only give you an inventory of IDs and sizes, refreshed periodically. Reading an archive back is not a synchronous `GET`; you start a retrieval job and collect the output later. **The Glacier storage classes** are the modern shape. Here nothing new is created — an ordinary S3 object in an ordinary bucket simply carries a different `StorageClass` value: - `GLACIER_IR` — S3 Glacier Instant Retrieval - `GLACIER` — S3 Glacier Flexible Retrieval (before the 2021 rename this class was just called "S3 Glacier", which is the root of most of the confusion) - `DEEP_ARCHIVE` — S3 Glacier Deep Archive The object keeps its key, its version ID, its metadata and tags, its object-level ACL or bucket-policy coverage, and its participation in event notifications. `ListObjectsV2` still lists it and reports the class: ```bash aws s3api list-objects-v2 --bucket my-archive-bucket \ --query 'Contents[].[Key,StorageClass]' --output table ``` ## Why the distinction matters in practice The practical consequence is **which API surface applies**. With the storage classes, everything you already built against S3 keeps working: the same SDK client, the same bucket policy, the same `s3:GetObject` and `s3:PutObject` permissions, the same replication and inventory tooling. The one behavioural difference is that objects in the asynchronous classes (`GLACIER` and `DEEP_ARCHIVE`) are not directly readable — a plain `GetObject` on one fails with the `InvalidObjectState` error until you have called `RestoreObject` on it. `GLACIER_IR` objects are read with an ordinary `GetObject`. With the vault service, none of that transfers. Bucket policies do not apply — vaults have their own vault access policies. S3 lifecycle rules do not target vaults. S3 Inventory, S3 Replication, S3 Event Notifications and presigned URLs are all bucket features and simply do not exist on the vault side. You are running a second, parallel storage system with its own identity model and its own operational habits. ## What to choose For any new workload the answer is the storage classes, and interviewers expect you to say so without hedging. The reasons are concrete rather than stylistic: 1. **Addressability.** Objects have meaningful keys you chose. Archives have IDs the service chose, so you must operate and back up your own ID-to-meaning index — a database whose loss makes the archive unreadable in practice. 2. **One control plane.** Access control, encryption configuration, logging and auditing all go through the S3 mechanisms you already run, rather than a second set. 3. **Transitions are declarative.** Moving cold data into an archival class is a property change on an object you already have, not an export into a foreign system. The vault API still exists and continues to serve deployments built on it years ago, so "we have a Glacier vault" is a legitimate legacy answer — but it is a migration candidate, not a design choice you make today. ## The trap in the naming Because the class now called Flexible Retrieval used to be called plain "S3 Glacier", older runbooks, blog posts and even internal wikis say "Glacier" when they mean one specific storage class, and other documents say "Glacier" when they mean the vault service. In a design discussion, resolve the ambiguity explicitly: ask whether the data is objects in a bucket or archives in a vault. That single clarifying question is most of what this topic is worth in an interview.