Troubleshooting Azure Storage Deletion: Immutability, WORM, and Version Retention

One of the most common questions Azure Storage administrators ask after enabling immutable storage is:

"Why can't I delete my storage account anymore?"

Azure Immutable Storage is designed to provide WORM (Write Once, Read Many) protection, ensuring that data cannot be modified or deleted during a defined retention period. This capability is essential for compliance, regulatory, legal, and audit requirements, but it can be surprising when administrators later attempt to remove storage resources and discover that Azure refuses to delete them.

In some environments, immutable storage policies may not have been configured directly by Azure Storage administrators. Backup or data protection solutions can automatically enable and manage retention settings, and storage administrators may not always have visibility into these externally managed policies. 

This article explains:

• Why storage accounts become undeletable
• Why containers sometimes appear empty but still cannot be deleted
• The difference between Unlocked and Locked policies
• How ImmutableStorageWithVersioning changes deletion behavior
• What happens when version retention is reduced to one day
• A practical step-by-step process to remove protected resources
  
  

Understanding Azure Storage Immutability

Azure Blob Storage supports immutability through two primary mechanisms:

Time-Based Retention Policies

A retention policy protects data for a fixed number of days. During this period: read are allowed, deletes are blocked and overwrites are blocked.

Examples: 7 days,30 days,180 days,7 years

Legal Holds

Legal holds have no expiration date. The data remains protected until the hold is manually removed. Organizations commonly use legal holds when: litigation is in progress, regulatory investigations are occurring and data preservation is legally required

Where Can Immutability Be Applied?

Azure supports immutability at two different scopes.

Version-level protection requires: Blob Versioning enabled and ImmutableStorageWithVersioning enabled

Important: A storage account containing immutable data may itself become protected from deletion.

What Happens When You Try to Delete Resources?

Immutability blocks deletion at multiple layers.

Think of it as a dependency chain:

Storage Account
└─ Container
     └─ Blob
        └─ Blob Version

Azure will not allow deletion of a parent resource while protected child resources still exist.

Scenario 1: Deleting the Storage Account

You attempt to delete the storage account.

Azure returns:

Failed to delete storage account 'accountname'.
Error: 'accountname' is protected from deletion.

 

 

 

 

 

 

 

 

 

 

 

 

 

This occurs when at least one container still contains: a locked immutability policy, a legal hold or Immutable blob versions

Before the account can be deleted: every user container must be removed, every blob must be removed, every blob version must be removed and every snapshot must be removed

What About System Containers?

System containers do not block deletion.These are managed automatically by Azure. The containers that matter are user-created containers.

Examples: $logs, $blobchangefeed and $web

Scenario 2: Deleting a Container

You select Delete Container and Azure returns:

The storage account container is protected from deletion due to ImmutableStorageWithVersioning.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Even when, the container appears empty and the latest blobs have been deleted. Deletion may still fail. Why?

Previous blob versions still exist.
This is one of the most common causes of confusion. The Azure Portal normally displays: Only Show Active Blobs

 

 

 

 

 

 

 

As a result, previous versions remain hidden. The container looks empty, but Azure still sees historical versions, snapshots and soft-deleted objects

Although the container may appear empty at first glance, it is not actually empty. When "Show active and  Deleted blobs" is enabled, the container displays all blobs that are currently in either the active or deleted state. Therefore, deletion remains blocked.

 

 

 

 

 

 

 

Deleting containers with immutability (WORM) policies

Container deletion may fail if an Immutable blob storage policy is applied at the container or version level. These policies keep blobs in a non-modifiable, delete-protected state (WORM) for the duration of the defined retention interval.

The behavior depends on the policy State:

Unlocked: the policy can still be edited or removed. You must delete the immutability policy reference from the container before deleting it. Once removed, the container and its blobs can be deleted normally.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Locked: the policy cannot be deleted or shortened. You must wait until the retention interval expires for all affected blobs. Until that time elapses, the blobs, the container, and the storage account cannot be deleted.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Scenario 3: Deleting Individual Blobs

The retention policy prevents deletion of the blob regardless of whether the Delete option appears available in the user interface. Any delete request is rejected by the Storage service until the retention period expires. This indicates that an active retention policy is protecting the blob. Until retention expires: Delete, overwrite and modification are blocked.

Unlocked Policies

Think of this state as a testing phase. Protection is active, but administrators retain management flexibility. You can, Increase or decrease the retention period, or delete the policy. Once the policy is removed, the data becomes deletable. This allows organizations to validate configurations before committing to compliance requirements.

Locked Policies

A locked policy represents a compliance commitment. After locking: the policy cannot be deleted, retention cannot be reduced or extended.

Most importantly:

No user, administrator, or Microsoft Support engineer can bypass or remove a locked retention policy before expiration. i.e If retention is configured for 180 days, deletion becomes possible only after those 180 days have passed.

The Hidden Detail: ImmutableStorageWithVersioning

A common misunderstanding is believing that removing an unlocked retention policy completely disables immutability. It does not.

Once ImmutableStorageWithVersioning is enabled: The feature itself cannot be disabled.

Even if every unlocked policy is deleted, Azure still requires all versions to be removed before containers and storage accounts can be deleted.

Why Version Retention Matters

Blob versioning introduces another important behavior. When you modify version retention and reduce it to a lower value, for example:

 

 

 

 

 

 

 

 

 

 

 

 

Once the version retention period is reduced (for example, from 180 days to 1 day), Azure automatically updates or creates the corresponding Lifecycle Management rule responsible for cleaning up old blob versions.

At this stage, administrators can manually delete any remaining base blobs, snapshots, or versions that are already eligible for deletion.

For versions that still exist and exceed the newly configured retention threshold: No additional manual action is required, the Lifecycle Management rule will automatically identify them as eligible for deletion and all versions older than the configured retention period are processed during subsequent Lifecycle Management executions.

Example, If version retention is changed from 180 days to 1 day: Versions created more than 1 day ago immediately become eligible for cleanup, the Lifecycle Management engine evaluates those versions during its next execution cycle and once the versions are removed, container deletion can proceed provided no other immutable objects remain.

Important Consideration

Lifecycle Management is an asynchronous service. Therefore, after reducing retention: The configuration change is applied immediately, older versions become eligible for deletion immediately and actual version removal may take 24-48 hours or longer, depending on the Lifecycle Management execution schedule.

For this reason, it is normal to see containers remain undeletable for a period of time after retention settings are modified. Administrators should allow sufficient time for Lifecycle Management to complete cleanup of all versions that exceed the configured retention threshold before attempting to delete the container or storage account.

Azure lifecycle rule created automatically after changing the versioning retention. Many administrators are unaware that this happens behind the scenes.

 

 

 

 

 

 

 

 

 

 

Code View for automatic rule created

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The purpose is simple: Remove older blob versions once they exceed the configured age.

Reducing the retention period does not instantly delete existing versions. Instead, it makes existing versions eligible for deletion by Lifecycle Management, which removes them asynchronously during future processing cycles.

Common Misconception

Many customers assume: "Only versions created after I changed the setting will be deleted." This is incorrect.

Azure evaluates every version independently using its creation timestamp. If a version is already older than one day when the rule runs: It becomes eligible for deletion. There is no grandfathering mechanism.

Another Important Detail: Deletion Is Not Immediate

Lifecycle Management follows an asynchronous process.

Typical behavior:

Because of this delay, containers may remain undeletable for some time even after retention settings are updated.

Recommended Cleanup Process

When attempting to remove immutable storage resources:

Step 1 — Inventory all protection mechanisms: Account-level immutability, Container-level policies, Blob-level policies, Legal holds.
Step 2 — Determine policy state: Locked or Unlocked
Step 3 — Remove unlocked policies.
Step 4 — Clear legal holds.
Step 5 — Review versioning and soft delete settings.
Step 6 — Remove all blobs, snapshots, and versions.
Step 7 — Allow Lifecycle Management to remove old versions.
Step 8 — Delete containers.
Step 9 — Delete the storage account.

Important Note: The deletion order is always blobs → container → storage account. A parent resource cannot be removed while protected children remain, so if any blob is still under a Locked policy (or an active legal hold), the entire process is blocked until retention expires or the hold is cleared.

Key Takeaways

✅ Immutable storage protects data against deletion and modification.

✅ Locked policies cannot be bypassed, shortened, or removed.

✅ Legal holds must be manually cleared.

✅ Containers that appear empty may still contain hidden versions.

✅ ImmutableStorageWithVersioning cannot be turned off once enabled.

✅ Blob version retention automatically creates a Lifecycle Management rule.

✅ Storage account deletion requires every protected object underneath it to be removed first.

 

References

• https://learn.microsoft.com/azure/storage/blobs/immutable-storage-overview
• https://learn.microsoft.com/azure/storage/blobs/immutable-policy-configure-container-scope
• https://learn.microsoft.com/azure/storage/blobs/immutable-policy-configure-version-scope
• https://learn.microsoft.com/azure/storage/blobs/data-protection-overview
• https://learn.microsoft.com/azure/storage/blobs/lifecycle-management-overview