Lifecycle Storage Tiering Policy¶

A scheduled relocation policy — instantiates Layer Decay and Expiration Management

Migrates each layer down a hot → warm → cold → deep-archive ladder as it ages and cools, compacting it along the way, so old deposits get cheaper to hold instead of being deleted.

Not every aging layer should be deleted — much of it just doesn't need to sit on fast, expensive storage anymore. Lifecycle Storage Tiering Policy is the mechanism that keeps history without keeping it expensive. Its defining move is relocation, not removal: as a layer ages past thresholds and its access cools, the policy walks it down a ladder of storage tiers — hot for the active, warm for the occasionally-touched, cold and deep-archive for the rarely-needed — often compacting or repacking it at each step. The layer never leaves the system; its cost and access profile change to match its declining activity. It is the graceful middle path between "active by default forever" and "delete," and it is scheduled and continuous rather than triggered by a crisis.

Example¶

A team runs their object store under a lifecycle policy modelled on cloud storage classes. New telemetry lands in a hot standard tier where dashboards query it live. After 30 days without frequent reads it transitions to an infrequent-access warm tier — same durability, lower price, small retrieval fee. At 180 days it moves to cold archive, and at one year to deep archive, where storage is cheapest but restore takes hours. Along the way the policy flags the daily telemetry files as compaction candidates and rolls each month's thousands of tiny objects into one packed archive, cutting per-object overhead. A year-old incident's telemetry is still fully retained and legally intact — it just costs a fraction of a cent to hold and a few hours to wake, instead of premium hot-tier rent it no longer earns.

How it works¶

The distinctive machinery is the downward transition ladder, keyed to age and access rather than to a delete decision:

Define ordered tiers (hot / warm / cold / deep) with their cost, durability, and retrieval-latency trade-offs.
Set transition thresholds — days since last access, days since creation — that demote a layer one rung at a time as it cools.
Compact on the way down — repack, dedupe, or roll up many small aging layers into fewer large ones, since cold tiers reward big objects and punish many small ones.
Leave retention and deletion to other mechanisms; the ladder's bottom is deep archive, not the trash.

Tuning parameters¶

Transition thresholds — how many quiet days trigger each demotion. Aggressive thresholds save money fast but risk demoting a layer just before it's needed, incurring retrieval cost and latency.
Tier definitions — how many rungs and how cold the coldest is. More rungs fit cost to activity more finely; deeper cold tiers save more but wake more slowly.
Compaction aggressiveness — how much to repack and roll up. Heavier compaction shrinks overhead but makes retrieving a single sub-item costlier.
Access-vs-age basis — whether demotion is driven by elapsed time or by observed access. Access-driven adapts to real use; age-driven is simpler and predictable.
Retrieval-cost budget — how much surprise restore expense the policy tolerates, which implicitly caps how cold it lets active-ish layers fall.

When it helps, and when it misleads¶

Its strength is that it makes retention affordable, so the choice stops being "keep it hot or delete it" and becomes "keep it, at a price that matches its use." It reclaims fast storage automatically and preserves history and auditability the whole way down.

Its failure modes come from mismatch between the ladder and real access. Too-aggressive tiering buries a layer in deep archive right before a spike of demand, and now every read pays a retrieval fee and an hours-long wait — a premature-demotion tax that can dwarf the storage saved. Over-compaction makes single-item retrieval painful. And tiering is often mistaken for a retention or deletion policy: it never removes anything, so leaning on it to control legal exposure or unbounded growth simply relocates the problem to a cheaper tier. The discipline is to drive transitions from observed access where the pattern is spiky, keep a retrieval-cost budget in view, and pair the ladder with an actual retention schedule for the layers that must eventually leave.

How it implements the components¶

Lifecycle Storage Tiering Policy realises the relocation-and-compaction side of the archetype — changing a layer's cost profile as it cools:

hot_warm_cold_access_state — it sets each layer's tier: the policy is the state machine that moves layers between hot, warm, cold, and deep-archive states.
layer_compaction_candidate_flag — it flags and compacts aging layers as they descend, rolling small deposits into packed archives suited to cold tiers.

It does not evict under live capacity pressure (that's the online Cache Eviction Rule), and it never deletes or sets how long a layer may live — retention windows come from Retention Schedule. This policy relocates; others remove.

Instantiates: Layer Decay and Expiration Management — the cost-managed relocation path that keeps history without keeping it expensive.
Sibling mechanisms: Cache Eviction Rule · Archive-Restore Test · Retention Schedule · Age-Weighted Value Score · Log Rotation and Cleanup Job · Time-to-Live (TTL) Policy · Stale-Layer Detection Dashboard · Dependency-Safe Delete Check · Soft-Delete Quarantine Window · Tombstone or Deletion Marker

Notes¶

The bottom of this ladder is deep archive, not deletion — the policy assumes a working recovery path out of the coldest tier. That assumption is exactly what Archive-Restore Test exists to keep honest: a layer demoted to deep archive is only truly "kept" if it can still be brought back.