Glacier/Deep Archive cost optimization (reduce restores 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.

RPS to Monthly Requests Calculator API Request Cost Calculator CDN Request Cost Calculator

Optimization starts only after you know whether restore frequency, small-object fan-out, minimum-duration churn, or wrong-tier placement is the real archive cost driver; otherwise teams batch or re-tier blindly without removing the real waste.

This page is for production intervention: restore discipline, object packaging, lifecycle control, tier placement, and restore-SLA protection.

Start by confirming the dominant cost driver

Restore frequency dominates: the same datasets are repeatedly brought back because workflow demand is too frequent for archive storage.
Small-object fan-out dominates: request counts are exploding because retrieval touches too many tiny objects.
Minimum-duration churn dominates: short-lived archived data is paying cold-tier penalties without staying cold long enough.
Wrong-tier placement dominates: a workload that behaves like warm storage is living in an archive tier.

Do not optimize yet if these are still unclear

You still cannot explain whether restore frequency, object fan-out, minimum-duration churn, or tier fit is the larger driver.
You only have one blended archive number with no split between storage, retrieval volume, request count, and duration exposure.
You are still using the pricing page to define scope or the estimate page to gather missing retrieval evidence.

1) Reduce unnecessary restores and rehydration

Cache restored datasets for a short time instead of re-restoring repeatedly.
For frequent analytics, consider a warmer storage class or a separate analysis copy.
Avoid restoring "just in case" - restore based on explicit demand.

Practical pattern: keep "hot last 30 days" in a warm tier, keep long retention in archive, and only restore when you have a concrete job that needs it.

2) Reduce small-object request fan-out

Package small files into larger objects when it fits the access pattern.
Batch retrieval and avoid per-file interactive restores.
Prefer workflows that read sequentially from fewer objects.

Retrieval is billed on both GB and requests. The same 1 TB restored can be a few hundred objects or tens of millions of objects - and the request bill is very different.

3) Control minimum-duration churn

Be mindful of minimum storage duration rules when deleting/overwriting.
Use lifecycle policies intentionally to avoid churn-driven early deletion.
Keep short-lived data out of tiers with long minimum duration.

4) Fix wrong-tier placement

Batch work: do restores as a scheduled job, not ad-hoc clicks that restore the same data repeatedly.
Restore scope: restore only the prefixes or partitions you need for the job, not the entire archive.
Restore frequency: if you restore weekly, you may not be an archive workload anymore.

Quantify changes before you implement them

Use S3 Glacier / Deep Archive Cost Calculator to estimate savings from fewer restores or fewer retrieval requests.

Create a baseline scenario with current restores/month, restored GB/month, and retrieved objects/month.
Create an optimized scenario where you reduce restore frequency, batch objects, and avoid early deletion.
Use the calculator's Save scenario to compare the two without losing inputs.

Change-control loop for safe optimization

Measure the current dominant driver across restore frequency, object fan-out, minimum-duration churn, and tier placement.
Make one production change at a time, such as reducing restore cadence, repackaging objects, changing lifecycle rules, or moving one workflow to a warmer tier.
Re-measure the same restore and request windows and confirm the bill moved for the reason you expected.
Verify restore SLA, downstream analysis workflow, and operator usability still meet requirements before keeping the change.

Common pitfalls (what breaks cost savings)

Archiving data that is actually read frequently (analytics, compliance audits, backfills).
Many tiny objects: request costs and operational complexity explode.
Transition churn: moving objects between tiers too often creates transition fees.
Short-lived data in tiers with long minimum duration.
Restoring the same dataset repeatedly because the workflow has no cache or persisted restored copy.

How to validate the optimization

Track restores/month and restored GB/month before and after (at least one full billing period).
Confirm the object-count effect: did you reduce retrieved objects/month, not just total GB?
Validate SLA: restore completion time and downstream job success rate should not regress.