Storage Lifecycle Policy

A storage lifecycle policy uses supported conditions to schedule actions such as changing storage class or expiring objects and versions. It implements part of an approved retention and cost policy; it does not decide whether the organization is entitled to keep or delete the data.

Name the population, action, and clock. Object age, tier residence, last access, and time since a version became noncurrent are different measurements. A literal prefix selects keys beginning with those characters; it is not a wildcard expression unless the API defines one. Current and noncurrent versions can need separate rules. For a hypothetical dataset created on January 1, 2026, a ninety-day object-age rule selects it on April 1. If the business policy instead permits deletion ninety days after a contract closes on March 1, its earliest deletion date is May 30. The first rule acts fifty-nine days earlier because it starts the clock at creation. Supply the approved business trigger through supported metadata or a controlled selection process, and separately check holds and referenced versions before expiration.

Before expiration, account for retained snapshots, active readers and writers, recovery needs, and enforced holds. Preserving a manifest while deleting its referenced files still breaks the dataset. A tag has an effect only when a rule or enforcement mechanism uses it.

Test candidate selection against a version-aware inventory, then verify actual provider actions on a disposable dataset. Lifecycle execution can be asynchronous. Turning off a policy does not recover completed deletions or necessarily cancel queued work. Keep the approved policy version, candidate inventory, exceptions, and execution evidence together.

See Storage Tiering, Lifecycle, and Archival for worked examples.

References

• S3 lifecycle configuration