Overview
Azure Storage covers three genuinely different access patterns under one umbrella: Blob for API-driven unstructured object storage, File for network-mountable file shares, and Disk for a VM's own block storage. Two orthogonal choices then apply mostly to Blob Storage, redundancy (how many copies exist and where, which is a durability decision) and access tier (Hot/Cool/Archive, which is a cost-versus-retrieval-speed decision, not a durability one). Conflating these two, assuming a cheaper tier means less durable data, or that geo-redundancy means instantly readable in the secondary region, is the most common source of storage design mistakes.
Quick Reference
| Service | Access pattern | Typical use |
|---|---|---|
| Blob Storage | HTTP/HTTPS object API | Unstructured data at scale, images, backups, logs |
| File Storage | SMB/NFS mountable share | Shared network drive across multiple VMs |
| Disk Storage | Block storage, attached to one VM | A VM's own persistent virtual hard disk |
| Redundancy | Protects against | Consistency |
|---|---|---|
| LRS | Hardware failure within a datacenter | Synchronous |
| ZRS | Datacenter failure within a region | Synchronous |
| GRS | Regional disaster | Asynchronous to secondary region |
Syntax
az storage account create \
--name appuploadsprod --resource-group rg-app \
--sku Standard_GRS --kind StorageV2Examples
# Access tier changes cost and retrieval speed, not durability;
# an Archive blob has identical durability to a Hot blob with the
# same redundancy setting, but takes hours to rehydrate before read.
az storage blob set-tier \
--container-name backups --name 2026-01-full.bak \
--tier ArchiveRA-GRS still means asynchronous replication
Even with read access enabled on the secondary region, GRS replication is asynchronous, recent writes may not have propagated yet. Don't assume the secondary region is a real-time mirror; it's a disaster-recovery copy, not a synchronous replica.
Visual Diagram
Common Mistakes
- Assuming a cheaper access tier (Cool, Archive) means less durable data; durability is entirely determined by the redundancy setting, not the tier.
- Treating RA-GRS's secondary region as synchronously up to date, then being surprised by stale reads during a failover.
- Storing frequently accessed data in the Archive tier to save on storage cost, then paying far more in retrieval cost and multi-hour rehydration delay than was saved.
- Using Disk Storage where Blob Storage would fit better (e.g., storing application-generated files that don't need to live on a specific VM's attached disk).
Performance
- Blob Storage access latency is generally higher than a locally attached Disk, since it's accessed over HTTP(S) rather than as a block device, the trade-off is scalability and API-driven access versus raw local I/O speed.
- Archive tier retrieval isn't just slower, it's asynchronous by design, rehydration can take hours, so it is unsuitable for anything on a request-serving path.
- File Storage performance tiers (Standard vs. Premium) affect IOPS and throughput ceilings for shared-drive workloads the same way disk performance tiers do for VM-attached storage.
Best Practices
- Choose the storage service based on access pattern first (API-driven object, mountable share, or VM-attached disk), not on habit.
- Set access tiers based on actual access frequency, and use lifecycle management policies to automatically transition aging data to cheaper tiers instead of doing it manually.
- Choose redundancy (LRS/ZRS/GRS) based on the actual failure domain you need to survive, not reflexively picking the most redundant (and expensive) option everywhere.
- Never assume a secondary GRS region is real-time consistent, design any failover process around its asynchronous replication lag.