Estimate Glacier/Deep Archive retrieval volume (GB and requests)

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-01-27. Editorial policy and methodology.

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


This page is the retrieval-measurement workflow, not the bill-boundary page: the goal is to turn restore events, job frequency, object counts, backfill windows, and object packaging into a defendable retrieval model.

If you are still deciding which costs belong inside the archive bill versus beside it, go back to the pricing guide first.

Evidence pack before you estimate anything

  • Restore events: how often restores are triggered and how much data each restore touches.
  • Job frequency: recurring analytics, audits, backfills, or incident-driven retrieval workflows.
  • Object counts: how many objects are restored per workflow, not just how many GB are returned.
  • Backfill windows: exceptional months where one-off restore events dominate the bill.
  • Object packaging: whether the same data is stored in many small objects or fewer large objects.

Define "retrieval" for your workflow

  • Restore: rehydrating an object so it becomes readable again.
  • Read after restore: your jobs scanning the restored data (often the real driver of how often you restore).
  • Object count: how many objects you restore, which maps to request-like fees and operational work.

Method 1: From restore events (best if you have history)

  • Restores/month x average restore GB = retrieval GB/month.
  • Objects restored/month approximates retrieval requests/month.

If restores vary by day, do not use one average. Keep a baseline and a peak month (backfills and audits are typically the peak).

Method 2: From analytics workflows

  • If you rehydrate archives for analytics, model job frequency x data restored.
  • Large-scale backfills can dominate a single month's cost.

Method 3: From object counts (when the request bill matters)

If your archive has many small objects, treat "objects restored/month" as a primary input, not an afterthought. Even modest GB restored can become expensive if it is split into millions of objects.

  • List the top prefixes you restore from and estimate objects restored per job.
  • Multiply by job frequency to get objects/month.
  • Convert to cost using the archive calculator (it models GB and requests separately).

Sanity checks (to avoid underestimating)

  • Many small objects can create very high request counts.
  • Batching and packaging data into larger objects can reduce request charges.
  • Repeated rehydration suggests you may need a warmer tier or cached analysis copy.

Separate baseline retrieval from peak windows

  • Baseline retrieval: ordinary compliance checks, occasional restores, and predictable monthly jobs.
  • Peak retrieval windows: audits, backfills, or reprocessing events that can dominate one billing month.
  • Request-heavy windows: months where small-object fan-out matters more than restored GB.
  • Workflow-change windows: temporary migrations or new analytics patterns that alter restore behavior.

Worked estimate template (copy/paste)

  • Retrieval GB/month = restores/month * GB per restore (baseline + peak scenario)
  • Retrieval requests/month = objects restored/month (baseline + peak scenario)
  • One-time event = backfill restores (GB) + backfill objects (requests)

Turn retrieval into cost

Use AWS S3 Glacier / Deep Archive Cost Calculator with your retrieval GB/month and retrieval requests/month assumptions.

  • Create a baseline scenario from the most typical month.
  • Create a peak scenario for audits/backfills and compare.
  • Use Copy inputs (JSON) to share assumptions with teammates during review.

How to validate the estimate

  • After the first month, reconcile your model with actual restore events and billing usage types.
  • Check whether your restores were concentrated in a few days (peaky usage) and keep the peak scenario.
  • Verify object-count assumptions by sampling one representative job and counting restored objects.

When the retrieval model is ready to hand off

  • Go back to archive pricing if you still are not sure which retrieval and duration costs belong to the archive bill versus adjacent workflow costs.
  • Move to Glacier cost optimization when you can defend the dominant driver and want to change restore behavior, packaging, lifecycle rules, or tier placement.

Related reading and tools

Sources


Related guides


Related calculators


FAQ

What's the fastest way to estimate retrieval GB/month?
Start with expected restores per month x average restore size. If restores are triggered by analytics jobs, use job frequency x data restored per job.
How do I estimate retrieval requests?
Requests roughly track objects retrieved. If you retrieve 1,000,000 objects in a month, model about 1,000,000 retrieval requests (adjust for your tooling and batching).
Why do retrieval bills spike?
Backfills and audits can restore large volumes in a short time. Many small-object restores can also create large request counts even if GB is modest.
How do I validate the estimate?
Use a representative window of restore jobs (counts and sizes), then compare against actual restore logs or billing once available.

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