How to create a lifecycle policy in Azure Blob Storage

Keeping every blob in the Hot tier is convenient but expensive: data that is rarely accessed still pays the highest storage price. A lifecycle policy in Azure Blob Storage fixes this automatically, moving or deleting blobs based on their age — with no manual work and without touching your applications. In this guide you will build, end to end, a policy that cools and cleans up old data.

Prerequisites

• A general-purpose v2 Storage Account (lifecycle policies do not work on classic Blob accounts).
• Storage Account Contributor (or Owner) permissions on the account.
• Optional: the Azure CLI installed, if you prefer to apply the policy from the command line.
• A basic understanding of the access tiers: Hot, Cool, Cold and Archive.

Step 1: Understand the access tiers

Before writing rules, it helps to know where the data will go. Azure Blob Storage has four access tiers, from the most expensive to store (but cheapest to access) to the cheapest to store (but most expensive and slowest to access):

• Hot: frequently accessed data.
• Cool: infrequently accessed data, with a 30-day minimum retention.
• Cold: rarely accessed data, with a 90-day minimum retention.
• Archive: data that is almost never accessed; it is offline and rehydration takes hours.

The idea is simple: as a blob ages and stops being used, it should drop to a lower tier to cost less.

Step 2: Open Lifecycle management in the portal

In the Azure portal, open your Storage Account and, in the left-hand menu under Data management, click Lifecycle management. Here you can create rules through a visual wizard or by pasting the policy JSON directly. We will use the JSON because it is reusable and easy to version.

Step 3: Write the rule in JSON

A policy is a list of rules. Each rule has a filter (which blobs it covers) and a set of actions (what to do and when). The example below moves block blobs to Cool after 30 days without modification, to Archive after 90 days, and deletes them after 365 days:

{
  "rules": [
    {
      "enabled": true,
      "name": "arrefecer-e-arquivar",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "logs/" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

The prefixMatch limits the rule to the container or folder you specify (here, everything starting with logs/). To cover the whole account, just remove that line.

Step 4: Apply the policy

In the portal, paste this JSON into the Code view tab of Lifecycle management and click Save. Alternatively, save the JSON to a policy.json file and apply it with the Azure CLI:

az storage account management-policy create \
  --account-name mystorageaccount \
  --resource-group my-resource-group \
  --policy @policy.json

Replace the account and resource group names with your own. The policy then runs automatically once a day.

Verify the result

Lifecycle actions are not instant: Azure evaluates the policy once a day, and the first transitions can take up to 24 to 48 hours to run. To confirm everything is working:

• In the portal, go back to Lifecycle management and check that the rule shows as Enabled.
• After a day or two, open a container and check the Access tier column of the oldest blobs — they should now appear as Cool or Archive.
• For aggregated metrics, use Storage Insights in Azure Monitor and watch the capacity distribution per tier over time.

Conclusion

With a single rule you now have automatic cooling and cleanup, which usually translates into a much lower storage bill with no recurring effort. The natural next step is to tune the day thresholds to your own data and, if you enable last access time tracking, swap the condition for daysAfterLastAccessTimeGreaterThan to react to real usage instead of the modification date. What percentage of your blobs is still sitting in Hot without being touched in the last month?