A storage lifecycle policy is a set of rules attached to a bucket or storage account that automatically transitions objects to cheaper storage classes or deletes them once they meet conditions such as age, prefix or tag. In cloud storage it is the main tool for keeping cost aligned with how often data is actually read, without scripts or manual cleanup.
All major object storage services offer the feature: S3 Lifecycle configuration, lifecycle management in Azure Blob Storage, and Object Lifecycle Management in Google Cloud Storage. The policy runs inside the provider’s platform, so it scales to billions of objects and requires no compute resources from the customer.
How lifecycle rules are evaluated
Each rule combines a filter, one or more conditions and an action. The filter selects objects, for example by key prefix such as logs/, by object tags or by object size. The condition states when the action applies, most often a number of days since creation or since the object became a noncurrent version.
Evaluation is asynchronous and periodic. The provider scans objects in the background, typically about once a day, and queues matching actions. An object that qualifies today may therefore change class or disappear a day or more later, and billing usually reflects the new state from the moment the rule became eligible. A lifecycle policy is a cost and housekeeping mechanism, not a precise scheduler.
The main action types are listed below.
| Action | What it does | Typical use |
|---|---|---|
| Transition | Moves an object to a colder storage class | Logs and backups that are rarely read after a month |
| Expiration | Deletes the current version, or adds a delete marker when versioning is on | Temporary exports and retention-limited records |
| Noncurrent version expiration | Removes older versions after a set number of days | Controlling growth in versioned buckets |
| Abort incomplete multipart upload | Discards unfinished upload parts | Removing invisible storage left by failed uploads |
| Expired delete marker cleanup | Removes delete markers with no remaining versions | Keeping listings of versioned buckets clean |
Storage classes and minimum durations
Transitions only save money when the colder class fits the data. Colder classes charge less per gigabyte stored but add retrieval fees, slower access for archive tiers and a minimum storage duration. Deleting or moving an object before that minimum still triggers a charge for the remaining days.
| Tier | Example classes | Minimum duration | Access speed |
|---|---|---|---|
| Hot | S3 Standard, Azure Hot, Cloud Storage Standard | None | Milliseconds |
| Infrequent access | S3 Standard-IA, Azure Cool, Nearline | 30 days | Milliseconds |
| Cold | Glacier Instant Retrieval, Azure Cold, Coldline | 90 days | Milliseconds |
| Archive | S3 Glacier Deep Archive, Azure Archive, Cloud Storage Archive | 180 to 365 days | Hours, after a restore request |
Small objects deserve special attention. Infrequent-access classes often bill a minimum object size of about 128 KB, and every transition is charged per request, so moving millions of tiny files can cost more than keeping them in the hot tier. Size filters in the rule help to exclude them.
Archive tiers add one more consideration: objects there are not directly readable. A restore request creates a temporary readable copy, and the retrieval option chosen, from expedited to bulk, sets both the waiting time and the price. Data that may be needed urgently during an incident should therefore stay in a class with millisecond access, even if storage is slightly more expensive.
Lifecycle policies compared with related mechanisms
Several features in cloud storage also manage data over time, and they are frequently confused. The table separates their purposes.
| Feature | Decides placement by | Main purpose |
|---|---|---|
| Lifecycle policy | Fixed rules on age, prefix, tags or size | Predictable cost reduction and deletion |
| Intelligent tiering | Observed access patterns per object | Savings when access patterns are unknown |
| Object versioning | Every overwrite or delete | Recovery from mistakes, not cost control |
| Object lock or retention policy | Legal or compliance retention period | Preventing deletion before a set date |
Retention locks take precedence over lifecycle expiration: an object under a compliance hold is not deleted until the hold ends, even if a rule matches. Intelligent tiering and lifecycle rules can also be combined, with a rule moving data into the automatic tier after creation and a later rule expiring it.
Designing an effective policy
A good policy starts from measured access patterns, not assumptions. Storage analytics or access logs show how quickly reads decline after an object is written, and that curve determines sensible transition ages.
- Classify data by prefix or tag, for example raw logs, processed reports and backups.
- Set transition ages that exceed the minimum duration of the target class.
- Define expiration according to retention requirements and legal obligations.
- Add noncurrent version and multipart cleanup rules to every versioned bucket.
- Review the bill after one or two cycles and adjust rules that cause early-deletion or retrieval charges.
Policies should be managed as code alongside the bucket definition, because a rule changed by hand in a console is easy to lose and hard to audit.
Common mistakes
| Mistake | Consequence | Prevention |
|---|---|---|
| Expiration without versioning awareness | Data appears deleted but noncurrent versions keep accruing cost | Add noncurrent version expiration |
| Archiving data that is read monthly | High retrieval fees and hours of delay | Base rules on access logs |
| Overly broad filter | Production data deleted along with temporary files | Use specific prefixes or tags and test on a copy |
| No multipart cleanup rule | Unseen upload fragments billed indefinitely | Abort incomplete uploads after a few days |
The most serious risk is irreversible deletion. Expiration rules act silently, so any rule that deletes data should be reviewed by the data owner and tested against a small prefix before it covers a whole bucket.
Put simply
A storage lifecycle policy works like a filing system with automatic rules. New documents stay on the desk, older ones move to a cabinet in the back room, very old ones go to a distant warehouse, and some are shredded after a fixed period.
In the cloud, each of those places has a different price. The policy moves files automatically, so the company pays less for data that nobody reads anymore and deletes what it no longer needs.
In practice
A video analytics company stores about 400 TB of application logs and processed results in object storage. Engineers read logs heavily during the first week to investigate incidents, occasionally during the first quarter, and almost never afterward, but regulations require keeping them for seven years.
The team defined one policy for the logs/ prefix: transition to an infrequent-access class after 30 days, to a cold class after 90 days, to deep archive after 365 days, and expiration after seven years. A second rule aborts incomplete multipart uploads after three days. Within a few billing cycles, storage cost for logs fell substantially while engineers kept immediate access to the recent data they actually use.