Azure storage types explained: Blob, Data Lake, Files, Disks, Queues, Tables, NetApp Files and more, with the workload each one fits

#The one question that decides it

Before looking at any service, ask how the application reads and writes the data:

Get the access pattern right and most of the other choices (performance, cost, backup) follow from it. Pick the wrong family and no amount of tuning fixes it.

#Storage accounts: the container for four services

Blob, Files, Queue and Table all live inside a storage account. The account sets the name (<name>.blob.core.windows.net), the redundancy, the network rules and the default access tier.

General-purpose v1 and legacy BlobStorage accounts still exist, but don't create new ones; upgrade them to v2.

#Redundancy options

Premium accounts support LRS and, in many regions, ZRS. Geo-redundancy is Standard only. For how failover works, see Azure Storage geo-redundancy and failover.

Warning

Redundancy is not backup. If someone deletes a container, the delete is replicated to every copy. Turn on soft delete and versioning as well; see recovering deleted blobs and containers.

#Blob Storage: objects at any scale

Blob Storage holds unstructured data as objects in containers. There are three blob types:

• Block blobs: files, images, backups, logs, Parquet. This is 99% of usage.
• Append blobs: optimised for appending only, such as log files written by many writers.
• Page blobs: random-access 512-byte pages; the format behind VHDs.

#Access tiers

Storage gets cheaper as you go down the table, but reads and transactions get more expensive. Archive is supported on LRS, GRS and RA-GRS accounts, not on ZRS or GZRS. Automate the moves with lifecycle rules: Azure Blob lifecycle management and access tiers.

# Move one blob to Cool, and rehydrate an archived blob with high priority
az storage blob set-tier --account-name stdata01 --container-name reports \
  --name 2025/q4.parquet --tier Cool --auth-mode login

az storage blob set-tier --account-name stdata01 --container-name archive \
  --name 2019/ledger.csv --tier Hot --rehydrate-priority High --auth-mode login

#Key features

• Soft delete for blobs and containers, versioning, point-in-time restore.
• Immutable storage (time-based retention and legal hold) for WORM compliance.
• Object replication between accounts, change feed, blob index tags.
• Static website hosting from the $web container.
• Entra ID RBAC (Storage Blob Data Reader/Contributor), SAS tokens, private endpoints.

Use it for: backups and archives, media, application uploads, log retention, static websites, landing zones for data pipelines.

#Data Lake Storage Gen2: Blob with folders and ACLs

Data Lake Storage Gen2 is not a separate service. It is a StorageV2 account with hierarchical namespace (HNS) enabled. That gives you:

• Real directories: renaming or deleting a folder is one atomic operation, not millions of blob copies.
• POSIX-style ACLs on folders and files, on top of RBAC.
• The abfss:// driver used by Spark, Databricks, Synapse and Fabric shortcuts.
• Optional NFS 3.0 and SFTP endpoints.

az storage account create -g rg-data -n stlakeprod01 -l centralindia \
  --kind StorageV2 --sku Standard_ZRS --hns true \
  --min-tls-version TLS1_2 --allow-blob-public-access false

Tip

Decide on HNS when you create the account. An existing account can be upgraded, but the upgrade is one-way and some Blob features behave differently with HNS, so test first.

Use it for: data lakes, lakehouse (Delta, Iceberg), Databricks and Synapse workloads, big-data analytics. See storage options for Databricks.

#Azure Files: managed file shares

Azure Files gives you SMB and NFS shares without running a file server.

Key features: identity-based SMB auth (on-premises AD DS, Entra Domain Services or Entra Kerberos for hybrid identities), share snapshots, Azure Backup integration, and Azure File Sync, which caches a share on Windows file servers on-premises.

# Premium account + NFS share (NFS needs a private endpoint or service endpoint, not public access)
az storage account create -g rg-app -n stfilesprem01 -l centralindia \
  --kind FileStorage --sku Premium_ZRS --https-only false
az storage share-rm create -g rg-app --storage-account stfilesprem01 \
  --name appdata --quota 1024 --enabled-protocols NFS --root-squash RootSquash

--https-only false is needed only because NFS 4.1 does not use HTTPS; keep the account private with network rules.

Warning

SMB uses TCP 445, which many ISPs and corporate networks block. Users connecting from home usually need a VPN or private connectivity.

Use it for: lift-and-shift file servers, shared app configuration, user profiles (FSLogix for AVD), container persistent volumes that need ReadWriteMany.

#Managed disks: block storage for VMs

Managed disks are virtual disks attached to one VM (or several, with shared disks).

az disk create -g rg-db -n sqldata01 -l centralindia --zone 1 \
  --sku PremiumV2_LRS --size-gb 512 \
  --disk-iops-read-write 8000 --disk-mbps-read-write 300

Also worth knowing: ephemeral OS disks (stored on the host, free, lost on reallocation; good for stateless scale sets and AKS nodes), shared disks for clustered workloads such as SQL Server FCI, and disk snapshots for quick restore points. Right-sizing guidance: managed disks and Premium SSD v2.

Use it for: VM OS disks, databases on IaaS VMs, any application that expects a local drive letter or mount.

#Queue Storage and Table Storage

Queue Storage is a simple, cheap message queue over HTTPS. Messages are up to 64 KB, and a queue can hold millions of messages. Use it to decouple a web front end from background workers. If you need ordering, sessions, topics or dead-lettering, use Azure Service Bus instead.

Table Storage is a NoSQL key-attribute store addressed by PartitionKey and RowKey. It is cheap and fast for lookups by key, but it has no secondary indexes. If you need global distribution or secondary indexes, use Azure Cosmos DB for Table (same API).

az storage queue create --account-name stapp01 --name orders --auth-mode login
az storage table create --account-name stapp01 --name devicestatus --auth-mode login

Use them for: job queues, simple event hand-off, device or session state, audit records looked up by key.

#Specialist storage services

For a deeper comparison of the file and block options, read choosing between Blob, Files, NetApp Files, disks and Elastic SAN.

#Which storage for which workload

#Quick checklist before you create anything

1. Access pattern: object, file (SMB/NFS), block, queue or table?
2. Performance: is Standard enough, or do you need Premium / Premium SSD v2 / Ultra?
3. Redundancy: LRS for dev, ZRS for production, GZRS when you need a regional DR copy.
4. Tiering: will the data cool down? Add lifecycle rules on day one.
5. Security: disable public blob access and shared key where possible, use private endpoints and Entra ID RBAC. Baseline: Azure Storage account secure baseline.
6. Protection: soft delete, versioning, Azure Backup or snapshots, depending on the service.
7. Cost: check the current pricing page for capacity, transactions, egress and early-deletion charges; transaction costs often surprise teams more than capacity.

#Prevent it next time

• Put the decision table above into your landing zone design document so teams pick storage by workload, not by habit.
• Enforce the basics with Azure Policy: allowed SKUs, secure transfer, no public blob access, minimum TLS 1.2.
• Review storage monthly with Azure Advisor and Cost Management to catch Hot data that should be Cool, and oversized Premium disks.