LRS vs ZRS vs GRS vs GZRS: the short answer
LRS
Choose the lowest-cost option when three synchronous copies in one primary-region datacenter meet the failure boundary.
ZRS
Choose primary-region availability-zone resilience without a geo-replicated secondary region.
GRS
Choose asynchronous geo-replication when an LRS primary is sufficient and zonal primary protection is not required.
GZRS
Choose both primary-region zonal resilience and an asynchronously replicated secondary region.
Add the RA prefix—RA-GRS or RA-GZRS—only when the application must read the secondary endpoint before failover. Geo-replication is asynchronous, so it does not promise zero data loss during an unplanned regional failover.
Start with the failure the workload must survive
Three synchronous copies in one physical location in the primary region.
Three synchronous copies across separate zones in the primary region.
Asynchronous copies in a paired secondary region, with different primary-region protection.
First choose the required boundary: local hardware, an availability zone, or an entire region. Then decide whether applications need read access to the secondary before failover.
Azure Storage redundancy comparison table
All writes go to the primary endpoint. Primary-region replication is synchronous. Geo-replication to the secondary is asynchronous, so regional protection introduces a non-zero recovery point during an unplanned failover. Microsoft publishes durability targets separately from availability SLAs; do not treat the durability percentages as uptime guarantees.
RA-GRS and RA-GZRS expose a read-only secondary endpoint
Standard GRS and GZRS maintain secondary copies but do not expose them for normal application reads. Read-access variants add a secondary endpoint whose hostname includes a -secondary suffix. Applications can use it for read-only access, reporting or availability patterns when they are designed for potentially stale data.
Primary blob endpoint:
https://examplestore.blob.core.windows.net
Read-only secondary endpoint with RA-GRS or RA-GZRS:
https://examplestore-secondary.blob.core.windows.netSecondary reads do not guarantee that the latest primary write has arrived. Use the storage account’s Last Sync Time and application semantics to decide whether secondary data is acceptable.
Planned vs unplanned Azure Storage failover
Microsoft documents three failover paths: customer-managed planned failover, customer-managed unplanned failover and Microsoft-managed failover. They do not have the same data-loss or post-failover behavior.
Both regional endpoints are available. Azure synchronizes before switching, retains geo-redundancy and is designed for disaster-recovery testing without expected data loss.
The primary is unavailable. Asynchronous lag can cause data loss, the secondary becomes primary and the account becomes LRS until geo-redundancy is re-enabled.
Microsoft may fail over an entire affected region in an extreme disaster. It is not an individual-account test mechanism.
For an unplanned failover, data written after Last Sync Time might not exist in the secondary. Confirm current account-type, feature and regional support before treating any failover option as part of a production runbook.
A documented planned failover can test supported disaster-recovery procedures. Do not use an unplanned failover as a routine connectivity test because it can lose recent writes and changes the account’s redundancy state.
Redundancy keeps copies—but it can also copy a mistake
If an authorized user deletes a blob or an application overwrites it with bad data, replication can reproduce that operation across copies. Redundancy protects infrastructure availability; it is not automatically a historical backup.
Infrastructure failure
Choose LRS, ZRS or geo-redundancy based on the required hardware, zone and region boundary.
Accidental deletion
Evaluate blob soft delete, container soft delete, file-share soft delete or other service-specific recovery controls.
Unwanted overwrite
Evaluate blob versioning, snapshots, point-in-time restore or backups where supported and appropriate.
Recovery design also needs monitoring, access control, resource locks where appropriate, tested runbooks and business-aligned recovery objectives.
Worked scenario: zone failure plus regional recovery requirement
Situation: A customer portal stores documents in Azure Blob Storage. It must continue through an availability-zone outage in the primary region, retain a copy in a secondary region, and allow reports to read that secondary before any failover.
Zonal primary resilience
LRS and GRS do not distribute the primary copies across availability zones. Start with ZRS behavior.
Secondary region
ZRS alone has no geo-replicated secondary. Add geo-redundancy: GZRS.
Pre-failover reads
Standard GZRS does not expose secondary reads. The complete choice is RA-GZRS.
It combines synchronous zone redundancy in the primary, asynchronous LRS replication to the secondary region and read access to the secondary endpoint. The application must tolerate secondary lag.
Secondary endpoint returns old data: troubleshoot the design, not only DNS
- Confirm the SKU: verify the account is RA-GRS or RA-GZRS; standard GRS/GZRS does not provide routine secondary reads.
- Confirm the endpoint: ensure the client is intentionally using the correct
-secondaryservice endpoint. - Check Last Sync Time: determine the latest time for which writes are known to have reached the secondary.
- Review application expectations: a successful secondary read can still be stale because replication is asynchronous.
- Check service and account support: redundancy conversions, failover and data services have compatibility constraints.
Geo-redundant does not mean active-active writable storage. The primary handles writes; the secondary is asynchronously maintained and is read-only before failover only with an RA option.
Practice checks with explanations
A storage account must survive a zone outage, but no secondary region is required. What fits?
Best answer: ZRS. It synchronously distributes three copies across availability zones in the primary region.
The company needs regional replication but the lowest geo-redundant option; zonal primary resilience is not required. What fits?
Best answer: GRS. It uses LRS in the primary and asynchronously replicates to an LRS secondary region.
A dashboard must read the secondary region before failover. Is GZRS enough?
Best answer: no. Select RA-GZRS to expose the read-only secondary endpoint while retaining ZRS in the primary.
Turn this comparison into an AZ-104 study decision
If storage redundancy is one of several weak areas, use the full AZ-104 training path and timed practice before changing a real account or booking an exam. For a focused recommendation, share only your Azure experience, target date and difficult domains.
Common AZ-104 storage mistakes
- Assuming LRS protects against an availability-zone outage.
- Assuming ZRS automatically adds a secondary region.
- Confusing GRS primary protection with GZRS primary protection.
- Expecting secondary reads from standard GRS or GZRS.
- Treating asynchronous geo-replication as zero data-loss protection.
- Using redundancy as a replacement for delete, version and backup controls.
- Forgetting to reassess redundancy after a customer-managed failover.
Frequently asked questions
What is the difference between LRS and ZRS in Azure Storage?
LRS synchronously keeps three copies in one physical location in the primary region. ZRS synchronously keeps three copies across separate availability zones in the primary region, adding resilience to a zonal failure.
What is the difference between GRS and GZRS?
Both asynchronously replicate data to a secondary region. GRS uses LRS in the primary region, while GZRS uses ZRS in the primary region. The secondary region uses LRS for both options.
Can applications read the secondary region with standard GRS or GZRS?
Not normally. Choose RA-GRS or RA-GZRS when read access to the secondary endpoint is required before a failover.
Can geo-redundant storage lose recent writes during a regional failover?
Yes. Replication to the secondary region is asynchronous, so an unplanned failover can lose writes that had not reached the secondary. Last Sync Time helps estimate the recovery point.
Does Azure Storage redundancy replace application backups?
No. Replication can reproduce accidental deletion or corruption. Use soft delete, versioning, point-in-time restore or backup controls as appropriate to the workload in addition to infrastructure redundancy.
Which Azure Storage redundancy option should I choose?
Choose LRS for the lowest-cost local hardware protection, ZRS for primary-region zone resilience, GRS for geo-replication with an LRS primary, or GZRS for both primary-zone resilience and geo-replication. Add the RA prefix only when the application must read the secondary before failover.
Official Microsoft references
Review Microsoft Learn for Azure Storage redundancy, disaster-recovery guidance, storage-account failover, and the official AZ-104 study guide. Availability and supported operations can vary by region, account type and service.