AZ-104 · Implement and manage storage · Updated August 7, 2026
Azure Storage Redundancy Options Compared: LRS, ZRS, GRS, GZRS, and the RA- Variants
Every Azure Storage account carries a redundancy setting, and that one setting answers two separate questions at once: how many copies of your data exist inside the primary region, and whether a copy also exists in a second region hundreds of miles away. Azure Storage offers six named combinations of answers to those two questions: LRS, ZRS, GRS, GZRS, and the read-access variants RA-GRS and RA-GZRS. The setting applies to the entire storage account, not per container or blob, so an administrator picks one option per account and lives with its tradeoffs across everything stored there.
Two independent axes, not six unrelated options
It helps to stop thinking of the six names as six different products and instead see them as two independent choices stacked together. The first choice is how data replicates within the primary region: to a single datacenter (LRS) or synchronously across three or more availability zones in that region (ZRS). The second choice is whether that primary-region copy is also asynchronously replicated to a paired secondary region, and if so, whether the secondary copy is readable at any time (the RA- prefix) or only after a failover. Once those two axes are separated, GZRS stops looking like a mysterious fifth option and becomes exactly what it is: ZRS in the primary region, plus GRS-style replication to a secondary region.
LRS and ZRS: what protects the primary region
Locally redundant storage (LRS) keeps three synchronous copies of every object within a single datacenter. It’s the cheapest tier because it does the least work, and it provides at least 99.999999999% (eleven 9s) durability over a given year. LRS survives a failed disk, server, or rack, but a datacenter-level event, fire, flooding, or a cooling failure, can take out every copy at once, since nothing exists outside that one building.
Zone-redundant storage (ZRS) spreads the same three synchronous copies across three or more availability zones, physically separate datacenters with independent power and networking inside the primary region. Because it survives a full datacenter loss, ZRS reaches at least 99.9999999999% (twelve 9s) durability. Microsoft specifically recommends ZRS for Azure Files workloads (clients don’t need to remount a file share if a zone goes down) and for Azure Data Lake Storage workloads on the primary region. Neither LRS nor ZRS moves any copy outside the primary region, which makes ZRS the answer whenever a scenario needs datacenter-level resiliency alongside a data-residency rule that forbids storing data outside the region.
GRS, GZRS, and their read-access variants
Geo-redundant storage (GRS) takes an LRS primary copy and asynchronously replicates it to a paired secondary region, where it’s stored using LRS again. Geo-zone-redundant storage (GZRS) does the same thing but starts from a ZRS primary copy instead of LRS. In both cases, the secondary region itself is always plain LRS, never zone-redundant, regardless of how the primary is configured. Both GRS and GZRS reach at least 99.99999999999999% (sixteen 9s) durability over a given year, the highest tier Azure Storage publishes.
Neither option makes the secondary copy accessible under normal conditions; applications can’t read or write it until a failover occurs. Read-access geo-redundant storage (RA-GRS) and read-access geo-zone-redundant storage (RA-GZRS) remove that restriction by exposing a permanent, separate read-only endpoint against the secondary region (the storage account name with -secondary appended), reachable at any time with no failover required. A scenario that needs the secondary copy readable continuously, not just after a disruptive failover, always calls for the RA- prefix.
One recent addition worth knowing: Azure Storage’s geo priority replication feature now targets a recovery point objective (RPO) of 15 minutes or less specifically for block blobs on geo-redundant accounts, tightening how far behind the secondary copy can realistically fall during normal operation.
Failover: three types, and they behave differently
Administrators, not just applications, are responsible for failover on geo-redundant accounts. Microsoft’s disaster recovery and storage account failover guidance documents three distinct kinds, and AZ-104 expects you to know all three:
| Failover type | Who initiates it | Typical use | Expected data loss | Effect on redundancy setting |
|---|---|---|---|---|
| Customer-managed planned | You | Disaster recovery testing, proactive prep for a known event | No | Retained (GRS stays GRS, GZRS becomes GRS) |
| Customer-managed unplanned | You | Primary region endpoints are actually down | Yes | Lost: account converts to LRS in the new primary |
| Microsoft-managed | Microsoft, only in extreme regional disasters | Catastrophic, entire-region failures | Yes | N/A, can’t be triggered for one account |
A planned failover swaps primary and secondary cleanly with no expected data loss, as long as both regions stay available throughout, and it’s the only type Microsoft recommends for actually testing a disaster recovery plan. An unplanned failover is a genuine emergency measure: because replication to the secondary is asynchronous, any writes that hadn’t yet reached the secondary region before the outage are gone permanently, and the account is automatically demoted to LRS in its new primary region afterward, so geo-redundancy has to be manually re-enabled, and re-replicated at a cost, once things stabilize. Microsoft-managed failover should never be relied on as an actual disaster recovery plan, since it can’t be triggered for an individual storage account, subscription, or tenant, only for an entire physical region in extreme circumstances. Most failovers complete in under an hour once initiated.
Comparing the six options at a glance
| Option | Primary region copies | Secondary region | Secondary readable without failover | Durability |
|---|---|---|---|---|
| LRS | Single datacenter | No | N/A | 11 nines |
| ZRS | Across availability zones | No | N/A | 12 nines |
| GRS | Single datacenter | Yes | No | 16 nines |
| RA-GRS | Single datacenter | Yes | Yes | 16 nines |
| GZRS | Across availability zones | Yes | No | 16 nines |
| RA-GZRS | Across availability zones | Yes | Yes | 16 nines |
Choosing between them
Cost rises with every layer of protection added: zone spread costs more than a single datacenter, geo-replication costs more than staying in one region, and read access to the secondary costs more than leaving it dormant. The administrator’s job is picking the least protection that still satisfies the stated requirement, not the most protective option available. Easily-regenerated or low-value data belongs on LRS; anything needing datacenter-level resiliency with a strict data-residency constraint belongs on ZRS; workloads that can’t tolerate losing a region, with applications built to read continuously from a secondary, are what RA-GZRS exists for.
What redundancy doesn’t protect against
Redundancy replicates every change, including destructive ones. An accidental container deletion or an overwritten blob propagates to every synchronous and asynchronous copy just as fast as a legitimate write, so raising an account from LRS to RA-GZRS does nothing to undo human error. Guarding against accidental deletion or overwrite is a separate concern handled by soft delete and blob versioning, or by a real backup product like Azure Backup, distinct from redundancy and from Site Recovery.
How the AZ-104 exam tests this
- A scenario stacks datacenter-loss protection with a data-residency requirement. Anything with “geo” in the name replicates outside the region, so the answer is always ZRS.
- A scenario needs continuous reads from a secondary region without a failover. Plain GRS and GZRS are disqualified immediately; only the RA- variants provide that.
- A scenario asks what happens to an account’s redundancy setting after an unplanned failover. The account is automatically converted to LRS in the new primary region, and geo-redundancy has to be manually restored afterward at additional cost.
- A scenario distinguishes disaster recovery testing from an actual outage. Testing calls for a customer-managed planned failover (no expected data loss, redundancy retained); a genuine outage calls for customer-managed unplanned failover (data loss expected, redundancy lost).
- A scenario tests whether Microsoft-managed failover is a valid recovery plan for one storage account. It isn’t. It can’t be triggered per account and shouldn’t be relied on.
- A cost-minimization scenario appears alongside a resiliency requirement. The correct answer satisfies the stated requirement with the cheapest option, not the most protective one available.
Redundancy decisions rarely stand alone on the exam; they usually pair with access-tier or backup requirements in the same scenario. See the AZ-104 study guide for how storage topics connect to the rest of the exam.