Skip to main content
Moving blobs between access tiers (Hot → Cool → Archive) helps reduce storage costs by matching access patterns to cheaper tiers. Blob Lifecycle Management automates these transitions and expirations using policy-based rules, so you don’t have to build custom automation.
Blob Lifecycle Management is available only for Blob Storage and General Purpose v2 (GPv2) storage accounts. If your account is General Purpose v1 (GPv1), upgrade it to GPv2 to use lifecycle policies.
Blob Lifecycle Management provides policy-based transitions of blobs between tiers and automatic deletion of blobs and snapshots based on rules you configure.
What Lifecycle Management can do
  • Automatically transition blobs to cooler tiers based on lastModified or lastTierChange dates.
  • Automatically delete blobs and blob snapshots after a configured number of days of inactivity.
  • Scope policies using filters such as blob name prefixes, blob index tags, blob types (e.g., blockBlob, appendBlob), or a combination of these.
  • Target base blobs, blob versions, and snapshots with separate actions and conditions.
How a lifecycle policy is defined A lifecycle policy is a JSON document that contains one or more rules. Each rule can:
  • Be enabled or disabled.
  • Specify filters (prefixes, blob index tags, and blob types).
  • Specify actions for base blobs, blob versions, and snapshots using actions like tierToCool, tierToArchive, and delete.
  • Use conditions such as daysAfterModificationGreaterThan and daysAfterLastTierChangeGreaterThan.
Summary of common actions and conditions Typical lifecycle rule behaviors
  • Move base blobs to Cool if not modified for 60 days.
  • Move base blobs to Archive if not modified for 180 days.
  • Delete base blobs if not modified for 365 days.
  • Skip blobs that were rehydrated or had a tier change within the last 7 days.
Creating a lifecycle rule in the Azure portal
  1. Sign in to the Azure portal and open your storage account.
  2. In the left-hand menu, select Lifecycle management under Data management.
  3. Use the List view and click Add rule to create a rule without editing JSON directly.
  4. Enter a name (for example, policy-1) and choose whether the rule is enabled.
  5. Limit the rule scope with filters (apply to all blobs or specific prefixes/tags).
  6. Select blob types and targets: base blobs, versions, snapshots, block blobs, or append blobs.
  7. Define actions and conditions (for example, set days after modification or days after last tier change).
  8. Save the rule. You can view or edit the generated JSON representation at any time.
Example JSON lifecycle policy
Best practices and tips
  • Use tag-based filters to apply policies to specific datasets without relying only on prefixes.
  • Test rules on a small subset (prefix or tag) before applying broadly.
  • Consider daysAfterLastTierChangeGreaterThan to avoid repeated tier-churn after rehydration or manual tier changes.
  • Keep separate rules for different retention and tiering requirements (for example, media files vs. logs).
You can create multiple rules to target different prefixes, tags, blob types, or combinations of actions. Policies are easy to enable, disable, or edit from the portal as your retention and cost requirements change.
A Microsoft Azure portal screenshot showing the "Lifecycle management" page for storage account demoaz0753553 with a single enabled rule named "policy-1" (Blob type: Block). The left navigation pane lists storage and networking options like Containers, File shares, Networking, and Data management.
Links and references

Watch Video