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.
Compare all six Azure Storage redundancy options
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.
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.
Regional failover changes the primary and may lose recent writes
Microsoft can perform a service-managed failover during a severe regional outage. Eligible geo-redundant accounts may also support customer-managed failover. Because geo-replication is asynchronous, data written after Last Sync Time might not exist in the secondary when failover occurs.
Local copies commit synchronously.
The secondary can lag behind.
Account endpoints resolve to the new primary.
After customer-managed unplanned failover, the new primary is typically configured with LRS and geo-redundancy must be re-established when appropriate. Review supported account types and feature interactions before relying on failover in a design.
A real account failover changes the account’s regional role and can cause data loss. Use documented disaster-recovery exercises, separate test accounts and application-level validation.
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.
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.
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.