4.5 Blob Tiers, Lifecycle, Soft Delete, and Versioning

Cost and recovery are designed together

Azure Blob Storage access tiers are not labels for importance. They are cost and access behavior choices. Hot is optimized for frequently accessed data with higher storage cost and lower access cost. Cool is for infrequently accessed data that still needs online access. Cold, where available, fits less frequent access than cool while keeping data online. Archive is offline and has the lowest storage cost, but data must be rehydrated before it can be read. The correct tier depends on how quickly data must be accessed, how often it is read, and how long it will be retained.

Tiering can happen at the account default access tier for new blobs or at the blob level for block blobs. Lifecycle management policies automate tier changes and deletions. A policy can move blobs to cool after 30 days, archive after 180 days, and delete after 2555 days. Policies can filter by prefix, blob type, tags, and other conditions. They can also act on previous versions and snapshots, which is important when versioning is enabled and old versions start consuming unexpected capacity.

Portal path example: Storage account > Data management > Lifecycle management > Add a rule. Choose a rule name, scope, blob type, prefix match, optional blob index match, and actions for base blobs, snapshots, or versions. For one-off tier changes, use Storage account > Containers > select blob > Change tier. At account level, use Configuration to set the default access tier for new blobs where supported.

CLI examples:

az storage blob set-tier \
  --account-name staz104prod01 \
  --container-name reports \
  --name 2025/q4/export.csv \
  --tier Cool \
  --auth-mode login

az storage account blob-service-properties update \
  --account-name staz104prod01 \
  --resource-group rg-storage-prod \
  --enable-delete-retention true \
  --delete-retention-days 14 \
  --enable-container-delete-retention true \
  --container-delete-retention-days 14

Soft delete protects deleted blobs for a retention period. During that period, an administrator can restore the deleted blob. Container soft delete protects deleted containers. Blob versioning keeps previous versions when a blob is overwritten or deleted, giving a stronger recovery story for accidental overwrite. Snapshots are point-in-time copies created explicitly, while versions are created automatically when versioning is enabled. Point-in-time restore can restore block blobs to an earlier state within the configured retention window when prerequisites are met.

Archive tier troubleshooting is a common case. If a user tries to read an archived blob, the operation fails because the blob is offline. Rehydrate it to hot or cool, choose a rehydration priority where supported, and wait until the archive status clears. Do not promise instant access. Also remember that changing tiers can have cost implications. Moving data too early from cool or archive can trigger early deletion charges depending on the tier rules.

Lifecycle troubleshooting starts with filters and dates. If a rule did not move a blob, check whether the blob type is supported, whether the prefix matches exactly, whether the rule is enabled, whether the action applies to base blobs or versions, and whether the age condition is based on last modification or creation behavior. If costs continue rising after enabling versioning, inspect old versions and snapshots. Data protection features preserve data, which means they can also preserve billable data.

Compliance scenarios need careful wording. Soft delete and versioning help recovery, but they are not the same as immutable storage or legal hold. If the requirement says users must not be able to modify or delete data for a retention period, look for immutability policies rather than only soft delete. If the requirement says recover from accidental deletion by an administrator, soft delete may be enough. If the requirement says recover from overwrite, use versioning.

Case scenario: a media company stores raw video uploads for active editing for 14 days, rarely reads them after 90 days, and must retain them for seven years. Editors also accidentally overwrite metadata files. A practical design is hot tier for new data, lifecycle rules to cool or cold after the active window, archive after the rare-access period if retrieval delay is acceptable, delete only after the retention requirement, blob versioning for overwrite recovery, soft delete for accidental deletes, and monitoring for retained versions.

If a legal retention requirement forbids deletion, add immutable storage policy rather than relying only on lifecycle rules.