Blob (Binary large object) storage is designed for storing massive amounts of unstructured data. A storage account can contain any number of storage containers, each of which can contain nested folders and blobs.

There are multiple blob kinds:

  • Block blobs comprise up to 50,000 blocks which can be inserted, replaced and deleted. They can be up to 190.7TB in size, with a maximum blob size of 4GB.
  • Append blobs are append-only block blobs, ideal for logging and auditing. They're limited to 195GB.
  • Page blobs are optimised for random read/write and back VM disks. These can be up to 8TB.


Changes to blobs are applied immediately.


Leases allow atomic updates, preventing changes from clients until a write completes. IaaS VMs obtain leases on the page blobs behind their disks for this reason.


Snapshots can keep a point-in-time history of the entire blob, allowing administrators to revert contents to a specific snapshot. They have to be taken manually by the client.


Versioning provides automatic snapshots against blob state.

Access tiers

Access tiers (formerly storage tiers) allow configuring performance targets for different blobs:

  • Premium offers the best performance, but is available only for premium block blob storage accounts.
  • Hot is designed for frequently accessed data, charging higher storage costs but reduced access costs.
  • Cool is suited to less frequently accessed data, charging higher access costs but lower storage costs.
  • Archive is suited to archival or compliance data that's unlikely to be accessed. This data isn't directly accessible and there's up to a 15 hour delay while the data is rehydrated to either the cool or hot tiers, unless you pay for the high priority access (<= 1 hour).

Access tier can be set at both the container and (for block blobs) blob level, allowing fine grained management of performance.

Access levels

Access levels are set at both the storage account and blob container levels and dictate the level of access granted without authentication:

  • Private requires authentication for both blob and container access.
  • Blob allows access to blobs within a container, but not enumeration of container and folder contents.
  • Container grants both blob read and container and folder enumeration access.


Billing is based on a number of factors:

  • Total data stored
  • Operation volume
  • Outbound data transfer
  • Geo-replication data transfer

Change feeds

Unlike Storage Analytics at the account level, Blob Change Feeds log only write events and guarantee, and are designed for use by application developers:

  • Ordering, so operations will always be logged in the order that they took place.
  • Durability due to the choice of Apache Avro for serialisation.
  • Immutability by way of the use of append blobs for storage.

Logs are written the the $blobchangefeed container of the storage account within a few minutes

For more immediate processing, logs can be streamed to an Event Grid via the Blob Storage Events source.


Limiting mutability can be required for regulatory compliance in some industries, and is provided across storage account types at no extra cost. Time-based and legal hold retention periods can be configured at the container level. All changes to the configuration are logged for auditing purposes.

Lifecycle management

Lifecycle management allows moving data between access tiers to ensure you're getting the best possible value for money. It's available on GPv2 and Blob Storage accounts and works by specifying rules for blob containers and sets of blobs (via prefix filters and index tags) against read and modification times.

There are three available actions:

  • Move to Hot tier
  • Move to Cool tier
  • Delete blob

The rules are executed once per day.

Static website hosting

Enabling static website hosting allows you to configure the default document and error document and creates the $web container. Files placed in this container will be publicly accessible.

The service can be fronted by Azure CDN or Traffic Manager, though not with authentication and without an SSL certificate, which allows use of a custom domain.

Soft delete

Soft deletion guards against accidental or malicious deletions for 1-365 days, after which blobs are permanently erased. The policy applies to all three blob kinds, but cannot be applied to managed disk resources. The feature is available for GPv1, GPv2, and Blob Storage accounts.

Soft deletion does not protect against deletion of the storage account; ensure you set resource locks for this.

Support for soft deletion of containers is currently in preview.

  1. Data Lake