Blob Storage Cost Optimisation in Azure

Storage Tier Pricing Comparison

Azure Blob Storage offers four access tiers with different trade-offs between storage cost and access cost:

Real-World Tier Savings

For 10 TB of data that is accessed rarely — for example, application logs from 12 months ago — the tier choice has a dramatic impact on monthly cost:

• Hot tier: 10,240 GB × $0.018 = $184/month
• Cool tier: 10,240 GB × $0.01 = $102/month (44% saving)
• Cold tier: 10,240 GB × $0.0036 = $37/month (80% saving)
• Archive tier: 10,240 GB × $0.00099 = $10/month (95% saving)

If the data is log files that might be queried once a year for compliance purposes, archive tier is the obvious choice.

Lifecycle Management Policies

Lifecycle management policies automatically transition or delete blobs based on age and last-access time. This is the most impactful single change you can make to a Blob Storage cost profile — set it once and cost optimisation happens automatically.

Example policy: log data lifecycle

A common pattern for application log data:

• 0–30 days: Hot tier (being actively queried by operations team)
• 30–90 days: Cool tier (occasionally queried for investigation)
• 90–365 days: Cold tier (compliance access only)
• 365+ days: Archive or delete

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

# Apply a lifecycle policy to a storage account
az storage account management-policy create \
  --account-name mystorageaccount \
  --resource-group my-rg \
  --policy @lifecycle-policy.json

# View existing lifecycle policies
az storage account management-policy show \
  --account-name mystorageaccount \
  --resource-group my-rg

Choosing the Right Redundancy Level

Azure Blob Storage offers four redundancy options, each with different costs and durability guarantees. Many teams default to GRS (geo-redundant storage) for everything, when LRS or ZRS would suffice for much of their data at significantly lower cost.

Guidance by data type:

• Temporary or regenerable data (build artifacts, thumbnails, cached files): LRS is sufficient
• Static website assets (images, CSS, JS): ZRS for availability, LRS if CDN provides redundancy
• Application backups: GRS or GZRS depending on RTO/RPO requirements
• Primary database data: use managed database service replication rather than raw Blob Storage for this type of data

# Change redundancy level on an existing storage account
az storage account update \
  --name mystorageaccount \
  --resource-group my-rg \
  --sku Standard_LRS   # Change to LRS, ZRS, GRS, or GZRS as needed

Reducing Operations Costs

Beyond storage and redundancy, Blob Storage charges per operation. These are small individually but add up at scale:

• Hot tier reads: $0.004 per 10,000 operations
• Hot tier writes: $0.05 per 10,000 operations
• List operations: $0.05 per 10,000 operations

At 1 billion operations/month, write costs alone amount to $5,000. Batching strategies to reduce operation count include:

• Append multiple small writes to the same blob using append blobs or by accumulating data before writing
• Use Azure Data Factory or Synapse pipelines to batch many small files into fewer large files (the “small file problem” in data lakes)
• Avoid listing container contents in tight loops — cache directory listings on the application side
• Use blob tags for filtering instead of listing and filtering client-side

Soft Delete and Version Cleanup

Blob soft delete and versioning are useful data protection features, but both retain historical versions of blobs that accumulate storage costs. A storage account with 1 year of blob versions enabled on frequently-modified data can have 10–20x the storage costs of the current data alone.

# Check soft delete and versioning settings
az storage account blob-service-properties show \
  --account-name mystorageaccount \
  --resource-group my-rg \
  --query "{softDelete:deleteRetentionPolicy, versioning:isVersioningEnabled}"

# Reduce soft delete retention from 30 days to 7 days
az storage account blob-service-properties update \
  --account-name mystorageaccount \
  --resource-group my-rg \
  --delete-retention 7 \
  --enable-delete-retention true