Unmanaged Blob Versions and Soft-Deleted Data Accumulation

With versioning enabled, every write to a blob (Put Blob, Put Block List, Copy Blob, Set Blob Metadata) turns the current version into a previous version, and deleting a blob keeps all its previous versions. Previous versions are not removed when the soft-delete retention period expires; they persist until they are deleted explicitly or by a lifecycle management rule. With soft delete alone, every overwrite creates a hidden soft-deleted snapshot that is kept for the retention period.

None of this is visible in a normal blob listing, so capacity grows while the live data set looks unchanged. The effect is largest for data that is overwritten frequently, such as checkpoints, exports rewritten on a schedule, and application state files uploaded with Put Blob, where each version can hold a complete copy. Microsoft's Well-Architected guidance calls out versioning and soft delete as features that add capacity cost and recommends lifecycle rules for old versions and a separate account for frequently overwritten data.

Previous versions and snapshots

Billed at the same rate as active data for as long as they exist

Unique-block billing

Without an explicitly set tier, you pay for unique blocks across a blob and its versions; a full Put Blob overwrite makes every block unique

Explicitly tiered version

A version or blob whose tier is set explicitly is billed at its full content length

Soft-deleted data

Billed at the same rate as live data until the retention period of 1 to 365 days expires

• Run a blob inventory report with includeBlobVersions, includeSnapshots and includeDeleted set to true and the VersionId, IsCurrentVersion, Snapshot, Deleted and Content-Length fields, then sum capacity for previous versions, snapshots and deleted blobs against current versions
• List storage accounts with blob versioning enabled (isVersioningEnabled on the blob service properties) that have no lifecycle management rule with a version or snapshot delete action
• Review the soft delete retention period on each account; long retention on accounts with frequently overwritten data multiplies retained capacity
• Watch for capacity growth in Storage insights or the account's Blob Capacity metric that outpaces growth in current data
• Check whether applications still take manual blob snapshots on accounts where versioning is already enabled

• Add lifecycle management rules that delete previous versions (and snapshots) a set number of days after they were created, or move them to Cool, Cold or Archive before deletion; lifecycle delete operations are free, while tier changes are billed as Set Blob Tier operations
• Move frequently overwritten data to a separate storage account with versioning and soft delete disabled, as Microsoft recommends
• Set the soft delete retention period to what recovery actually needs; Microsoft suggests starting short, with seven days as the minimum recommended value
• Stop taking manual snapshots of block blobs once versioning is enabled, since they add cost without extra protection
• Prefer Put Block and Put Block List for partial updates of large blobs so fewer blocks become unique, and note that lifecycle deletes in soft-delete-enabled accounts leave data soft-deleted until the retention period ends

• Blob Versioning in Azure Storagelearn.microsoft.com
• Soft Delete for Blobs to Recover Datalearn.microsoft.com
• Azure Blob Storage lifecycle management overviewlearn.microsoft.com
• Azure Storage blob inventorylearn.microsoft.com
• Architecture Best Practices for Azure Blob Storagelearn.microsoft.com
• Azure Blob Storage pricingazure.microsoft.com