Blob Storage

Blob Storage is an infinite hard drive you rent by the gigabyte-month, where every file has a URL. You PUT an object under a name into a container, inside a storage account, and GET it back over HTTPS. There is no filesystem, no server to patch, and no capacity to provision — you pay for the bytes you keep and the requests you make.

Names: the service is Azure Blob Storage, one of the four services inside an Azure Storage account (Blob, File, Queue, Table). Its hierarchical-namespace variant is Azure Data Lake Storage Gen2 (ADLS Gen2) — not a separate product but a feature flag on a storage account, which is the single most misunderstood thing about it. You will still see "Data Lake Storage Gen1" in older material; that is a genuinely separate, now-retired service. "Classic" (Microsoft.ClassicStorage) storage accounts are also retired; this topic uses the Resource Manager model throughout.

What it is and where it fits

Blob Storage is object storage: a flat key-value store where the key is a string that may contain slashes and the value is an opaque sequence of bytes up to several terabytes long, addressed at https://<account>.blob.core.windows.net/<container>/<blob>. It is the cheapest durable place to put data in Azure and, by volume, where most Azure data lives — backups, logs, images, video, model artifacts, parquet files, and the state behind half the other services in the catalogue.

The problem it solved is the one every growing system hits: file storage that must survive hardware failure, scale past a single machine, be reachable from anywhere, and cost roughly nothing when idle. Doing that yourself means disks, RAID, replication, a serving fleet, and a capacity plan. Blob Storage replaces all of it with an HTTP endpoint and a bill measured in gigabyte-months.

The thing that most often trips people up is that Blob Storage is not a filesystem, even though it looks like one. Directories are a naming convention — logs/2026/07/29/app.log is a single flat key containing slashes, not four nested objects — unless you enable the hierarchical namespace, at which point directories become real and rename becomes an atomic metadata operation instead of a copy-and-delete.

Azure's storage catalogue overlaps itself, so separate the neighbours in a line each:

• Azure Files — a real SMB/NFS file share you can mount as a drive letter. Choose it when an application expects a POSIX or Windows filesystem and you can't change it. Costs more per GB and scales lower than Blob.
• Managed Disks — block storage attached to exactly one VM at a time. Choose it for an OS disk or a database's data files. Not addressable by URL, not shareable, billed on provisioned size.
• Azure NetApp Files — enterprise-grade NFS/SMB with very low latency for workloads that a file share won't satisfy (SAP, HPC scratch). Expensive; a deliberate choice, never a default.
• Cosmos DB / Azure SQL — for anything you need to query by value, index, or transact over. If you find yourself listing blobs to find one, you wanted a database.
• Azure Data Lake Storage Gen2 — Blob Storage with the hierarchical namespace turned on. Choose it for analytics; see the trade-offs in Core Concepts.

If you're coming from AWS: Blob Storage is S3, and the analogy carries you most of the way — bucket ≈ container, object ≈ blob, storage class ≈ access tier, presigned URL ≈ SAS token. Where it breaks: the storage account is a real, consequential layer above the container that has no S3 equivalent. It owns the redundancy setting, the firewall and network rules, the encryption keys, the performance tier, the endpoints, and — critically — most of the quotas and throughput limits. In S3 you make a bucket and stop thinking about the account; in Azure the account is the resource you actually design.

Key facts at a glance

Category	Storage — object storage
Resource provider	Microsoft.Storage/storageAccounts (blobs live under the blobServices/containers child types)
Data-plane endpoint	https://<account>.blob.core.windows.net — separate from ARM, with separate RBAC
Scope	The account is regional (with a zonal or geo option chosen via redundancy); the name is globally unique across all of Azure
The SKU axis	Two axes multiplied: performance tier (Standard vs. Premium block blob) × redundancy (LRS / ZRS / GRS / GZRS, each with a read-access RA- variant). Plus a per-blob access tier: Hot / Cool / Cold / Archive
The kind axis	StorageV2 (general purpose v2) is the default and correct answer; BlockBlobStorage is the premium-only kind; BlobStorage and Storage (v1) are legacy
The feature flag that changes everything	is_hns_enabled — the hierarchical namespace, i.e. ADLS Gen2. Set at creation and irreversible
Unit of billing	Per GB-month stored (rate varies by access tier) + per 10,000 operations (rate varies by tier and operation class) + egress + optional features (versioning, soft delete, and change feed all store extra bytes you pay for)
The billing trap	Archive tier is nearly free to store and expensive to read and has an early-deletion charge — delete an archived blob before its minimum retention and you're billed as if you'd kept it. Same trap, smaller, for Cool and Cold
SLA posture	Higher for read-access geo-redundant accounts than for locally-redundant ones; Archive reads are explicitly excluded from the latency SLA ⚠️ verify current percentages against current Azure docs
Usual companions	Microsoft Entra ID + Azure RBAC, Private Endpoint + Private DNS, Key Vault (for customer-managed keys), Event Grid, Azure Functions, Azure Data Factory, Azure Monitor, Front Door / CDN
Primary alternative	Azure Files (needs a filesystem), Managed Disks (needs block storage), a database (needs queries)
AWS rough analogue	S3 — with the storage account as the extra layer that has no S3 equivalent

When to use Blob Storage

• Anything large, immutable, and read by key — images, video, PDFs, firmware, installers, model weights, build artifacts.
• Backups and archives, where the lifecycle policy can push cold data to Cool, Cold, or Archive and cut the bill by an order of magnitude.
• A data lake — parquet/delta files read by Databricks, Synapse, or Fabric. Enable the hierarchical namespace and you get directory semantics and POSIX-style ACLs on top of object economics.
• Log and telemetry landing zones — append blobs and diagnostic settings both write here natively.
• Static website hosting and CDN origin — a static site served straight from $web, fronted by Front Door.
• The staging area between two systems — the "drop a file, fire an event" pattern with Event Grid and Functions is one of the most-used integrations on Azure.
• Anywhere you need a time-limited, scoped, credential-free download link — that's a user-delegation SAS.

When not to use Blob Storage

• As a database. There is no query, no index, no transaction across blobs, and List is a paged, lexicographic scan. If your access pattern is "find the blob where status = pending", you wanted a table.
• As a mounted filesystem for a legacy app. BlobFuse and NFS 3.0 support exist, but they are emulation with real caveats around consistency and locking. If the application genuinely needs POSIX semantics, use Azure Files.
• For low-latency small reads at high frequency. Every read is an HTTPS round trip. Single-digit millisecond consistency at scale is Cosmos DB's job, or Redis's.
• For write-heavy workloads that update in place. Blobs are replaced, not edited (page and append blobs are the narrow exceptions). Read-modify-write on a large blob is a full rewrite.
• When the data is small, hot, and highly relational. The per-operation cost and per-request latency dominate; you're paying object-storage overhead for database-shaped work.
• Archive tier for anything you might need soon. Rehydration is measured in hours, not seconds, and you cannot read an archived blob without rehydrating or copying it first.

What this topic covers

Sub-topic	What it covers
What & Why	The problem object storage solves, where it sits against Files and Disks, the S3 analogy and where it breaks, and the honest anti-patterns
Core Concepts	Storage accounts, containers, the three blob types, access tiers, redundancy, SAS vs. RBAC, the hierarchical namespace, and the SKU traps
Architecture	What actually happens during an upload, the partition layer, control plane vs. data plane, consistency and durability, scale targets, and throttling
Getting Started	One container and one blob, three ways — portal, az CLI, and a minimal Terraform snippet — plus teardown
Deployment	A parameterised Terraform module, remote state in a blob container, an Ansible playbook, the Bicep equivalent, OIDC-based CI/CD, environments, rollback, and drift
Integrations	Event Grid, Functions, Data Factory, Front Door, Key Vault, Private Link, and the two glue mechanisms that recur everywhere
Production	Security, cost, scaling and quota scopes, observability, and reliability — the five pillars that separate a demo from a running system
Interview Questions	Three tiers of questions with answer keys, from "what is a blob" to "someone changed the firewall by hand, now what"
Glossary & Cheatsheet	Every term in one line each, the commands you'll actually type, the resource ID shape, and the limits worth memorising

Three ideas worth carrying into every other page

The storage account is the unit of everything. Limits, throughput, firewall rules, redundancy, encryption keys, the private endpoint, the diagnostic setting, and the name's global uniqueness all live on the account, not the container. The practical consequence is that "one account for everything" is how teams hit throttling with no idea why, and how one team's noisy pipeline slows another's API. Design accounts as blast-radius and throughput boundaries, not as folders.

Control plane and data plane have separate RBAC, and this catches everyone exactly once. Being Owner on a storage account does not let you read a blob through Entra ID auth. Contributor is a control-plane role; Storage Blob Data Reader is a data-plane role. The reason Owner appears to work in the portal is that the portal quietly falls back to the account access keys — which is also why disabling shared-key access is the moment this distinction stops being theoretical.

Two settings are irreversible and both are set at creation. The hierarchical namespace cannot be turned on or off after the account exists, and the account name is globally unique and, thanks to soft delete on the account, may remain reserved after you delete it. Every migration story in this topic starts with one of these two decisions being made carelessly.

Reading paths

New to object storage — What & Why → Core Concepts → Getting Started. Upload a file, delete the resource group, then come back for Architecture.

Coming from S3 — skim What & Why, then go straight to Core Concepts for the account/container/blob-type model and Architecture for the control-plane / data-plane split, which has no clean S3 equivalent.

Need to ship this week — Deployment first, then Production. Getting Started is deliberately throwaway; don't build on it.

Building a data lake — the hierarchical-namespace section of Core Concepts, then Integrations for the Data Factory and Databricks wiring, then the security section of Production for ACLs vs. RBAC.

Interview or certification prep — Core Concepts, Architecture, and Interview Questions. The redundancy-options question and the SAS-vs-RBAC question come up constantly.

Chasing a cost surprise — the cost section of Production, then the access-tier and lifecycle discussion in Core Concepts. Early-deletion charges, versioning with no expiry policy, and transaction costs on Cool data are the usual three culprits.

---

Next: What & Why →

← Back to the article