Storage accounts underpin many services, and the redundancy choice decides what failures you survive.
A storage account is a namespace for Azure Storage services: Blob (objects), Queue (simple messages), Files (SMB/NFS shares) and Table (key-value). Its name is globally unique, 3 to 24 lowercase letters and digits, and becomes part of every endpoint: https://<name>.blob.core.windows.net.
Choices made at creation:
- Kind/performance:
StorageV2(general-purpose v2, Standard performance) for almost everything; Premium kinds (BlockBlobStorage,FileStorage) for low-latency workloads. - Redundancy (SKU):
LRS: three copies in one datacenter.ZRS: three copies across availability zones in the region.GRS: LRS plus asynchronous copy to the paired region;RA-GRSadds read access to the secondary.GZRS/RA-GZRS: ZRS in the primary plus geo copy.
Geo replication is asynchronous, so a regional failover can lose recent writes; check lastSyncTime.
Secure defaults to set: disable anonymous blob access, require TLS 1.2, and disable shared key access (--allow-shared-key-access false) so every request uses Entra ID instead of account keys, which grant full control to whoever holds them.
Example
az storage account create -g rg-data -n stordersprod01 \
--kind StorageV2 --sku Standard_ZRS --location westeurope \
--min-tls-version TLS1_2 \
--allow-blob-public-access false \
--allow-shared-key-access false
az storage account show -g rg-data -n stordersprod01 \
--query "{sku:sku.name, blob:primaryEndpoints.blob}"
# { "sku": "Standard_ZRS", "blob": "https://stordersprod01.blob.core.windows.net/" }Remember
- One account = blob, queue, file and table endpoints under a global name
- LRS < ZRS < GRS/GZRS in resilience and price
- Geo replication is asynchronous
- Prefer Entra ID auth and disable shared keys
Watch out for
- Choosing LRS for data that must survive a zone outage.