Azure Blob Storage lifecycle management automates actions based on how long objects have existed, when they were last modified, or when they were last accessed. A policy can move eligible blobs to cooler access tiers or delete them when the retention period ends.
Understand what a lifecycle policy can do
Lifecycle policies can apply to current blob versions, previous versions, or snapshots. Actions include moving data to cooler tiers and deleting objects at the end of their lifecycle. Rules can target an entire storage account, selected containers, or a subset filtered by name prefixes or blob index tags. [1]
Lifecycle management is supported for block blobs and append blobs in supported storage account types. It does not affect system containers such as $logs or $web.
1. Open Lifecycle management
- Open the storage account in the Azure portal.
- Under Data management, select Lifecycle management.
- Open the List View tab.
- Select Add a rule.
Before creating a delete action, document the data owner, retention requirement, restore expectations, and approval process. A lifecycle rule is automated, so a configuration error can affect many objects.
2. Define the rule scope
- Give the rule a descriptive name.
- Choose the rule scope.
- Select the blob type and subtype that the rule should evaluate.
- Select Next or continue to the filter settings.
Use a narrow scope for the first rule. For example, target one container or a prefix such as logs/ instead of applying a policy to every blob in the account.
3. Add filters
If you select a filtered scope, open the Filter set tab. Use container and blob-name prefixes or blob index tags to identify the objects. If more than one filter is defined, Azure applies a logical AND, so an object must satisfy all selected filters. [1]
Filters select what to include. They do not provide a general exclusion rule. Test the prefix and tag values against real object names before activating a rule.
4. Set a tiering action
- Open the Base blobs section.
- Choose a condition such as days since last modification.
- Choose the target tier, such as cool or archive where supported.
- Review the selected blob versions and snapshots.
- Save the rule.
For example, a policy can move block blobs to the cool tier when they have not been modified for 30 days. Choose thresholds based on actual access patterns and retrieval costs, not only storage price.
5. Add a deletion action carefully
Use deletion only when the retention requirement is explicit. Consider separate rules for current versions, previous versions, and snapshots. Check whether immutable storage, soft delete, or legal retention controls affect the planned deletion. Microsoft notes that lifecycle deletion does not work for blobs in immutable containers and can interact with soft-deleted objects. [1]
6. Enable last-access tracking only when needed
If the policy depends on the last access time, enable access time tracking under the storage account’s Lifecycle management page. Microsoft says this option is available when using block blobs and can generate additional transaction activity. [2]
7. Save and monitor the policy
Select Add to save the rule. Azure runs the policy once per day. Microsoft notes that policy changes can take up to 24 hours to take effect and for the first execution to start. Monitor metrics, logs, or the LifecyclePolicyCompleted event when you need evidence of execution. [2]
Common mistakes
- Applying a delete rule to the whole storage account without testing a narrow prefix.
- Assuming filters can exclude a second set of objects.
- Using last-access conditions without enabling access time tracking.
- Ignoring blob versions, snapshots, soft delete, or immutable storage.
- Expecting a new rule to run immediately instead of allowing for policy delay.
