Skip to content

AWS Updated 2026-07-04

Restoring from Glacier: expedited vs standard vs bulk, honestly compared

How to restore objects from S3 Glacier Flexible Retrieval and Deep Archive — what expedited, standard, and bulk retrieval actually deliver, what each costs, and the runbook for large restores.

Restoring from Glacier means issuing a restore request, waiting for the tier you paid for, then reading a temporary copy before it expires. From Glacier Flexible Retrieval: expedited typically completes in 1 to 5 minutes, standard in 3 to 5 hours, and bulk in 5 to 12 hours — and bulk is free. From Deep Archive: standard completes within about 12 hours, bulk within about 48, and expedited does not exist. The honest comparison: bulk for anything planned, standard for the same-day case, and expedited only for genuine emergencies on a small number of objects — it is the most expensive option and, without provisioned capacity, not guaranteed to be available.

What’s happening

Objects in Glacier Flexible Retrieval and Deep Archive are not directly readable. A GetObject against them returns InvalidObjectState. You call RestoreObject, S3 queues a retrieval job at the tier you chose, and when it finishes, a temporary copy of the object becomes readable alongside the archived original for the number of days you requested. You pay for the archived object and the temporary copy simultaneously during that window, plus the retrieval itself — billed per GB retrieved and per 1,000 requests, with expedited costing the most per GB and bulk the least (free from Flexible Retrieval). Glacier Instant Retrieval is different: no restore step at all, reads are synchronous, which is why it exists.

Expedited has a capacity caveat that matters exactly when you least want it to: it is delivered on shared capacity, and during a regional event when many customers restore at once, expedited requests can be rejected with an insufficient-capacity error. Provisioned capacity units exist to guarantee expedited throughput — if your disaster-recovery plan depends on expedited restores, that dependency needs to be bought, not assumed. The full mechanics are in the S3 documentation.

What to check first

  • Which class the objects are actually in. Flexible Retrieval and Deep Archive have different tiers and timelines; Instant Retrieval needs no restore at all.
  • How much data and how many objects. Retrieval bills per GB and per 1,000 requests — a million small objects is a request-cost problem, not just a bandwidth one.
  • The real deadline. “The auditor needs it this week” is a bulk job. Do not pay expedited prices for standard-tier patience.
  • Where the data goes next. Restoring to read once is different from restoring to permanently rehydrate — a restore does not change the storage class.

How to verify

Confirm the storage class and any restore already in progress:

aws s3api head-object --bucket my-bucket --key backups/db-2025-11-01.tar.gz

Look at StorageClass and the Restore field: ongoing-request="true" means a job is running; ongoing-request="false" with an expiry-date means the temporary copy is readable until that date. To find everything archived under a prefix:

aws s3api list-objects-v2 \
  --bucket my-bucket --prefix backups/ \
  --query 'Contents[?StorageClass==`DEEP_ARCHIVE`].[Key,Size]' \
  --output table

The runbook

  1. Issue the restore with an explicit tier and a short window. Days is how long the temporary copy stays readable — you pay double storage for that window, so keep it to what you need:

    aws s3api restore-object \
  --bucket my-bucket \
  --key backups/db-2025-11-01.tar.gz \
  --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Standard"}}'

  2. For thousands of objects, use S3 Batch Operations, not a shell loop. Generate a manifest (S3 Inventory works well — see S3 Inventory and Storage Lens), then create a Batch Operations restore job in S3 > Batch Operations > Create job. It retries failures and gives you a completion report; a loop over restore-object gives you neither.

  3. Get notified instead of polling. Configure an event notification on s3:ObjectRestore:Completed to SNS or EventBridge. Polling head-object across a large restore is slow and noisy.

  4. Read or copy the data before the window closes. The temporary copy expires silently. If the goal is permanent rehydration, copy the object over itself into the target class while it is restored:

    aws s3 cp s3://my-bucket/backups/db-2025-11-01.tar.gz \
  s3://my-bucket/backups/db-2025-11-01.tar.gz \
  --storage-class STANDARD

  5. For a true emergency on a handful of objects, use expedited — from Flexible Retrieval only. Swap "Tier":"Expedited" into the request. If you get an insufficient-capacity error, either retry, fall back to standard, or buy provisioned capacity. Deep Archive has no expedited tier, full stop — plan around a 12-hour floor there.

When this is the wrong move

If the same data is restored more than once or twice a year, it is in the wrong class — move it to Glacier Instant Retrieval or Standard-IA and stop paying restore tolls; the trade-offs are in S3 storage classes decoded. If the deadline is genuinely minutes and the data sits in Deep Archive, no runbook fixes that — the class choice already decided the outcome. And restoring an entire multi-terabyte bucket “to look for something” is the expensive way to discover you needed an inventory report.

Common mistakes

  • Restoring with "Days": 30 by default and paying a month of doubled storage for a file read once.
  • Scripting expedited restores across thousands of objects — the per-GB premium multiplies fast, and shared capacity may reject you mid-run.
  • Assuming a restore changes the storage class; the object stays archived, and the temporary copy quietly expires.
  • Building a DR plan on expedited retrieval without provisioned capacity, then hitting capacity errors during a regional event when everyone else restores too.

Prevention

  • Write the restore decision into the archive decision: before data enters Deep Archive, document the acceptable restore time and the approver for expedited spend.
  • Keep an S3 Inventory report on archived buckets so you can build restore manifests without listing millions of keys.
  • Test a small bulk restore once a year — the mechanics, the notification path, and the copy-out step.
  • If DR depends on fast restores, price provisioned capacity into the plan or change the storage class.

Glacier restores are predictable when the tier matches the deadline and painful when the deadline was never written down. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.