Azure Storage Lifecycle Management: Complete Guide to Blob Tier Transitions, Snapshot/Version Cleanup & Cost Optimization

Storage Lifecycle Management is the umbrella term for managing the entire lifecycle of Azure Storage resources — Blob / Data Lake / Files / Disks. This article covers the Blob Lifecycle Management Policy (automatic tier transitions and deletion), Soft Delete, Versioning, snapshot management, and cleanup of stale resources. Common patterns: 1) automatic Blob tier transitions (Hot → Cool → Cold → Archive), 2) automatic deletion of old Blobs (retention policy), 3) automatic deletion of old versions and snapshots, 4) cleanup of old disk snapshots and VM images, 5) unified container policies across the Storage Account. The cost savings can reach millions of yen per year, making this automation essential for production workloads.

A Lifecycle Management Policy is a set of Rules defined in JSON. Rule structure: 1) name, 2) enabled flag, 3) type: 'Lifecycle', 4) definition: { filters: { blobTypes: ['blockBlob'], prefixMatch: ['container1/logs/'], blobIndexMatch: [...] }, actions: { baseBlob: { tierToCool: { daysAfterModificationGreaterThan: 30 }, tierToArchive: { daysAfterModificationGreaterThan: 90 }, delete: { daysAfterModificationGreaterThan: 365 } }, snapshot: {...}, version: {...} } }. Filters narrow down target Blobs (prefix / blob type / Blob Index Tag), and Actions define what to execute (tierTo* / delete). The limit is 100 Rules per Storage Account. You can edit the JSON directly or use the GUI in the Azure Portal Lifecycle Management blade — combining both is the standard operational approach.

daysAfterModificationGreaterThan evaluates days since the Blob's last Modification (create or write). It is the most common option, the default behavior, and requires no extra features. daysAfterLastAccessTimeGreaterThan evaluates days since the Blob's last Access (Read operation), enabling a more dynamic lifecycle. It requires enabling Last Access Tracking (a single setting at the Storage Account level), only records Access from the point of enablement onward (no historical Access data), and updates on a daily cadence on Read operations (no extra storage cost from frequent updates). A common rule looks like: 'tier to Cool after 90 days since last Access, Archive at 180 days, delete at 365 days.' Last Access Tracking has no storage cost and is recommended. This achieves true automatic optimization — keeping active business data Hot while automatically moving unused archives to lower-cost tiers.

Versioning automatically retains older versions whenever a Blob is modified, and is enabled at the Storage Account level. Snapshots are point-in-time copies of a Blob taken manually or via code. Both consume extra storage, so deletion via Lifecycle is mandatory. Typical rules: 1) delete Snapshots after 30 days, 2) delete Versions after 90 days, 3) permanently delete Soft Deleted Blobs after 30 days. The production pattern is to enable both Versioning and Snapshots while using Lifecycle to delete them on schedule for cost control. Microsoft's recommended combo is: 7-day Soft Delete + 30-day Snapshot + 90-day Version retention. Without these settings, Snapshots and Versions can accumulate without limit, causing runaway costs — Lifecycle configuration should be treated as mandatory at Storage Account creation time.

Disk Snapshots and VM Images are not covered by the Blob Lifecycle Policy and require separate operations. Common automation patterns: 1) an Azure Automation Runbook running a scheduled PowerShell script (e.g. Get-AzSnapshot to find snapshots older than 90 days, then Remove-AzSnapshot to delete them), 2) Azure Logic Apps with a Recurrence Trigger calling the Azure REST API, 3) Azure Functions with a Timer Trigger and the Azure SDK, 4) Azure Backup's Vault Policy managing Snapshot retention automatically (only for snapshots taken via Azure Backup), 5) a DevOps Pipeline running periodic IaC-based cleanup. In production, the Azure Automation Runbook offers the most flexibility, typically using tag-based identification (e.g. AutoDelete=true) to mark deletion targets. The cumulative cost of snapshots (thousands to tens of thousands of yen per month) is a classic 'hidden cost' that goes unnoticed — scheduled deletion automation is essential.

The Lifecycle Management Policy only operates at the Blob level — Storage Account and Container deletion are out of scope. Organization-level cleanup patterns: 1) tag-based naming conventions (CreatedDate, Owner, Project, AutoDeleteDate) for automatic detection of stale resources, 2) Azure Resource Graph queries to list Storage Accounts unused for 6+ months, 3) weekly review and notification via an Azure Automation Runbook matching tag conditions, 4) Azure Policy with a Deny Effect preventing creation of Storage Accounts that would go unused for 6+ months, 5) Cost Management to detect Storage Accounts with 0 yen/month usage (unused but still incurring costs). The modern best practice in production is to use Azure Resource Graph + Logic App to automate reporting, email the owner with a deletion proposal, and delete after approval. This continuously optimizes organizational resource sprawl.

Key caveats: 1) after configuring a Policy, the first evaluation takes 24-48 hours (it is not immediate; unexpected behavior must be verified), 2) deleting from Archive before 180 days triggers an early-deletion fee (also applies to Cool at 30 days and Cold at 90 days), 3) Lifecycle Policy Filters operate at the Container level (the entire Storage Account is not a target), 4) only BlockBlob is supported (PageBlob / AppendBlob require separate handling), 5) Last Access Tracking only records Access from the moment it is enabled — past data cannot be evaluated, 6) Policy evaluation internally executes List Blob operations, generating transaction costs in environments with many Blobs, 7) Audit Logs are essential for verifying Policy behavior and investigating unexpected deletions. There is no Report-only mode to simulate behavior, so the safe operational pattern is: always validate in a Dev environment first, then apply to Production.

Lifecycle Management is a major topic in AZ-104 (Administrator) domain 2 (Storage, 15-20%), tested in depth. AZ-305 (Solutions Architect Expert) covers cost-optimization design, DP-700 (Fabric Data Engineer) covers Lifecycle for OneLake / ADLS Gen2, and DP-300 (DBA) covers integration with Backup retention strategy. Azure cost management is a continuous organizational challenge, and understanding Lifecycle Management is an essential skill for cloud cost managers and FinOps engineers.