Azure Storage redundancy - LRS, ZRS, GRS, GZRS and failover

Every Azure storage account keeps more than one copy of your data. The redundancy setting decides where those copies live: in one building, across several buildings in the same region, or in a second region hundreds of miles away. That choice sets what kind of failure the account survives, whether you can still write during it, and whether you can read anything at all while the primary region is down.

The six options have short, similar names, and exam questions use that. A typical question gives two requirements, such as "survive a zone failure" and "read during a regional outage", and lists four options that each meet one of them. If you can break each name into its parts, you can solve these in seconds.

Read the name in three parts

Each option answers three questions, and the letters tell you the answers:

How is data copied inside the primary region? L means locally, in one datacenter. Z means across availability zones.
Is it also copied to a second region? G means yes, to the region paired with the primary.
Can you read the secondary copy at any time? RA- means yes.

So GZRS is zone-redundant in the primary plus geo-replication, and RA-GZRS is the same with a readable secondary. Once you see it that way, there are only two decisions in the primary region and two outside it.

Redundancy inside the primary region

LRS

Locally redundant storage keeps three copies in a single datacenter in the region you pick. Microsoft quotes durability of at least eleven nines over a year. It protects against a failed disk, server or rack, but not against something that takes out the whole datacenter, such as a fire or flood. It is the cheapest option. It fits data you can recreate, dev and test, and data that rules say must stay in one region.

ZRS

Zone-redundant storage writes each change synchronously to three or more availability zones in the region, and a write is only acknowledged once it has landed in all of them that are available. Durability is at least twelve nines. The useful property is that if one zone fails, the account stays readable and writable; Azure repoints DNS, so the application should retry with backoff while that happens. ZRS keeps data in one region, so it is the usual answer when you need high availability and data residency at once. It needs a region with availability zones.

Redundancy in a second region

GRS and RA-GRS

Geo-redundant storage is LRS in the primary region plus an asynchronous copy to the paired secondary region, where the data is again stored as LRS. Azure chooses the secondary region from your primary region, and you can't change it. Durability is quoted at sixteen nines.

With plain GRS the secondary copy is invisible until a failover happens. RA-GRS gives you a second read endpoint, the account name with -secondary appended (for example myaccount-secondary.blob.core.windows.net), which works all the time. The same account keys work on both endpoints. That raises the read availability SLA for the hot tier from 99.9% to 99.99%.

GZRS and RA-GZRS

Geo-zone-redundant storage is ZRS in the primary region plus the same asynchronous copy to the paired region. It is the most resilient option: a zone failure costs you nothing, and a regional disaster still leaves a copy elsewhere. Microsoft recommends RA-GZRS for maximum availability and durability. The region needs both availability zones and a paired region.

What asynchronous means for you

Because the second region always lags a little behind, a sudden loss of the primary region can lose the most recent writes. The account's Last Sync Time tells you the point up to which everything is safely on the secondary; anything written after it may be gone if the primary never comes back. For block blobs Azure offers geo priority replication, which commits to an RPO of 15 minutes or less.

Failover

There are three kinds of storage account failover:

Customer-managed planned failover swaps the primary and secondary while both are healthy. It is meant for disaster recovery drills or getting ahead of a forecast event. No data is lost and the account keeps its geo-redundancy (a GZRS account runs as GRS while failed over and returns to GZRS when you fail back).
Customer-managed unplanned failover is what you trigger when the primary region is down. The secondary becomes the primary, the copy in the old primary is deleted, writes after the Last Sync Time are lost, and the account becomes LRS in the new region. You have to turn geo-redundancy back on yourself, and re-replicating the data is charged.
Microsoft-managed failover happens only for a whole region in a severe disaster. You can't ask for it for one account, and Microsoft says not to build a plan around it.

In all cases the endpoint names stay the same; Azure updates DNS so they point at the new primary. Applications don't need new URLs. A customer-managed failover typically takes under an hour. LRS and ZRS accounts have no secondary, so there is nothing to fail over to.

Access tiers and how they meet redundancy

Access tiers are a separate setting from redundancy, but a few questions combine them. Block blobs can sit in four tiers:

Hot for data in active use: highest storage price, cheapest reads.
Cool for data read occasionally, with a 30-day minimum before a delete or tier change is free.
Cold for data read rarely but still needed quickly, with a 90-day minimum.
Archive for data kept for years, with a 180-day minimum. It is offline: a blob must be rehydrated to an online tier before it can be read, which can take up to 15 hours.

The account's default tier can be hot, cool or cold, never archive. The catch that links the two topics: archive is only supported on LRS, GRS and RA-GRS accounts, not ZRS, GZRS or RA-GZRS. Changing the redundancy of an account that holds archived blobs means rehydrating them first, which is slow and expensive.

How to choose

If the data can be rebuilt and cost matters most, use LRS.
If the workload must keep running through a zone failure and the data must stay in one region, use ZRS.
If you need a copy that survives a regional disaster but can wait for a failover before using it, use GRS, or GZRS if you also need zone resilience in the primary.
If the application must keep reading during a primary-region outage without anyone triggering a failover, add RA-: RA-GRS or RA-GZRS.
If you need both zone resilience and readable regional redundancy, the only answer is RA-GZRS.
If blobs will go to the archive tier, rule out the zone-based options.
If it is Azure Files, note there is no RA- option for file shares; for managed disks, only LRS and ZRS exist.

Common exam traps

Assuming GRS lets you read the secondary. Only RA-GRS and RA-GZRS expose a secondary endpoint. Plain GRS needs a failover first.
Assuming geo-replication is synchronous. It isn't, so an unplanned failover can lose data written after the Last Sync Time. Only the copies inside a region are synchronous.
Expecting the account to stay geo-redundant after an unplanned failover. It becomes LRS in the new primary. Only a planned failover keeps geo-redundancy.
Confusing ZRS with GRS. ZRS protects against a zone or datacenter loss but not against losing the region; GRS protects the data against a regional disaster but not your write availability during a zone outage.
Pairing archive with ZRS or GZRS. Archive isn't supported on zone-redundant accounts.
Thinking redundancy is a backup. A deleted or overwritten blob is deleted or overwritten in every copy. Use soft delete, versioning or backups for that.

A worked example

A retailer stores product images in a general-purpose v2 account in a region with availability zones. The web tier must keep uploading images if one zone fails. If the whole region goes down, the storefront must still display existing images straight away, even if uploads stop. Old campaign images are kept for seven years and almost never opened.

Zone failure with writes still working rules out LRS and GRS, which keep the primary copy in one datacenter. Reading during a regional outage without a failover needs the RA- prefix. The only option with both is RA-GZRS, and the web tier reads from the -secondary endpoint when the primary fails.

The seven-year images tempt you toward the archive tier, but RA-GZRS doesn't support it. The clean answer is a second account for the old images on GRS or RA-GRS with a lifecycle rule that moves them to archive, or keeping them in the cold tier in the RA-GZRS account if fast access is worth the higher storage price.