Read-access geo-zone-redundant storage, usually called RA-GZRS, is one of the strongest Azure Storage redundancy choices. It keeps data redundant across availability zones in the primary region and also replicates data to another region where it can be read through a secondary endpoint. The primary region remains the write location, while the secondary copy is read-only unless failover occurs. RA-GZRS is for workloads that care about both zone resilience and regional read continuity. It costs more, so it needs a real recovery or availability requirement.
RA-GZRS, Standard_RAGZRS, read-access GZRS, read-access geo-zone redundant storage, zone and geo read access
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-21
Microsoft Learn
Read-access geo-zone-redundant storage, or RA-GZRS, combines zone redundancy in the primary region, geo-replication to a secondary region, and a secondary read endpoint. It protects against zonal failures while preserving read access to replicated data when the primary region or application path is impaired.
In Azure architecture, RA-GZRS is a storage account redundancy SKU, commonly Standard_RAGZRS for supported account types and regions. It combines synchronous zone replication in the primary region with asynchronous geo-replication to a secondary region and exposes secondary endpoints for read access. This makes it relevant to Blob Storage, Data Lake Storage, queues, tables, and selected account types, with service-specific limitations. Architects must design network access, private endpoints, DNS, authorization, lifecycle rules, monitoring, and client routing so both zone and regional-read objectives are actually usable.
Why it matters
RA-GZRS matters because some data needs protection from both datacenter-zone failures and broader regional disruption. A workload may survive a zonal issue in the primary region without changing endpoints, then still have a readable secondary copy if regional access becomes impaired. That combination is valuable for critical configuration, regulatory evidence, customer downloads, disaster-response content, and operational archives. The tradeoff is higher cost and a more complex runbook. Teams must understand replication lag, secondary endpoint routing, service compatibility, and failover consequences before claiming RA-GZRS as a complete availability strategy The value appears only when recovery procedures match the chosen redundancy tier closely.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
Storage account redundancy settings show Standard_RAGZRS, primary location, secondary location, endpoint details, and geo-replication status during resilience design or audit reviews and readiness drills.
Signal 02
Azure CLI and Resource Graph inventory expose account SKU, kind, locations, tags, secondary endpoints, last sync metadata, and network posture used for fleet-level continuity checks.
Signal 03
Recovery runbooks, application settings, or incident workbooks reference secondary blob, queue, table, or Data Lake endpoints when teams test regional read continuity under approval gates.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Protect critical storage data from primary-region zone failures while retaining a readable copy in a paired secondary region.
Support high-priority static content, configuration, or operational files that must remain readable during regional disruption.
Meet architecture standards that require both zone redundancy and tested secondary-read continuity for tier-one workloads.
Reduce recovery pressure by letting operators read replicated data before deciding whether full storage account failover is necessary.
Compare premium continuity needs against cheaper redundancy options during workload tiering and FinOps governance reviews.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Payment processor protects reconciliation files
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
ClearLedger Payments stored reconciliation exports used by banks and merchants every morning. The business required zone resilience and a regional read path without allowing emergency writes.
🎯Business/Technical Objectives
Keep reconciliation exports readable during zone or regional disruption.
Avoid full account failover unless the incident truly required it.
Validate replicated data age before banks consumed secondary files.
Limit RA-GZRS usage to high-value settlement containers.
✅Solution Using Read-access geo-zone-redundant storage
The storage team placed settlement exports in a Standard_RAGZRS storage account and left low-value diagnostic logs in cheaper accounts. The settlement application wrote only to the primary endpoint. A recovery script checked statusOfSecondary, lastSyncTime, container availability, and private endpoint health before publishing secondary-read URLs through a controlled portal banner. SAS tokens were read-only and short-lived. Azure Monitor workbooks tracked replication status, transaction latency, and secondary-read counts, while cost tags separated settlement continuity spend from general storage growth A quarterly evidence review checked that no settlement-adjacent test containers inherited the costly SKU.
📈Results & Business Impact
Morning reconciliation remained readable in two zone-failure simulations.
Secondary-read activation took under eight minutes after approval.
RA-GZRS was limited to 22 percent of storage capacity, controlling cost.
Bank support tickets during resilience testing dropped by 36 percent.
💡Key Takeaway for Glossary Readers
RA-GZRS gives critical storage workloads a stronger continuity posture when secondary reads are controlled and tested.
Case study 02
Emergency agency keeps map packages available
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A state emergency agency hosted wildfire map packages and evacuation-zone files in Azure Storage. Regional stress events were exactly when responders needed the files most.
🎯Business/Technical Objectives
Preserve read access to current map packages during infrastructure disruption.
Protect against primary-region zone failure without changing normal workflows.
Show responders when map data might be slightly behind.
Keep public download paths separate from internal update paths.
✅Solution Using Read-access geo-zone-redundant storage
The agency configured the map package account with RA-GZRS and routed updates through the primary endpoint from a secured operations subnet. Public download services normally used cached primary content through Front Door, while an incident workflow could switch downloads to the secondary endpoint after operators checked lastSyncTime. Internal editors did not receive secondary write access. Diagnostic logs, Defender alerts, and storage metrics fed a situational workbook that showed primary availability, secondary status, replication age, and download volume by region The same drill confirmed that editors could not accidentally publish updates through the recovery path.
📈Results & Business Impact
Responders kept map downloads available during a simulated regional access failure.
The workbook displayed replication age within five minutes of each update cycle.
Public reads were separated from internal write paths with no emergency privilege expansion.
The agency passed its annual continuity exercise without adding a custom replication tool.
💡Key Takeaway for Glossary Readers
RA-GZRS can support public-safety continuity when freshness, routing, and write authority are separated clearly.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A robotics manufacturer stored machine telemetry archives used for warranty disputes and safety analysis. Investigators needed read continuity, but production devices could tolerate delayed archive access.
🎯Business/Technical Objectives
Protect high-value telemetry archives across zones and regions.
Keep ingest workloads writing only to the primary storage endpoint.
Provide investigators with a secondary-read recovery option.
Avoid applying premium redundancy to short-lived raw debug files.
✅Solution Using Read-access geo-zone-redundant storage
The data platform team separated telemetry into critical warranty archives, raw debug uploads, and temporary staging blobs. Warranty archives used RA-GZRS, while staging data used lower-cost redundancy and lifecycle expiration. A Function tagged each archived blob with equipment model, plant, and retention class. Investigators accessed data through an internal portal that could switch to the secondary endpoint only after an operator confirmed status and last sync time. Azure Policy denied creation of RA-GZRS accounts without required criticality and owner tags Monthly reviews compared archive value, read continuity need, and actual secondary-read drill results.
📈Results & Business Impact
Warranty archive availability objectives were met in quarterly recovery drills.
Temporary debug storage costs fell 27 percent after tiering and lifecycle cleanup.
Investigators retrieved replicated evidence within 15 minutes during a regional-read exercise.
Policy controls blocked three untagged high-cost storage account deployments.
💡Key Takeaway for Glossary Readers
RA-GZRS is a resilience tool for selected critical data, not a substitute for storage classification and governance.
Why use Azure CLI for this?
As an Azure engineer with ten years of storage resilience work, I use Azure CLI for RA-GZRS because the difference between GZRS, RA-GZRS, RA-GRS, and ZRS matters during incidents. CLI lets me prove the exact SKU, endpoints, locations, status, and last sync time across a fleet in minutes. It also helps verify private endpoint and firewall configuration before a recovery drill. Portal screens are useful for one account, but architecture reviews, audit evidence, and incident bridges need scriptable output that can be compared, exported, and repeated without relying on screenshots That evidence keeps resilience claims honest across platform reviews and audits.
CLI use cases
Inventory all storage accounts using Standard_RAGZRS and compare them with criticality tags or architecture standards.
Inspect secondary endpoints, geo-replication status, and last sync time before activating a secondary-read plan.
Create a new storage account with RA-GZRS only in supported regions and account configurations.
Update redundancy after confirming service compatibility, cost impact, migration constraints, and rollback expectations.
Validate network rules, private endpoint connections, and diagnostic settings for accounts claiming tier-one continuity.
Before you run CLI
Confirm tenant, subscription, resource group, storage account name, region, account kind, and whether RA-GZRS is supported for the intended service and location.
Review cost approval, workload criticality, recovery objectives, and data-classification requirements before changing redundancy.
Use read-only inventory commands before mutating the SKU because redundancy changes can affect billing, compatibility, and recovery assumptions.
Validate private endpoint DNS, firewall rules, and identity access for secondary-read tests, not just the primary endpoint.
Capture JSON output for statusOfSecondary, lastSyncTime, endpoints, SKU, and location fields during resilience exercises.
What output tells you
sku.name confirms whether the account is really Standard_RAGZRS rather than GZRS, RA-GRS, ZRS, or LRS.
Primary and secondary endpoint fields show exactly which URLs clients or runbooks would use for normal and secondary reads.
location and secondary region metadata reveal whether the account aligns with the expected paired-region continuity plan.
statusOfSecondary and lastSyncTime indicate whether secondary reads are available and how fresh replicated data may be.
Network rule and private endpoint output exposes whether the resilience path is reachable from approved application environments.
Mapped Azure CLI commands
Storage Account operations
direct
az storage account list --resource-group <resource-group>
az storage accountdiscoverStorage
az storage account show --name <storage-account> --resource-group <resource-group>
az storage account update --name <storage-account> --resource-group <resource-group> --set allowBlobPublicAccess=false
az storage accountconfigureStorage
az storage account delete --name <storage-account> --resource-group <resource-group>
az storage accountremoveStorage
Architecture context
A seasoned Azure architect chooses RA-GZRS when the workload has a tier-one storage continuity requirement and the application can use read-only secondary access. The design should separate normal primary writes, primary-zone resilience, secondary reads, and full account failover into distinct scenarios. Private networking must be tested for primary and secondary endpoints, especially when services run in locked-down VNets. Monitoring should include availability, last sync time, transaction metrics, and unusual secondary reads. RA-GZRS also affects CDN, Front Door, backup, lifecycle, and data-governance decisions because the data exists across zones and a paired region Ownership for each scenario should be documented in the workload recovery plan.
Security
Security impact is direct because RA-GZRS creates highly available copies of the same sensitive data across zones and a secondary region. Encryption protects data at rest, but access controls still determine who can read it. Review account keys, SAS policies, managed identities, RBAC assignments, firewall rules, private endpoints, and diagnostic settings. The secondary endpoint must not be treated as an emergency shortcut exempt from normal access review. If customer-managed keys are used, confirm the key design supports account operations and continuity expectations. Audit secondary-read traffic because unexpected access can indicate a misrouted client, exposed token, or incident workaround Review cross-region data residency requirements before enabling the SKU for regulated datasets.
Cost
RA-GZRS has a direct and meaningful cost impact because it combines zone redundancy, geo-replication, and read-access capability. It should be reserved for data that needs both primary-region zone resilience and secondary-region read continuity. Storage capacity, transactions, secondary reads, monitoring, lifecycle retention, and data transfer all influence the bill. Cost reviews should compare RA-GZRS with ZRS, GZRS, RA-GRS, backups, object replication, CDN caching, or application-level replication. The biggest waste pattern is using RA-GZRS for low-value logs or test data simply because it sounds safest. Tag criticality and review redundancy quarterly Tie the SKU to a named service tier and recovery objective before approval.
Reliability
Reliability is the main reason to choose RA-GZRS. Zone redundancy helps absorb a primary-region availability zone failure, while geo-replication with read access gives operators a secondary path for data reads during broader trouble. Reliability still depends on application routing, private DNS, endpoint testing, and clear decisions about stale data. Replication to the secondary region is asynchronous, so last sync time must guide incident choices. Teams should rehearse zone failure assumptions, secondary-read activation, and account failover separately. Without those rehearsals, RA-GZRS becomes an expensive setting rather than a proven resilience capability Recovery tests should record the difference between zone resilience and regional read access.
Performance
Performance impact depends on which path is used. Normal reads and writes use the primary endpoint, benefiting from primary-region zone resilience. Secondary reads may help consumers near the paired region or during primary trouble, but they are read-only and may lag behind the primary. Large objects, private networking, DNS, client retry policy, and service throttles affect perceived speed. RA-GZRS does not automatically speed up the application; it gives more read paths and resilience options. Operators should measure primary latency, secondary read latency, last sync time, error rates, and routing behavior during drills and peak demand Synthetic tests should use realistic object sizes and authenticated clients.
Operations
Operators manage RA-GZRS by checking the storage account SKU, supported services, primary and secondary endpoints, geo-replication statistics, zone and region placement, network rules, and access logs. Common tasks include confirming Standard_RAGZRS during inventory, validating secondary-read tests, reviewing last sync time, documenting recovery procedures, and detecting accounts whose redundancy does not match workload criticality. Runbooks should include service caveats, expected client routing, and conditions for failover. Operators also need to explain freshness limits to business owners, because the secondary endpoint can be available while the newest writes have not replicated yet They should also track exceptions where service limitations change the promised recovery behavior.
Common mistakes
Choosing RA-GZRS because it sounds safest without confirming the workload needs both zone and regional read continuity.
Assuming the secondary endpoint is current enough for writes, approvals, or financial decisions despite asynchronous replication.
Failing to test secondary-read access through private DNS and firewall rules before a real outage.
Using RA-GZRS for low-value logs or short-lived test data and creating unnecessary storage spend.
Ignoring service-specific limitations, especially when different storage services behave differently under redundancy options.