Blob Lifecycle Management in Azure

How lifecycle policies work

A lifecycle policy is a JSON document attached to a storage account. It contains one or more rules. Each rule has:

• A filter — which blobs the rule applies to (by container name, blob type, or name prefix)
• Actions — what to do with matching blobs (change tier or delete)
• Conditions — when the action should trigger (based on days since creation, last modification, or last access)

Azure evaluates the policy once per day. When a blob matches a rule’s filter and its condition is true, Azure applies the action — such as moving the blob from hot to cool, or deleting it outright.

Writing a lifecycle policy

Here’s a real policy that covers a typical backup retention scenario:

{
  "rules": [
    {
      "name": "BackupRetention",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["backups/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToCold": {
              "daysAfterModificationGreaterThan": 90
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 180
            },
            "delete": {
              "daysAfterModificationGreaterThan": 365
            }
          }
        }
      }
    }
  ]
}

This rule says: for any block blob in the backups/ prefix, move to cool after 30 days since last modification, cold after 90 days, archive after 180 days, and delete after 365 days.

Save this as lifecycle-policy.json and apply it:

az storage account management-policy create \
  --account-name mystorageaccount123 \
  --resource-group my-storage-rg \
  --policy @lifecycle-policy.json

Using last access time instead of modification date

By default, policy conditions use daysAfterModificationGreaterThan — how long since the blob was last written. But for caching or content delivery scenarios, you might want to keep blobs hot as long as they’re being accessed, and only move them to cool when access stops.

Azure supports last access time tracking — but you must enable it explicitly, because it adds a small cost for metadata updates on every read.

# Enable last access time tracking
az storage account blob-service-properties update \
  --account-name mystorageaccount123 \
  --resource-group my-storage-rg \
  --enable-last-access-tracking true

Once enabled, you can write policies using daysAfterLastAccessTimeGreaterThan:

{
  "rules": [
    {
      "name": "InactiveBlobsToArchive",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["media/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterLastAccessTimeGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterLastAccessTimeGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

This policy moves media blobs to cool if they haven’t been accessed in 30 days, and to archive if they haven’t been accessed in 90 days — regardless of when they were last modified.

Managing versions and snapshots with lifecycle policies

If you have blob versioning or snapshots enabled, lifecycle policies can target old versions and snapshots separately from the current blob:

{
  "rules": [
    {
      "name": "CleanupOldVersions",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"]
        },
        "actions": {
          "version": {
            "tierToArchive": {
              "daysAfterCreationGreaterThan": 30
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          },
          "snapshot": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

This policy archives old versions after 30 days, deletes old versions after 365 days, and deletes snapshots after 90 days. The current blob version is untouched.

Combining multiple rules

A single lifecycle policy can contain many rules. Each rule applies independently. You might have one rule for backups, another for user uploads, and a third for log files — all in one policy document attached to the same account.

{
  "rules": [
    {
      "name": "UserUploads",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["uploads/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 180
            }
          }
        }
      }
    },
    {
      "name": "LogFiles",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["appendBlob"],
          "prefixMatch": ["logs/"]
        },
        "actions": {
          "baseBlob": {
            "delete": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

Viewing and updating an existing policy

# View the current policy
az storage account management-policy show \
  --account-name mystorageaccount123 \
  --resource-group my-storage-rg

# Delete the entire policy
az storage account management-policy delete \
  --account-name mystorageaccount123 \
  --resource-group my-storage-rg

There’s no “update a single rule” command. To change a rule, you retrieve the current policy, edit the JSON, and apply it again with the create command (which replaces the existing policy).