Azure Blob Storage: Block, Page, and Append Blobs
Blob Storage is Microsoft's object storage for the cloud, optimised for massive amounts of unstructured or non-relational data: text, binary, images, video, backups, data lakes. It authenticates with OAuth 2.0 tokens from Microsoft Entra ID, shared keys, or SAS tokens. Not Kerberos, which is the first thing that separates it from Azure Files. Underneath the single name sit three genuinely different blob types with different size limits and different write behaviour, and one storage account setting that turns the whole service into something else.
Containers and blobs
Three resources make up the model:
- The storage account: which can contain an unlimited number of containers.
- Containers: which organise blobs the way directories organise files. Every blob lives in a container, and a container name must be unique within its storage account.
- Blobs: which can be any type of data and any size.
Objects are reachable worldwide over HTTP or HTTPS via URLs, the Azure Storage REST API, Azure PowerShell, the Azure CLI, or a client library. Available for: .NET, Java, Node.js, Python, PHP, and Ruby. Blob data can also be reached using the NFS 3.0 protocol.
Blob Storage suits applications needing streaming and random-access, and any case where application data has to be reachable from anywhere: serving images or documents directly to a browser, distributed file access, streaming video and audio, backup and archive, and holding data for analysis by an on-premises or Azure-hosted service.
The three blob types
Block blobs are assembled from blocks of data and are the default type for a new blob. Most scenarios use them: files, images, video. A block blob holds up to 50,000 blocks of up to 4,000 MiB each, giving a maximum of roughly 190.7 TiB.
Append blobs are also made of blocks, but optimised for append operations, which makes them the right choice for logging where data accumulates over time. Blocks are capped at 4 MiB and the blob at roughly 195 GiB — dramatically smaller than a block blob, which is the constraint that decides whether a logging design works.
Page blobs are optimised for frequent random read/write operations and max out at 8 TiB. Azure Virtual Machines uses page blobs for operating system and data disks.
One consequence worth knowing early: access tiers apply only to block blobs. You can't set Hot, Cool, Cold, or Archive on an append or page blob, which quietly removes the main cost-optimisation lever for those two types.
Data Lake Storage Gen2 and the hierarchical namespace
Azure Data Lake Storage Gen2 isn't a separate service. It's a set of capabilities layered on Blob Storage, switched on by enabling the hierarchical namespace option on the storage account. It adds a real file system layer with HDFS compatibility and folder-level security through POSIX ACLs.
The reason that matters is mechanical rather than cosmetic. In a flat namespace, "folders" are just part of the object name, so renaming or deleting a directory is a per-object operation across everything beneath it. In a hierarchical namespace, it's a single metadata operation. For analytics workloads that reorganise large amounts of data, that difference is the whole argument.
The Access Control List rule that catches people
POSIX-compliant ACLs require the hierarchical namespace. An ACL is a set of entries specifying access permissions on an object, giving finer control over file and directory permissions than the traditional POSIX permission model.
Assigning a user the Reader, Contributor, or Owner role bypasses the ACLs for read access. If you want ACLs to be evaluated, don't hand out those roles — use the data-plane roles instead.
Scope is the other half of it, and the distinction between the two ACL types is what usually goes wrong:
- A default ACL on the root defines what new folders and files inherit going forward.
- An access ACL on the root changes only the root itself — not its child objects.
- Creating an access ACL or a default ACL on each folder in root doesn't fix permissions for the files already sitting in root.
What the hierarchical namespace costs you
Enabling it is a decision with consequences well beyond the namespace. Several blob features aren't supported on accounts that have it enabled, including point-in-time restore, blob versioning, and object replication. Since versioning is itself a prerequisite for several data protection features, that exclusion cascades further than it first appears. Check the feature support matrix before switching it on, not after.
Blob inventory
A blob inventory rule generates a scheduled report of the blobs, snapshots, and blob versions in an account. This is useful for compliance reporting and for finding which resources carry an immutability policy.
The prefix match string in an inventory policy must start with the container name, followed by the blob name prefix. To capture blobs beginning with finance in container1, the match string is:
container1/finance
Not finance. The container name is not optional, and leaving it off is the usual reason a rule matches nothing.
Scale targets and hot partitions
A blob's partition key combines the storage account name, container name, and blob name. That has a direct consequence for naming schemes: a sequential or append-only prefix — timestamps being the classic case — concentrates traffic on a single partition.
A hot partition throttles with HTTP 503 (Server Busy) or 500 (Operation Timeout) before the account reaches its documented scalability limits, which makes it a confusing failure to diagnose: the metrics say there's headroom, and the requests fail anyway. The mitigations are to avoid sequential prefixes, retry with exponential backoff, and ramp new workloads up gradually rather than all at once.
Common errors
PublicAccessNotPermitted: the request reached the account without valid authorisation. Check you're using a valid access key or a correctly generated SAS token.
AuthenticationFailed after key rotation: the SAS token was signed with a key that has since been rotated, so it's now invalid.
A leaked SAS token: individual SAS tokens can't be revoked. Rotating the associated account key is the only way to invalidate one, and it invalidates every other token signed with that key at the same time. The post on securing storage accounts covers the stored-access-policy approach that avoids this.
Finding the access keys: they're under Security + networking > Access keys on the storage account.