Academmia

Azure Storage redundancy options: LRS, ZRS, GRS, GZRS, and read-access variants

az-900•mixed•

Azure architecture and services

Azure Storage redundancy options: LRS, ZRS, GRS, GZRS, and read-access variants

Short Summary

In this lesson, I explain what “redundancy” means in Azure Storage and why it matters for durability and availability. I compare the main redundancy models (within one datacenter, across availability zones, and across regions) and when each one is a good fit. I also clarify the difference between redundancy and backup, and what “read-access” means for geo-redundant options.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define redundancy in Azure Storage and describe what it protects against.
  • Differentiate Locally Redundant Storage (LRS) and Zone-Redundant Storage (ZRS) by where copies are stored.
  • Compare Geo-Redundant Storage (GRS) and Geo-Zone-Redundant Storage (GZRS) for regional disaster coverage.
  • Interpret what read-access geo-redundancy (RA-GRS / RA-GZRS) adds, and what it does not.
  • Select a redundancy option based on the failure scope you care about (hardware, zone, or region).

Core Concepts

What “redundancy” means

Redundancy in Azure Storage means Azure keeps multiple copies of my data so a failure doesn’t automatically turn into data loss. The key decision is where those copies live:

  • inside one datacenter,
  • across multiple datacenters within the same region (availability zones),
  • or in a second region.

An Azure region is a geographic area that contains one or more datacenters. Some regions support availability zones, which are separate physical locations within the same region designed to reduce the impact of a single datacenter outage.

The main redundancy models

Here are the core redundancy models I need to recognize:

  • Locally Redundant Storage (LRS) Copies are kept within a single datacenter in the primary region. It’s usually the lowest-cost option and is meant to protect against local hardware failures, not a full datacenter disaster.

  • Zone-Redundant Storage (ZRS) Copies are kept across multiple availability zones within the primary region. This is the “stay up if one zone goes down” option (as long as the service and region support zones).

  • Geo-Redundant Storage (GRS) Data is replicated to a secondary region for disaster recovery. Geo-replication is typically asynchronous, so the secondary copy can lag behind the primary. With plain GRS, the secondary copy isn’t used for reads or writes unless there’s a failover.

  • Geo-Zone-Redundant Storage (GZRS) This combines ZRS in the primary region (zone protection) with asynchronous replication to a secondary region (regional protection). It’s basically “zone + region” coverage.

Read-access variants and consistency expectations

The “read-access” variants are:

  • Read-Access Geo-Redundant Storage (RA-GRS)
  • Read-Access Geo-Zone-Redundant Storage (RA-GZRS)

They add a read-only endpoint for the secondary region, so I can read from the secondary copy without triggering a failover (for supported Azure Storage services). Because geo-replication is asynchronous, I treat the secondary reads as eventually consistent with the primary.

Redundancy is not backup

A rule I keep in my head: redundancy helps me survive infrastructure failures; it doesn’t protect me from my own mistakes.

If I delete a blob or overwrite a file, redundancy can replicate that change to all copies. For recovery from deletion/corruption, I need backup strategies or data protection features designed for restore and history.

Practical Understanding

Practical Situation 1: “Lowest cost, basic protection for dev/test data”

I store non-critical development data and I mainly want protection from drive/server failures at the lowest cost. I’m not trying to survive a datacenter, zone, or regional outage.

How to think about it: This is a “local hardware failure” requirement. Locally Redundant Storage (LRS) matches that scope.

Common misunderstanding: “Redundancy always means another region.” It doesn’t—LRS stays inside one datacenter in one region.

Practical Situation 2: “My app must survive a zone outage inside the region”

I run a workload in a region that supports availability zones and I want the data to remain available even if one zone goes down.

How to think about it: This is zonal resilience, not regional disaster recovery. Zone-Redundant Storage (ZRS) is designed for this.

Common misunderstanding: Confusing Zone-Redundant Storage (ZRS) with Geo-Redundant Storage (GRS). ZRS is one region; geo options involve a second region.

Practical Situation 3: “I must survive a full regional outage”

I store production data and I need it protected even if the entire primary region is unavailable. A second region must have a copy.

How to think about it: This is a regional disaster requirement. I look for geo options: Geo-Redundant Storage (GRS) or Geo-Zone-Redundant Storage (GZRS). If I also want zone resilience in the primary region, I lean toward GZRS.

Common misunderstanding: Assuming Zone-Redundant Storage (ZRS) covers a regional outage. ZRS helps with a zone outage; a full region outage needs geo-replication.

Practical Situation 4: “I want to read from the secondary region without failover”

I want the ability to read from the secondary-region copy during an incident, knowing it may be slightly behind the primary.

How to think about it: I choose a read-access geo option (RA-GRS or RA-GZRS) so a read-only secondary endpoint is available (where supported), and I design with eventual consistency in mind.

Common misunderstanding: Thinking “read-access” means I can write to the secondary region. Read-access is read-only; writes still go to the primary region.

Common Pitfalls

  • Mistake: Assuming redundancy is the same as backup. Correction: Redundancy improves durability/availability for infrastructure failures; backups are for restore after deletion/corruption.

  • Mistake: Thinking all redundancy options protect against regional outages. Correction: Only geo options (GRS/GZRS and their read-access variants) replicate to a secondary region.

  • Mistake: Mixing up “zone” and “geo.” Correction: ZRS spreads copies across availability zones in one region; GRS/GZRS replicate to another region.

  • Mistake: Assuming read-access geo options allow writes to the secondary region. Correction: RA-GRS/RA-GZRS provide a read-only secondary endpoint; writes stay in the primary region.

  • Mistake: Picking the highest redundancy “just in case,” without matching the requirement. Correction: Start from the failure scope you need (hardware vs. zone vs. region), then weigh cost and service support.

Check Your Understanding

  1. Describe a workload where LRS is enough, and explain what kind of outage it does not cover.
  2. Explain the difference between a zone outage and a regional outage in your own words. Which redundancy options map to each?
  3. If I say “I need a second region copy,” which redundancy names should immediately come to mind, and why?
  4. What does “read-access” add to a geo-redundant option, and what limitation still remains?
  5. Write a short checklist you would use to pick between ZRS and GRS/GZRS for a new storage account.

Further Reading