Azure Blob Lifecycle Management Rules
Access tiers only save money if data actually moves between them, and nobody wants to be the person manually re-tiering blobs. Lifecycle management is the rule engine that does it: policies that transition blobs to cooler tiers or delete them outright when conditions you define are met. It's the difference between a tiering strategy that exists on a diagram and one that shows up on the bill.
What a rule can do
A lifecycle policy is a set of rules that automatically transition blobs between the Hot, Cool, Cold, and Archive tiers, or delete them, based on conditions. Rules can act on:
- Current versions of a blob
- Previous versions
- Blob snapshots
Scope can be the entire storage account, selected containers, or a subset of blobs filtered by name prefix or blob index tag.
It's a feature of the Blob service in general-purpose v2, Blob Storage, and premium block blob accounts.
Last modified versus last accessed
Rules trigger on one of two timestamps, and the choice between them matters more than it looks.
Last modified is available by default and costs nothing extra. It's the right trigger for write-once data types like: logs, backups, archives, where the write date genuinely reflects the data's age.
Last accessed tracks reads as well as writes, which is what you actually want for data whose value is determined by whether anyone is still using it. But it requires access tracking to be enabled, and that carries its own storage cost. It's a real trade: you're paying to track access in order to save money on tiering, so it only pays off where the tiering saving is larger than the tracking overhead.
Building a rule
In the portal, under Data management > Lifecycle management:
- Add a rule and give it a descriptive name.
- Define the scope — all blobs in the account, or filtered by container or prefix.
- Specify the blob type the rule applies to: base blobs, snapshots, or versions.
- Set the age threshold in days since last modification, or since last access if tracking is enabled.
- Configure the action — delete, or move to Cool, Cold, or Archive.
A reasonable first rule: if base blobs were last modified more than 30 days ago, move them to Cool. From there, a second condition at 90 days to Cold and a third at 180 to Archive builds a full cost curve without further intervention.
The two things lifecycle rules can't do
Both of these come up when someone assumes lifecycle management is a general-purpose data mover. It isn't.
You can't rehydrate an archived blob with a lifecycle policy. Rules move data to colder tiers and delete it. They don't bring it back out of Archive. Rehydration is a separate, deliberate operation because it takes up to 15 hours and costs real money, it isn't something you want a scheduled rule doing on your behalf.
You can't tier data in a premium block blob account at all. Not by policy, not by Set Blob Tier. Moving that data means synchronously copying the blobs to the Hot tier of a different account using the Put Block From URL API, or a version of AzCopy that supports it. If a premium block blob account is in the design, tiering isn't part of its cost story.
Managing versions is where the savings usually are
Blob versioning creates a new version on every write, and those versions persist until something explicitly removes them. Point-in-time restore's retention setting has no effect on version retention, versions aren't cleaned up by it.
That makes a lifecycle rule targeting previous versions the standard mitigation for versioning's cost, and in practice it's where lifecycle management earns its keep on a busy account. Enabling versioning without a corresponding lifecycle rule is one of the more reliable ways to manage a storage bill.
Azure Files has no equivalent
There's no native automated lifecycle management for Azure Files in the same sense, and the reason is structural rather than a missing feature: file share tiers are set at the share level, not per file. Every file in a share sits in that share's tier, so there's nothing for a per-file rule to act on.
Automating anything file-by-file e.g. deleting old files, means building it yourself with Azure Functions or Logic Apps. Worth knowing before designing a retention policy that assumes blob-style behaviour from a file share.
Doing this across many accounts
Lifecycle management moves data within a single account. For the same job across many accounts at once, Azure Storage Actions provides storage tasks. A serverless framework for performing common data operations across millions of objects in multiple storage accounts, based on conditions you define. It's the answer when the tiering policy is an estate-wide standard rather than a per-account setting.