Azure Storage Account Immutability (Part 1/4): Basics

Azure Storage Account service allows storing massive amount of unstructured data a.k.a BLOB (Binary Large OBject) in cloud. In this article, I shall explain my understanding on a feature named Immutability of Blob Storage, types of immutability supported by Azure, scopes available to configure it and the Storage Account configurations required to use the feature. In the subsequent articles, I shall explain the details & steps to configure each immutability type across the supported scopes. Following are the articles in this series for quick reference.

Azure Storage Account Immutability : Basics *

Azure Storage Account Immutability : Time Based Retention

Azure Storage Account Immutability : Legal Hold Based Retention

Azure Storage Account Immutability : Conclusion

What is Immutability — Something that could not be modified

In the context of Storage Account, Immutability refers to the ability to prevent editing and deleting the Storage Blobs and optionally the versions of each Blob. In other words, it keeps the Blob file (and optionally its versions) in WORM (Write Once Read Many) state.

Azure provides Storage Immutability through 2 options:

1. Time Based Retention — Prevents editing & deleting Blob and optionally its versions for a defined time (anywhere between 1 day to 400 years).
2. Legal Hold — Prevent editing & deleting Blob and optionally its versions indefinitely using Tags.

Immutability Level: The Time based retention and Legal Hold based retention shall be configured either at Blob level or at Blob version level as detailed below.

1. Version level immutability — Immutability at Blob Version level. In this case, the immutability policies are applied at blob & blob version level. Once a blob file is uploaded, it could be read and also be edited/modified, but not deleted; blob versions are maintained by Azure when a blob gets edited. This option requires enabling Blob Version immutability either at Account level (only possible while creating an account) or at Container level (when creating a new container or by migrating an existing container) and Blob Versioning at Account level (pre-requisite to enable Blob Version immutability); refer to screenshots below. Once Blob version immutability is enabled either at Account level or container level, only time based retention could be enabled at Account level and/or Container level and/or directly at specific blob/version level and the “Legal Hold” policy based retention shall not be enabled at Container level, though you could enable “Legal Hold” policy directly at a specific blob/version level. In summary, with Version level immutability enabled at Account or Container level, both Time based retention & Legal hold shall be enabled directly at blob/version level, default time based retention shall be enabled at Account or Container level and Legal hold shall be enabled only directly at blob/version level (no Container level legal hold policy allowed).

Note: Even if a default Time based retention is not configured at Storage Account or Container level, with version level immutability enabled at Account or Container level, the Time based retention shall be directly configured at Blob/version level. The Time based retention at Account/Container level would be used to provide a default Time retention policy while uploading a blob, but could be overridden at Blob/version level. In addition the Legal Hold based retention could also be enabled at Blob/version level in addition to Time based retention.

(https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview#version-level-scope)

(https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview#scenarios-with-version-level-scope)

2. Container level immutability — Immutability at Blob level, is enabled when Blob version level immutability is not enabled at Account & Container level. Since Blob version immutability is not enabled, both Time based retention & Legal hold shall be applied at the same time on a Container. In this case, the immutability policies are applied at blob level and not at blob version level. Once a blob file is uploaded, it could be only read and could not be modified or deleted. Enabling Blob versioning at Account level has no significance when Time based and/or Legal hold based retention is active on a blob file, where the blob could not be edited and that in turn prevents generating new blob versions.

(https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview#scenarios-with-container-level-scope)

Enabling Version level immutability — Immutability at Blob Version level: To enable immutability at blob version level, both Blob versioning and Blob version level immutability needs to be enabled.

Configure Blob versioning: The Blob versioning shall be enabled only at Storage Account level (Storage Account > Data Management > Data Protection > Tracking: Enable versioning for blobs) either while creating or by updating an existing Storage Account.

(Enabling Blob Versioning at Account Level)

Configure Blob Version level immutability: The version level immutability shall be enabled either at (Option #1) Storage Account level or (Option #2) at container level.

Option #1: Enabling version level immutability at Storage Account level is only possible when creating a storage account and this option shall not be enabled after creating the storage account.

(Enabling Version level immutability — option #1 Storage Account Level)

Option #2: Enabling version level immutability at Container level is possible either when creating a new container (Option #2-1) or by migrating an existing container (Option #2-2), provided Blob versioning is enabled at Account level.

Option #2-1 — Enabling blob version level immutability on a new Container:

If blob version immutability is not already enabled at Account level, then it could be enabled at Container level, provided Blob Versioning is already enabled at Account level. The blob version immutability could either be enabled while creating a new container or by migrating an existing container.

(Blob Version immutability is not enabled at Account level and could be enabled at Container level)

Note: If the version level immutability is already enabled at Account level, all the containers in the account would have it enabled by default and it can’t be disabled at container level.

(Blob Version immutability is already enabled at Account level and inherited by container. This cant be disabled at Container level)

Option #2–2 — Migrating an existing container to enable blob version immutability:

To perform this, go to the Container > Select Access Policy > Add policy for Time based retention or edit an existing Time based retention policy > check “Enable version level immutability”.

(Screenshot showing migrating of existing container to enable version level immutability)

(Screenshot showing container is going through migration to enable version level immutability)

Container level immutability — Immutability at Blob level: Allows to maintain both Time based retention policy and Legal hold policy at Container level and are applied only for the blobs in a specific container. The immutability at Blob version level is not supported since blob version level immutability is not enabled at Account/Container level.

The Container level immutability is enabled automatically when Blob version level immutability is not enabled at Account & Container level. No specific steps are required to enable Container level immutability.

In this article, the basics of Storage account immutability, types of immutability supported, scopes available to configure it and the Storage Account configurations required to use it have been discussed.

In the next article, the options & steps to configure Time based retention shall be explained.

Happy Learning !