S3 Glacier Pricing & Cost Guide (storage, retrieval, Deep Archive)

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

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

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.

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.
• Retrieval GB: restored data volume that actually re-enters the workflow.
• Retrieval requests: object-count-driven request exposure that can grow faster than restored GB.
• 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.

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.

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

• Amazon S3 pricing (Glacier / Deep Archive classes)
• S3 storage classes overview

Related guides

Related calculators

FAQ