S3 Glacier retrieval pricing per GB and per request

Glacier retrieval pricing is a two-part bill: GB retrieved and retrieval requests. Understanding both is essential if you have many small objects or frequent restores.

The two retrieval price components

• GB retrieved: volume of data restored and read.
• Retrieval requests: number of objects restored (request-like fees).

Small-object amplification (why requests matter)

• Restoring 1 TB as 1,000,000 objects creates far more request fees than a few large objects.
• If you archive many small files, request fees can dominate retrieval cost.
• Packaging or batching into fewer objects can materially reduce request fees.

Tier choice changes cost

• Fast tiers: higher $/GB and request pricing, but shorter latency.
• Standard tiers: balance between cost and latency.
• Bulk tiers: lowest cost, but slowest restores.

How to estimate retrieval pricing (quick method)

1. Estimate retrieval GB/month (restores per month x avg restore size).
2. Estimate retrieval requests/month (objects restored).
3. Apply your tier pricing to both GB and requests.
4. Run a peak scenario for backfills or audits.

Pricing formula (simple and defensible)

• Retrieval GB cost = retrieved GB/month x $/GB for the chosen tier.
• Request cost = (retrieval requests/month / 1,000) x $ per 1,000 requests.
• Total retrieval = GB cost + request cost.

Keep the two units separate. Even if GB cost is the larger line item, requests can spike during restores of many small objects.

Worked example: small objects vs large objects

Suppose you restore 500 GB in a month. If those 500 GB are split into 2 million small objects, request fees can be significant. If the same 500 GB are stored as 5,000 large objects, request fees are tiny by comparison. The data volume is identical, but the request count is not. That is why object packaging and batch size matter.

Validation checklist

• Confirm retrieval GB from billing exports or restore job summaries (not stored GB).
• Count objects restored per month (or average objects per restore x restores/month).
• Separate routine restores from rare backfills or audits and model them as a peak scenario.
• Track the chosen retrieval tier and latency expectations for each workflow.

Estimate requests from object size (fast method)

• Requests/month ~= retrieval GB/month / avg object size (GB).
• Example: 500 GB retrieved with 5 MB objects -> about 102,400 objects.
• Use inventory reports to get real object size distribution if possible.

Tier selection notes (cost vs urgency)

• Expedited tiers reduce latency but increase both GB and request pricing.
• Bulk tiers are cheapest for large restores that are not time critical.
• If you run both routine and emergency restores, model them separately.

Where to get reliable inputs

• Restore jobs: track how many objects are restored per job and total bytes restored.
• S3 Inventory: use inventory reports to see object count and size distribution.
• Billing exports: confirm which usage types are driving charges (GB vs requests).

Optimization ideas that reduce request fees

• Bundle small files into larger archives before moving them to Glacier.
• Keep a manifest so you can restore only the needed subsets.
• Use a staging bucket to avoid repeated restore requests for the same objects.

Glossary (terms that affect cost)

• Restore request: the API call that initiates a rehydration job.
• Rehydration: the process of making archive objects readable again.
• Restore window: the temporary period when restored data stays accessible.
• Object fan-out: many small objects creating a large request count.

Common mistakes

• Modeling only GB retrieved and ignoring request fees.
• Using stored GB as a proxy for retrieval GB.
• Forgetting that retrieval tiers change both latency and price.

Related tools

Related guides

Related calculators

FAQ