Minimum Storage Duration Charge
also called Early Deletion Fee, Minimum Billable Duration
The contractual floor on how long an object in a cheaper storage class is billed for, which converts deletions and extra lifecycle hops inside that window into charges rather than savings.
A team ships a lifecycle policy that archives logs at day 30. Six weeks later the retention lawyer shortens the policy to 60 days, the rule deletes several hundred million archived objects, and the next invoice is higher than the month before the archiving began. Nothing is broken, nothing is misconfigured, and the storage dashboard shows the bytes are gone.
Cheap storage classes are cheap because you commit to leaving the data there. Each one carries a minimum storage duration, and an object deleted, overwritten or moved to another class before that duration elapses is billed for the remaining days as though it had stayed. At 2026 US list prices the documented minimums are 30 days for the infrequent-access classes, 90 days for Glacier Instant Retrieval and Glacier Flexible Retrieval, and 180 days for Glacier Deep Archive.
The charge is invisible in the design of a lifecycle policy because policies are written as a sequence of ages, and the penalty is a function of the intervals between those ages.
Why it matters
Lifecycle rules are the standard answer to storage growth, and they are usually written by someone reasoning about access patterns rather than about contract terms. A policy whose hops are closer together than the minimum durations pays for the same object more than once: a transition to Glacier at day 30 followed by a transition to Deep Archive at day 70 pays the balance of the 90-day Glacier minimum on top of the new class's own storage.
The cost is also asymmetric in a way that punishes exactly the organisations trying to improve. A team tightening retention from one year to 60 days is reducing total storage and will see a one-off charge for doing so, which is the opposite of the incentive anyone intended.
Implementation patterns
- Set the first transition age no earlier than the minimum duration of the class it moves to, so a later retention change cannot create a penalty.
- Collapse multi-hop policies. Standard to Deep Archive in one hop at day 90 is cheaper than Standard to Glacier at 30 then Deep Archive at 70, and simpler to reason about.
- Model the penalty before publishing a policy change: objects affected multiplied by remaining days multiplied by the class rate. For 400 million small objects this is a four or five figure number.
- Expire rather than archive anything with no retention obligation. Deletion from the standard class is free and immediate; archiving data you plan to delete is the worst of both.
Industry example
A web-scale crawler of Baidu's kind rewrites page snapshots continuously: the same URL is re-fetched, re-scored and re-stored, and old snapshots are superseded rather than read. An archive tier looks ideal for superseded snapshots until the overwrite rate is compared with the minimum duration. When the mean object lifetime is shorter than the class minimum, every object in the tier pays a penalty, and the archive tier becomes a surcharge on churn. The pattern repeats in event stores, CDC landing zones and preview-environment artifact buckets, which all have high rewrite rates and look archival on an age histogram.
Failure scenarios
- A retention tightening that produces a bill. The commonest version, and the one that discredits the storage programme that recommended tiering.
- Lifecycle churn. Several hops inside 90 days, each paying the previous minimum.
- Re-processing a dataset. A pipeline re-reads and rewrites archived objects, and each rewrite is an early deletion of the old version plus a new minimum on the new one.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Archive at the first legal opportunity | the lowest per-GB rate sooner | a penalty on any later retention change |
| Archive at the minimum duration or later | retention changes stay free | a few weeks of standard-class rate per object |
When not to use it
Archive classes are the wrong tool when the mean object lifetime is shorter than the class minimum, when the retention rule is still under discussion, or when the objects are small enough that the per-object overhead dominates. In all three cases the cheaper answer is shorter retention or compaction into larger objects, with no tier change at all.
Interview question
Q: You own a 2 PB log archive on a 90-day retention rule, archived at day 30. Legal asks you to cut retention to 45 days by the end of the month. What do you tell them it costs, and what do you change so the next such request is free?
What a strong answer covers: computing the penalty as affected objects times remaining minimum days; proposing that deletion start with objects already past the minimum while newer ones age out naturally, so the change costs nothing and lands a few weeks later; and the structural fix of aligning the first transition age with the class minimum so retention is a free variable from then on.
Quick check
Quiz: A policy archives at day 30 and a change deletes at day 60. What does the deletion cost? The remaining 30 days of the 90-day minimum, on every object, at the archive rate.
Flashcard: What do the archive storage classes charge for that the per-GB rate does not show? — A minimum storage duration of 30 to 180 days depending on class, billed in full even if the object is deleted, overwritten or moved earlier.