S3 Glacier Pricing: Instant Retrieval, Flexible Retrieval, Deep Archive, and Restore Cost

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-06-18. Editorial policy and methodology.

Use this page when you need to decide what belongs inside the archive bill before you debate restore batching, object repackaging, or tier changes.

The first budgeting decision is whether the archive bill is mainly a quiet-storage problem, a retrieval-volume problem, or a small-object request problem.

This guide is about bill boundaries: stored GB-month, retrieval GB, retrieval requests, transition exposure, minimum-duration exposure, and the adjacent compute, analysis-copy, or workflow costs that should be tracked beside the archive bill rather than blended into it.

Quick pricing read

Glacier pricing is no longer one generic cold-storage line. The practical choices are S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive. Each class changes the storage-versus-retrieval tradeoff, the minimum storage duration, and the risk that small objects or short-lived archive churn erase your expected savings.

S3 Glacier Instant Retrieval: archive-style storage with fast access, but it has a 128 KB minimum billable object size and a 90-day minimum storage duration.
S3 Glacier Flexible Retrieval: the classic Glacier retrieval path with restore tiers, 90-day minimum storage duration, and free bulk retrievals.
S3 Glacier Deep Archive: the lowest-cost deep archive path, but it carries a 180-day minimum storage duration and the heaviest retrieval friction.
Metadata overhead matters: Flexible Retrieval and Deep Archive add 40 KB of metadata overhead per archived object, which can make small-object estates look much more expensive than raw GB suggests.
Retrieval is not only a GB question: request counts, restore tier choice, and rehydration workflow can matter as much as restored volume.

This page was updated on 2026-06-18 against the current AWS S3 pricing page and S3 storage class documentation.

Inside the archive bill vs beside the archive bill

Inside the archive bill: stored GB-month, retrieval volume, retrieval requests, transitions, and minimum-duration exposure.
Beside the archive bill: downstream compute on restored data, temporary analysis copies, and operator-side workflow costs that happen after retrieval.
Why this distinction matters: teams often blame Glacier for the workload they run after restore, even though the restored-data processing cost belongs to a different budget bucket.

What to model on the archive bill itself

Stored GB-month: average archived data held over the billing window, adjusted for the actual storage class you are using.
Retrieval GB: restored data volume that actually re-enters the workflow, keeping restore class and urgency visible.
Retrieval requests: object-count-driven request exposure that can grow faster than restored GB, especially with many small objects.
Transition exposure: movement into archive when lifecycle rules or churn create extra archive-side activity.
Minimum-duration exposure: early deletion or overwrite patterns that erase cold-storage savings across 90-day or 180-day rules.

Storage class choice changes the whole cost shape

Treat storage class selection as the first pricing decision, not the last. Instant Retrieval is not just "Glacier but faster." Flexible Retrieval is not just "cheaper storage." Deep Archive is not just "the cheapest per GB." Each class changes what the archive is optimized for and what kind of restore behavior becomes expensive.

Choose Instant Retrieval when fast restore behavior matters enough to justify the higher storage posture and minimum billable object size.
Choose Flexible Retrieval when restore SLAs can tolerate tiered retrieval and bulk restore behavior is part of the archive plan.
Choose Deep Archive when retention is genuinely long-lived and restore friction is acceptable.

Boundary choices that change ownership

Restore workflow: the archive bill covers getting data back, not the analysis systems or compute you run after restore completes.
Warm-copy strategy: if you keep a cached or warm analysis copy, that copy belongs beside the archive bill rather than inside it.
Tier churn: frequent moves and short-lived archived objects can change whether cost is really a Glacier problem or a lifecycle-policy problem.

How to gather inputs without mixing jobs

Retrieval exposure: bring in defendable retrieval GB and request counts from the estimate page instead of counting restore jobs here.
Bill adjacency: list downstream compute, restored-data cache, and analysis-copy costs beside the archive bill instead of hiding them in one blended estimate.
Duration risk: keep minimum-duration exposure visible so short-lived archive use is not mistaken for ordinary retrieval cost.

When this is not the right page

Go to estimate retrieval if you still need to measure restore events, object counts, backfills, or peak windows.
Go to Glacier cost optimization if you already know the cost owner and need production changes such as restore discipline, repackaging, or tier changes.

Archive cost Estimate retrieval

Related Glacier workflow pages

Estimate Glacier retrieval: use this when you still need defendable restore GB, request counts, and peak retrieval windows.
Glacier retrieval pricing: use this when retrieval fees are the main cost question rather than total archive ownership.
S3 to Glacier transfer cost: use this when lifecycle transitions and archive movement are shaping the bill before restore even begins.

Validation checklist

Validate that retrieval, transition, and minimum-duration inputs belong to the archive bill rather than to downstream processing or cache systems.
Validate object-count exposure explicitly so request-heavy archives are not mistaken for pure storage problems.
Validate short-lived archive behavior so minimum-duration penalties are not hidden inside general storage assumptions.

Sources

How to estimate archival retrieval costs: model GB restored per month and the number of objects retrieved (requests), plus common drivers like restores, rehydration, and analytics.

Glacier/Deep Archive cost optimization (reduce restores and requests)

A practical playbook to reduce archival storage costs: reduce restores, reduce small-object request volume, and avoid minimum duration penalties. Includes validation steps and related tools.

S3 Glacier retrieval pricing per GB and per request

Estimate Glacier retrieval pricing by separating GB restored, request fees, small-object amplification, and retrieval tier choice so archive restores are modeled with both latency and cost in view.

S3 Glacier retrieval time: how long restores take by tier

A practical guide to S3 Glacier retrieval time: how restore tiers map to latency, what drives delays, and how to plan workflows without surprises.

S3 storage classes: how they change cost (and when archive fees matter)

Compare S3 storage classes by modeling retrieval, transition, lifecycle churn, and minimum-duration tradeoffs so cheaper per-GB tiers are judged against the real access pattern.

API Gateway pricing: what to model (requests + transfer)

Model AWS API Gateway pricing across request charges, data transfer, logs, and adjacent add-ons, with a clearer checklist for what belongs in the API bill versus downstream systems.

FAQ

What are the main cost components for archival storage?

Storage (GB-month) plus retrieval (GB retrieved and retrieval requests). Some classes also have minimum storage duration and early deletion fees.

Is Amazon Glacier the same as S3 Glacier?

Amazon Glacier is now delivered as S3 Glacier storage classes. Pricing is still based on storage, retrieval, and minimum duration rules, but the service is accessed through S3.

Why do small objects increase cost?

Because retrieval is billed on both GB and requests. Many small-object restores can create high request counts even if total GB is modest.

What else should I include besides storage and retrieval?

For a realistic model, include transition/restore events (if applicable), minimum duration effects, and the operational workflow (how often you rehydrate and how long you keep restored copies).

Last updated: 2026-06-18. Reviewed against CloudCostKit methodology and current provider documentation. See the Editorial Policy .