Managing Blob Access Tiers at Scale

Azure Blob Storage offers three access tiers to optimize storage costs based on data access patterns: Hot, Cool, and Archive. The Hot tier is optimized for frequent reads and writes, with the lowest access latency (single-digit milliseconds) but the highest storage cost. The Cool tier is designed for data that is infrequently accessed and stored for at least 30 days, offering lower storage cost but higher access cost (per GB read) and slightly higher latency. The Archive tier is for rarely accessed data with a minimum storage duration of 180 days, providing the lowest storage cost but requiring manual rehydration before reading, which can take up to 15 hours.

When you upload a blob, you can specify its tier at creation time, or it defaults to the account's default tier (Hot or Cool). Blobs in the Hot and Cool tiers are stored on high-performance SSDs or HDDs, while Archive blobs are stored on tape or cold HDDs, which is why rehydration is needed. The tier is stored as a property on the blob, and changing the tier (e.g., from Hot to Cool) is an immediate operation that updates the metadata and moves the underlying data. However, changing from Archive to any other tier requires rehydration: the blob is copied to a Hot or Cool tier, which can take hours. During rehydration, the blob remains in Archive tier until the copy completes, at which point the tier changes.

To set the default access tier on a storage account:

az storage account update --name mystorageaccount --resource-group myResourceGroup --access-tier Cool

To set the tier on a blob at upload:

az storage blob upload --account-name mystorageaccount --container-name mycontainer --name myblob --type block --tier Hot --file /path/to/file

To change the tier of an existing blob:

az storage blob set-tier --account-name mystorageaccount --container-name mycontainer --name myblob --tier Cool

To create a lifecycle management policy:

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

Example policy JSON that moves blobs to Cool after 30 days and to Archive after 90 days:

{
  "rules": [
    {
      "enabled": true,
      "name": "moveToCool",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"]
        }
      }
    },
    {
      "enabled": true,
      "name": "moveToArchive",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"]
        }
      }
    }
  ]
}

To verify the tier of a blob:

az storage blob show --account-name mystorageaccount --container-name mycontainer --name myblob --query "properties.accessTier"

A media company stores millions of video files for on-demand streaming. Hot tier is used for new releases that are accessed frequently (first 30 days). After 30 days, a lifecycle policy moves videos to Cool tier, as viewership drops. After 90 days, videos are moved to Archive. This reduces storage costs by 70% compared to keeping everything in Hot. However, when a classic movie becomes popular again, they need to rehydrate it from Archive, which takes up to 15 hours. They use high-priority rehydration (extra cost) for such cases. They also enable last access time tracking to ensure that videos that are still being watched (even if old) remain in Cool. Without this, old but popular videos would be archived, causing delays. The company monitors rehydration requests and sets up alerts to avoid surprise costs.

A hospital stores patient records in blob storage, with a legal requirement to retain data for 7 years. They use Hot tier for records less than 1 year old (frequently accessed). After 1 year, records are moved to Cool. After 3 years, they are moved to Archive. They use lifecycle policies with filters based on container names (e.g., 'year-2023' container). They also apply an immutability policy (WORM) to prevent deletion. A challenge is that occasionally they need to access an old record for a lawsuit; they must rehydrate it, which can take hours. They plan for this by initiating rehydration in advance. They also use the early deletion fee calculation: if they accidentally delete an Archive blob before 180 days, they incur a penalty. They set up RBAC to prevent accidental deletion.

A financial services company uses Azure Backup to store backups in blob storage. Backups are taken daily and retained for 30 days in Hot tier. After 30 days, they are moved to Cool for 90 days, then to Archive for 1 year. Lifecycle policies automate this. They use a separate storage account for backups to isolate from production data. A common issue is that when they need to restore from an Archive backup, the rehydration time can delay recovery SLAs. They mitigate this by keeping the most recent 7 days of backups in Hot and using Archive only for older backups. They also test rehydration periodically to ensure it works as expected. They monitor the 'BlobRehydrationStatus' metric to track progress.