Locking Down Azure Blob Storage: Container Immutability Policies for Audit Data

The problem: cleanup scripts and compliance conflicts

Audit logs, financial records, and other compliance data in Azure Blob Storage are vulnerable to the same operational actions that keep other storage tidy: lifecycle rules, manual deletions, and overwrite operations. A container-level immutability policy solves this by enforcing WORM (Write Once, Read Many) semantics on every blob in a container for a fixed retention period. The useful takeaway is that the policy is easy to create and nearly impossible to undo once locked, so the engineering decision centers on validating the retention period before you commit.

How the policy works

An immutability policy is container metadata. In its unlocked state, it records an intended retention interval but does not yet block operations. You can extend the period while it remains unlocked. When you lock the policy, the storage service rejects delete and overwrite operations on all blobs in the container—including blobs that existed before the policy was created—until the interval elapses.

This is distinct from a legal hold. A legal hold is a separate, clearable tag that also protects blobs from deletion. A locked immutability policy, by contrast, cannot be removed or shortened before its retention period ends. Deleting the storage account is the only way to bypass a locked policy, which makes account deletion a destructive last resort rather than a routine rollback.

Worked configuration with Azure CLI

Run these commands in Azure CLI (Cloud Shell or a local terminal after az login). Use a disposable storage account and container to validate behavior before enforcing the policy on production data. Replace sa1 with your storage account name and audit with your container name. The identity running the commands needs permission to manage container policies and blob data on the account.

az storage container create \
  --name audit \
  --account-name sa1 \
  --public-access off

Create the immutability policy in an unlocked state with a whole-day period. In this example, the period is 100 days.

az storage container immutability-policy create \
  --account-name sa1 \
  --container-name audit \
  --period 100

Inspect the policy to confirm the retention interval and state. The output should show the period you set and an Unlocked state.

az storage container immutability-policy show \
  --account-name sa1 \
  --container-name audit

While the policy is unlocked, deletion is still possible. Upload a test blob and delete it to establish the baseline if you want to confirm this behavior in your tenant.

az storage blob upload \
  --account-name sa1 \
  --container-name audit \
  --name test.txt \
  --file test.txt

az storage blob delete \
  --account-name sa1 \
  --container-name audit \
  --name test.txt

When you are certain the period is correct, lock the policy. This is a state change: the policy becomes immutable in its configuration and the service begins enforcing WORM protection.

az storage container immutability-policy lock \
  --account-name sa1 \
  --container-name audit

After locking, attempt to delete a blob. The service should reject the operation with an error indicating the blob is protected by an immutability policy. This is the practical check that the policy is active.

az storage blob delete \
  --account-name sa1 \
  --container-name audit \
  --name test.txt

Limits and common mistakes

Behavior	What actually happens
Shortening a locked policy	Not possible. The retention period can only be extended, never reduced, before it expires.
Existing blobs	Protected. Blobs written before the policy was created are subject to the same delete and overwrite restrictions.
Retention granularity	Whole days only. Fractional periods are rejected.
Backup and replication	Immutability does not replace backup, cross-region replication, or disaster recovery planning.

A frequent mistake is locking the policy before validating the retention period. Once locked, a mistaken 365-day policy cannot be corrected to 30 days; you must either wait out the interval or delete the storage account. Another mistake is assuming immutability controls soft-delete snapshots. Soft delete is an independent feature with its own retention settings; a locked immutability policy does not automatically govern snapshot deletion behavior.

Confusing immutability with legal hold also causes operational surprises. Legal holds are designed for litigation or investigation scenarios and remain clearable by an administrator. A locked immutability policy is designed for fixed compliance retention and is not clearable. Use legal hold when you need a temporary, revocable hold; use a locked immutability policy when the retention interval itself must be tamper-proof.

Verification before production

Validate the workflow against a disposable storage account. Confirm that az storage blob delete fails after the policy is locked, and inspect az storage container immutability-policy show to verify the period and state. You can also review the policy in the Azure portal under the container's Immutability policies settings. Current Azure CLI command names and retention limits can change, so confirm the exact syntax and maximum period against the Azure CLI and Storage documentation before deploying the pattern at scale.

Immutability protects blob data and metadata from delete and overwrite operations. It does not protect against storage account key compromise, subscription-level deletion, or Azure platform outages. Treat the locked policy as one layer in a broader data protection strategy, not as a complete safeguard.