LRS vs ZRS vs GRS vs GZRS: picking Azure Storage redundancy in five seconds

Azure Storage gives you six redundancy options for a storage account: LRS, ZRS, GRS, GZRS, RA-GRS and RA-GZRS. They look like alphabet soup, but every one of them is just the answer to two questions:

1. How is the data protected inside the region I chose? In one datacentre, or spread across availability zones?
2. Is it also copied to a second region, hundreds of miles away?

Then one follow-up decides the RA- prefix: does anyone need to read that second copy without waiting for a failover?

Question one: inside the primary region

LRS (locally redundant storage) keeps three copies of your data inside a single datacentre. A failed disk, server or rack is no problem. But a fire, flood or other event that takes out that building takes out all three copies with it. It’s the cheapest option and the least durable.

ZRS (zone-redundant storage) writes the copies synchronously across three availability zones: separate buildings with their own power, cooling and networking. Lose a whole zone and the account carries on, for reads and writes. Microsoft recommends ZRS in the primary region when you need high availability.

Question two: a copy in another region

GRS (geo-redundant storage) is LRS in the primary region plus an asynchronous copy to the paired region, where the data is stored with LRS again. You don’t choose the secondary: Azure decides it from the primary region you picked.

GZRS (geo-zone-redundant storage) is the best of both: ZRS in the primary region plus the same asynchronous geo copy. Lose a zone and you keep working; lose the whole region and the data is still safe in the secondary.

Because the geo copy is asynchronous, the secondary is usually a little behind the primary. If the primary region is lost for good, the most recent writes may be lost with it.

The trap: reading the secondary copy

With plain GRS or GZRS you can’t read the secondary copy. It sits there until there is a failover, and only then does the secondary become the new primary.

If an application or its users must be able to read the data at any time, including while the primary region is down and before anyone fails over, you need RA-GRS or RA-GZRS (read-access). The account then gets a second, read-only endpoint with -secondary added to the account name:

mystorage.blob.core.windows.net             primary: read and write
mystorage-secondary.blob.core.windows.net   secondary: read only

So when a requirement says “users must still be able to read the data if the primary region is unavailable, without a failover”, the answer starts with RA-.

Three more traps

• Redundancy isn’t backup. Every copy reflects the same current state, so a deleted or overwritten blob is deleted or overwritten everywhere. For mistakes and malicious changes you need soft delete, versioning or Azure Backup.
• The archive tier needs LRS, GRS or RA-GRS. It isn’t supported on ZRS, GZRS or RA-GZRS accounts, so a requirement for both archive and zone redundancy can’t be met by one account.
• Azure Files is narrower. It doesn’t support the read-access options (RA-GRS and RA-GZRS) at all, and SSD (premium) file shares support only LRS and ZRS.

Pick it in five seconds

For reference, Microsoft designs LRS for at least 11 nines of durability over a year, ZRS for 12 and GRS and GZRS for 16. Exams rarely ask for the numbers; they ask which option meets a scenario.

Go deeper

Storage accounts and their redundancy options are chapter 4 of the AZ-104 study guide; access tiers, soft delete, versioning and lifecycle rules follow in chapter 6, with the traps called out like these. For designing redundancy and disaster recovery across a whole solution, see the storage and backup chapters of the AZ-305 study guide. The facts here were checked against Microsoft Learn’s Azure Storage redundancy page on 4 October 2026.