Azure Storage Redundancy Options: LRS, ZRS, GRS, and GZRS

Azure Storage redundancy determines how many copies of your data exist, where those copies physically sit, and whether you can read from a secondary copy before or after a failure. Every storage account picks one of six options, and each answers two separate questions: does the data survive a datacenter loss, and does it survive losing an entire region? Getting the two questions untangled is the key to answering nearly every redundancy question on the AZ-900 exam.

The two failure domains redundancy protects against

Think of redundancy as stacking protection against two independent failure scales. The first is a single datacenter going down — a power outage, a fire, a cooling failure — while the rest of the region keeps running. The second is the entire region becoming unreachable, which is a much rarer, larger-scale event. Each redundancy option picks a combination of protecting against one, both, or neither of these, and that choice is what separates the six names from each other.

Locally redundant storage (LRS)

Locally redundant storage (LRS) writes three synchronous copies of every object within a single datacenter in your primary region. It’s the cheapest option because it’s doing the least work: all three copies sit behind the same power, cooling, and network infrastructure. LRS protects against a failed disk or a failed server node, but if that one datacenter goes offline, so does your data — there’s no second location to fall back to. It’s the right call for data that’s easily regenerated, non-critical, or explicitly excluded from stricter compliance requirements, where the lowest possible storage bill matters more than surviving a facility-level outage.

Zone-redundant storage (ZRS)

Zone-redundant storage (ZRS) spreads those same three synchronous copies across three separate availability zones within the primary region — physically distinct datacenters with independent power and networking, but still connected by a low-latency backbone inside the same region. That distinction matters: ZRS survives a full datacenter failure, but the data never leaves the region’s physical boundary. This makes ZRS the option to reach for whenever a scenario combines “must survive a datacenter loss” with a data-residency rule that forbids storing any copy outside the home region — GRS and its variants would fail that residency requirement even though they add more protection overall.

Geo-redundant storage (GRS) and read-access GRS (RA-GRS)

Geo-redundant storage (GRS) takes LRS’s single-datacenter primary copy and asynchronously replicates it to a second, paired region hundreds of miles away, protecting against the loss of the entire primary region. The catch is that the secondary copy is not readable under normal conditions — it only becomes accessible after Microsoft performs an account failover, which is a deliberate, disruptive event reserved for genuine regional outages.

Read-access geo-redundant storage (RA-GRS) removes that restriction. It replicates identically to GRS but adds a permanent, separate read-only endpoint against the secondary region, so applications or auditors can query that copy at any time — even while the primary region is completely healthy — with no failover required. The moment a scenario says something needs to be readable from a secondary region “at any time” or “without waiting for failover,” GRS alone is disqualified and RA-GRS becomes the answer.

Geo-zone-redundant storage (GZRS) and RA-GZRS

Geo-zone-redundant storage (GZRS) is what you get when you don’t want to trade zone protection for regional protection — it combines them. The primary region’s copies are spread across availability zones exactly like ZRS, and that zone-redundant set is then asynchronously replicated to a secondary region exactly like GRS. Read-access geo-zone-redundant storage (RA-GZRS) adds the same always-on read endpoint on the secondary copy that RA-GRS provides. RA-GZRS is the single option that survives a datacenter failure in the primary region, survives a full regional outage, and keeps the secondary copy continuously readable — whenever a scenario stacks all three of those requirements at once, RA-GZRS is the only correct choice.

Comparing the six options

Option	Primary region copies	Secondary region?	Secondary readable without failover?
LRS	Single datacenter	No	—
ZRS	Across availability zones	No	—
GRS	Single datacenter	Yes	No
RA-GRS	Single datacenter	Yes	Yes
GZRS	Across availability zones	Yes	No
RA-GZRS	Across availability zones	Yes	Yes

What redundancy does not protect against

Redundancy replicates changes, including bad ones. If someone accidentally deletes a container or overwrites a blob, every synchronous or asynchronous copy inherits that mistake just as fast as a legitimate write — upgrading from GZRS to RA-GZRS does nothing to undo an accidental delete, because redundancy only defends against infrastructure failure, not human or application error. Guarding against accidental deletion or overwrite requires separate features layered on top, such as soft delete for blobs and containers and blob versioning, which retain prior states you can restore regardless of which redundancy tier the account uses.

How the AZ-900 exam tests this

• A scenario states two constraints at once — resiliency and residency. “Must survive a datacenter failure” plus “data may never leave the region” always points to ZRS, since anything with a G in the name replicates outside the region.
• A scenario asks for reads from the secondary region “at any time” or “without a failover.” That phrasing eliminates plain GRS and GZRS immediately — you need the RA- prefix.
• A multi-part scenario stacks datacenter loss, regional loss, and continuous secondary reads together. This is the exam’s way of testing whether you know RA-GZRS is the only option satisfying all three simultaneously, rather than settling for an option that covers two out of three.
• A cost-minimization scenario appears alongside a redundancy question. The exam expects you to recognize that LRS is cheapest, each added layer of protection (zones, then geo-replication, then read access) adds cost, and you should pick the least protection that still satisfies the stated requirements — not the most protection available.

Redundancy choices pair naturally with access tiers when the exam wants you to minimize both durability risk and cost in the same scenario, so it helps to be equally comfortable with Hot, Cool, Cold, and Archive access tiers alongside these six redundancy levels. Redundancy only matters once data has actually landed in the account — whether it arrived through a scripted transfer or one of the other Azure data migration tools — after which the redundancy setting governs how durably it’s kept. And because each added layer of protection raises the bill, the cost-minimization guidance above pairs directly with the broader Azure cost factors the exam expects you to weigh. Once you can name the failure domain each option addresses without hesitating, practice this with real AZ-900 questions that combine redundancy with residency, cost, and access-tier constraints in a single stem.

Quick reference

• LRS: three copies, one datacenter, cheapest, no facility-level protection.
• ZRS: three copies across availability zones in the primary region only — survives a datacenter loss, stays within the region.
• GRS: LRS primary plus async replication to a second region; secondary unreadable until failover.
• RA-GRS: GRS plus a permanent read-only endpoint on the secondary, readable any time.
• GZRS: ZRS primary plus async replication to a second region; secondary unreadable until failover.
• RA-GZRS: GZRS plus a permanent read-only endpoint — survives datacenter loss, regional loss, and stays continuously readable.
• Any option with “geo” in the name replicates outside the primary region; only LRS and ZRS keep every copy within it.
• Redundancy protects against infrastructure failure only — soft delete and versioning protect against accidental deletion or overwrite.