Back to Blog
4 min read

Managing Data with Azure Blob Storage Lifecycle Policies

As data volumes grow, managing storage costs becomes essential. Azure Blob Storage lifecycle management allows you to automatically transition data between access tiers and delete old data. This is particularly relevant as organizations store more data due to remote work.

Storage Tiers Overview

Azure Blob Storage offers three access tiers:

  • Hot - Frequently accessed data, highest storage cost, lowest access cost
  • Cool - Infrequently accessed data (30+ days), lower storage cost, higher access cost
  • Archive - Rarely accessed data (180+ days), lowest storage cost, highest access cost

Creating a Lifecycle Policy

Using Azure CLI:

# Create a storage account with blob versioning
az storage account create \
    --name mystorageaccount2020 \
    --resource-group rg-storage \
    --location australiaeast \
    --sku Standard_LRS \
    --kind StorageV2 \
    --access-tier Hot

# Enable blob versioning
az storage account blob-service-properties update \
    --account-name mystorageaccount2020 \
    --enable-versioning true

Policy Definition

Create a policy file lifecycle-policy.json:

{
  "rules": [
    {
      "enabled": true,
      "name": "move-to-cool",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/", "data/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "archive-old-data",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["archive/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "delete-old-logs",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "delete": {
              "daysAfterModificationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        }
      }
    }
  ]
}

Apply the policy:

az storage account management-policy create \
    --account-name mystorageaccount2020 \
    --policy @lifecycle-policy.json

Managing Versions and Snapshots

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

Using .NET SDK

using Azure.Storage.Management;
using Azure.Storage.Management.Models;

public class LifecycleManager
{
    public async Task CreatePolicyAsync(string resourceGroup, string accountName)
    {
        var credential = new DefaultAzureCredential();
        var client = new StorageManagementClient(subscriptionId, credential);

        var policy = new ManagementPolicy
        {
            Rules = new List<ManagementPolicyRule>
            {
                new ManagementPolicyRule
                {
                    Name = "move-to-cool",
                    Enabled = true,
                    Type = "Lifecycle",
                    Definition = new ManagementPolicyDefinition
                    {
                        Actions = new ManagementPolicyAction
                        {
                            BaseBlob = new ManagementPolicyBaseBlob
                            {
                                TierToCool = new DateAfterModification
                                {
                                    DaysAfterModificationGreaterThan = 30
                                }
                            }
                        },
                        Filters = new ManagementPolicyFilter
                        {
                            BlobTypes = new List<string> { "blockBlob" },
                            PrefixMatch = new List<string> { "data/" }
                        }
                    }
                }
            }
        };

        await client.ManagementPolicies.CreateOrUpdateAsync(
            resourceGroup,
            accountName,
            policy);
    }
}

Monitoring Policy Execution

Lifecycle policies run once per day. Monitor execution through:

# Check last execution
az storage account management-policy show \
    --account-name mystorageaccount2020 \
    --query 'policy.rules[].definition.actions'

# View metrics in Azure Monitor
az monitor metrics list \
    --resource /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account} \
    --metric "BlobCount" \
    --interval PT1H

Cost Estimation

Before implementing policies, estimate savings:

TierStorage (per GB/month)Operations
Hot~$0.0184Low cost
Cool~$0.01Higher cost
Archive~$0.00099Highest cost

Best Practices

  1. Start with monitoring - Understand your access patterns before setting policies
  2. Use prefix filters - Target specific containers or folders
  3. Test with a subset - Apply policies to test data first
  4. Consider rehydration time - Archive tier requires hours to rehydrate
  5. Review regularly - Adjust policies as usage patterns change

Lifecycle policies are a set-and-forget way to optimize storage costs while ensuring data is retained according to your requirements.

Michael John Peña

Michael John Peña

Senior Data Engineer based in Sydney. Writing about data, cloud, and technology.