Azure Storage Redundancy: LRS, ZRS, GRS, and GZRS
Redundancy is chosen per storage account and decides how many copies of your data exist and where they live. It's one of the settings people pick quickly at creation time and regret slowly, because the failure it protects against is the one you haven't had yet. The six options look like a list of acronyms, but they're built from just two independent decisions: how data is replicated inside the primary region, and whether it's replicated out of that region at all.
Redundancy in the primary region
The primary region is chosen when the account is created, and it supports two replication options.
Locally redundant storage (LRS) is the cheapest and least durable. It replicates data three times within a single physical location in the primary region, protecting against drive and server rack failures. If that data centre is lost, every replica can be lost with it.
Zone-redundant storage (ZRS) replicates data synchronously across three Azure availability zones in the primary region. Separate physical locations with independent power, cooling, and networking. It protects against the loss of a whole data centre, and data stays available for both reads and writes if a zone goes down. ZRS isn't offered in every region.
Adding a secondary region
A secondary region is recommended for applications that need high durability, and three of its properties are worth internalising before relying on it:
- The paired secondary region is determined by the primary and can't be changed. You don't get to choose it.
- It's usually geographically distant from the primary, which is what protects against a regional disaster.
- Replication to the secondary is asynchronous. A failure that destroys the primary before replication catches up loses whatever was in flight.
Geo-redundant storage (GRS) replicates three times in the primary region using LRS, then asynchronously to a single physical location in the paired secondary region, where it's stored with LRS again. Six copies in total.
Geo-zone-redundant storage (GZRS) combines the two: ZRS in the primary region, asynchronously replicated to a secondary region where it's stored with LRS. The most resilient and most expensive option.
The only difference between GRS and GZRS is how data is replicated in the primary region — within the secondary, data is always replicated synchronously with LRS either way.
Read access to the secondary
With plain GRS or GZRS, the secondary copy isn't available for read or write access at all unless a failover happens. It exists purely as insurance.
RA-GRS and RA-GZRS add read access to the secondary region. Writes still go to the primary, so reads served from the secondary can be stale, and the read access costs extra. It's useful for disaster recovery scenarios and for serving users from a geographically closer location, but it isn't a substitute for a proper multi-region architecture, because the write path hasn't moved.
If the primary becomes unavailable, you can fail over to the secondary. After the failover completes, the secondary becomes the primary, and reads and writes resume against it.
The six options side by side
| Option | Primary region | Secondary region | Total copies |
|---|---|---|---|
| LRS | Three copies in one physical location, synchronous | — | 3 |
| ZRS | Three copies across three availability zones, synchronous | — | 3 |
| GRS | LRS, synchronous | LRS in the paired region, asynchronous | 6 |
| RA-GRS | LRS, synchronous | LRS in the paired region, asynchronous, readable | 6 |
| GZRS | ZRS, synchronous | LRS in the paired region, asynchronous | 6 |
| RA-GZRS | ZRS, synchronous | LRS in the paired region, asynchronous, readable | 6 |
Reading it by failure mode instead
The table above describes the mechanism. This one answers the question you actually have:
| Failure | Options that survive it |
|---|---|
| A node in a data centre is unavailable | All six |
| An entire data centre is unavailable | ZRS, GRS, RA-GRS, GZRS, RA-GZRS |
| A region-wide outage | GRS, RA-GRS, GZRS, RA-GZRS |
| Read access during a region-wide outage | RA-GRS, RA-GZRS only |
That last row is the one that catches people. Surviving a regional outage and being able to read your data during one are different requirements, and only the read-access variants satisfy the second.
Choosing
Not every redundancy option is available in every Azure region, so the first check is whether the level you want exists where you're deploying. Microsoft's own recommendation for high availability is ZRS in the primary region plus replication to a secondary.
Two constraints from elsewhere in the platform cut across this choice and are worth knowing before committing:
The Archive access tier is only supported on LRS, GRS, and RA-GRS accounts not ZRS, GZRS, or RA-GZRS. If a workload needs both zone redundancy and archival storage, those requirements conflict at the account level. I've covered the tiers and their constraints in the post on blob access tiers.
Azure Files can't read from the secondary region, even in an RA-GRS or RA-GZRS account. You can provision a file share there, and it's billed as geo-redundant, but the read-access half doesn't apply. That's covered in the post on Azure Files share tiers and protocols.
Redundancy is also distinct from object replication, which is a separate, user-configured feature for asynchronously copying blobs between accounts, different mechanism, different purpose, covered in its own post.