Storage Storage accounts

RA-GRS redundancy

RA-GRS, or read-access geo-redundant storage, replicates storage account data to a secondary region and allows read access to that secondary copy. It combines geo-redundant replication with a secondary endpoint applications can use when the primary region is unavailable or degraded.

Source: Microsoft Learn - Data redundancy - Azure Storage Reviewed 2026-05-21

Exam trap: Assuming RA-GRS automatically redirects application reads to the secondary endpoint during primary-region issues.
Production check: Does the storage account SKU actually show RA-GRS, not only GRS or LRS?

Practice this topic Microsoft Learn

Article details and learning context

Aliases: read-access geo-redundant storage, read-access GRS, RA GRS
Difficulty: intermediate
CLI mappings: 5
Last verified: 2026-05-21

Related context No curated learning path mapped yet; use the category trail.

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

RA-GRS redundancy is a storage account replication option that keeps another readable copy of your data in a paired secondary region. Normal writes go to the primary region, and Azure asynchronously replicates the data to the secondary. The important difference from regular GRS is read access: applications can be designed to read from the secondary endpoint during a primary-region problem. It is useful for business continuity, but the secondary copy may lag behind because replication is asynchronous.

Why it matters

RA-GRS redundancy matters because storage is often the dependency every application assumes will be there. With read access to the secondary region, teams can design degraded-mode experiences, reporting access, or evidence retrieval even when the primary region has problems. It also forces honest conversations about replication lag, stale reads, failover decisions, and cost. RA-GRS is not a replacement for backups, application-level consistency, or multi-region writes. It is a resilience tool that helps protect read availability for blobs, files, queues, or tables when designed and tested properly. The value appears only when applications, operators, and stakeholders understand the secondary read path.

Technical context

In Azure architecture, RA-GRS is configured at the storage account redundancy layer for supported account types and services. It uses locally redundant copies in the primary region, asynchronously replicates to the secondary region, and exposes secondary endpoints for reads. Applications must explicitly use those secondary endpoints; failover and read redirection are not automatic magic. Last Sync Time, account failover rules, private endpoint design, DNS, network restrictions, and service compatibility all matter when RA-GRS is part of a resilience plan.

Exam context

Compare with

GRS redundancy GZRS redundancy RA-GZRS redundancy Locally redundant storage

Where it is used

Where you see it

Storage account redundancy settings show RA-GRS or read-access geo-redundant storage as the selected replication option during resilience design and disaster recovery audits for production workloads.
Storage account properties expose primary and secondary endpoints, including secondary blob, queue, table, or file endpoints where supported by the account during failover rehearsal planning.
Geo-replication and disaster recovery views show Last Sync Time, failover readiness, secondary status, and replication health during continuity testing and incident readiness reviews for auditors.

Common situations

Design read-only degraded mode so users can retrieve critical blobs during a primary-region outage.
Test secondary endpoint reads before a disaster recovery exercise instead of assuming replication is usable.
Meet resilience requirements for audit archives, evidence stores, or operational reports that tolerate stale reads.
Monitor Last Sync Time so incident teams know which writes are available in the secondary region.
Compare RA-GRS against GZRS or RA-GZRS when balancing regional resilience, zone resilience, and cost.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Museum archive keeps collection records readable during outages Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Heritage North maintained digital collection records and exhibit media in Azure Storage. Curators needed read access to catalog evidence even if the primary storage region had a service disruption.

Goals

Keep critical archive metadata readable during regional incidents.
Avoid promising instant consistency for recently updated records.
Test secondary endpoint access without changing production writes.
Document data residency and replication behavior for governance.

Approach using RA-GRS redundancy

The archive team selected RA-GRS for the storage account that held catalog metadata and exhibit media references. Applications kept normal writes in the primary region but added a degraded read mode that could query the secondary endpoint for catalog browsing. Operators monitored Last Sync Time and displayed a warning when secondary data might be stale. Azure CLI runbooks captured the SKU, endpoints, network rules, and replication properties before each DR test. Access reviews confirmed that RBAC assignments and private endpoint rules protected both primary and secondary read paths.

Potential outcomes

Curators completed a DR read test without modifying production write paths.
Governance documentation clearly described asynchronous replication and staleness risk.
Secondary endpoint access issues were fixed before the annual continuity audit.
Archive search remained available in degraded mode during a planned primary-region test.

What to learn

RA-GRS is useful when organizations need regional read continuity and can communicate that replicated data may be slightly behind.

Scenario 02 Fintech risk platform protects read-only audit exports Scenario, objectives, solution, measured impact, and takeaway.

Scenario

LedgerWise produced daily risk exports for auditors and regulators. The exports were read-heavy, and the business wanted access during regional storage disruption without building a full active-active write model.

Goals

Provide read access to recent risk exports during primary-region issues.
Track replication lag before using secondary data for reporting.
Protect secondary reads with the same network and identity controls.
Avoid unnecessary multi-region application complexity.

Approach using RA-GRS redundancy

Architects placed approved risk exports in a storage account configured with RA-GRS. The application wrote exports to the primary endpoint and published metadata that included export time and replication status. A controlled read-only path could switch audit retrieval to the secondary endpoint when incident leadership approved degraded mode. Network engineers validated private endpoint and firewall behavior for secondary access, and security reviewed RBAC assignments. CLI evidence captured account SKU, endpoints, and Last Sync Time during quarterly continuity tests, while dashboards showed whether secondary data was appropriate for use.

Potential outcomes

Quarterly continuity tests retrieved audit exports from secondary storage successfully.
Replication-lag checks prevented use of stale exports during two rehearsals.
The team avoided a costly active-active write design for read-only evidence.
Security sign-off included both endpoint paths instead of only primary storage.

What to learn

RA-GRS can satisfy read-continuity needs for evidence and reporting workloads when stale-read controls are explicit.

Scenario 03 Logistics portal serves shipment documents in degraded mode Scenario, objectives, solution, measured impact, and takeaway.

Scenario

HarborRoute Logistics stored shipment manifests and customs documents in Azure Storage. Customers needed access to existing documents during primary-region incidents, even if new uploads paused.

Goals

Keep existing shipment documents readable during storage-region disruption.
Communicate clearly when new uploads are paused or delayed.
Verify secondary endpoint access through private networking.
Define failover authority before an actual incident.

Approach using RA-GRS redundancy

The storage account for manifests was moved to RA-GRS, and the portal added a read-only degraded mode that used secondary blob endpoints for existing documents. Writes still targeted the primary region and were paused during declared storage incidents to avoid consistency confusion. Operators monitored Last Sync Time and tested secondary reads through a separate private endpoint path. Azure CLI scripts listed RA-GRS accounts, exported endpoint configuration, and captured failover readiness evidence. The incident runbook required approval from operations, legal, and customer support before any account failover action. Customer support rehearsed the messaging so users understood why new uploads were temporarily unavailable.

Potential outcomes

Customers could retrieve existing manifests during the first degraded-mode exercise.
Support scripts explained stale-data risk and paused uploads in plain language.
Secondary private endpoint misconfiguration was found and corrected before launch.
Failover decisions became governed actions instead of ad hoc engineer choices.

What to learn

RA-GRS works best when applications have an intentional secondary-read mode and operators rehearse the network path.

Azure CLI

As an Azure engineer with ten years of storage resilience work, I use Azure CLI for RA-GRS because disaster recovery checks must be repeatable and timestamped. CLI shows the account SKU, endpoints, location, secondary region properties, network settings, and failover options without relying on portal memory. It also helps inventory many accounts to find which workloads actually have read-access geo-redundancy. During incidents, CLI evidence is valuable before any failover decision because failover is disruptive and should be approved, documented, and irreversible only with full awareness. That discipline keeps recovery discussions grounded in current account state rather than assumptions made during design.

Useful for

List storage accounts and filter for RA-GRS or related geo-redundant SKU names across a resource group.
Show a storage account to capture primary endpoints, secondary endpoints, location, and redundancy setting.
Check network rules and private endpoint configuration before testing secondary reads.
Export account properties and Last Sync Time evidence for disaster recovery readiness reviews.
Initiate account failover only during approved recovery procedures after replication and business impact are reviewed.

Before you run a command

Confirm tenant, subscription, resource group, storage account name, account kind, primary region, and paired secondary region.
Know whether the workload uses blobs, files, queues, tables, Data Lake Storage, or mixed services.
Check permissions carefully because storage account failover and redundancy changes are high-impact operations.
Review network rules, private endpoints, DNS, and customer-managed key dependencies before testing secondary access.
Use JSON output for endpoint, SKU, and replication properties so DR evidence can be archived.

What the output tells you

SKU output confirms whether the account is configured for read-access geo-redundant replication or another redundancy model.
Endpoint output shows the primary and secondary URLs that applications must explicitly use for secondary reads.
Geo-replication properties show Last Sync Time, helping operators estimate data staleness in the secondary region.
Network rule output reveals whether firewalls or private endpoints will block clients from reaching secondary endpoints.
Failover command output confirms operation state and should be preserved as evidence during a declared recovery event.

Mapped commands

RA-GRS redundancy operations

direct

az storage account list --resource-group <resource-group> --query "[].{name:name,sku:sku.name,location:location}" --output table

az storage accountdiscoverStorage

az storage account show --name <storage-account> --resource-group <resource-group> --query "{sku:sku.name,primary:primaryEndpoints,secondary:secondaryEndpoints,status:statusOfSecondary,lastSyncTime:geoReplicationStats.lastSyncTime}"

az storage accountdiscoverStorage

az storage account network-rule list --account-name <storage-account> --resource-group <resource-group>

az storage account network-rulediscoverStorage

az network private-endpoint-connection list --id <storage-account-resource-id>

az network private-endpoint-connectiondiscoverStorage

az storage account failover --name <storage-account> --resource-group <resource-group>

az storage accountremoveStorage

Architecture context

A seasoned Azure architect starts RA-GRS design by asking what the application will read during a regional failure and how stale that data may be. The storage account must use a redundancy option that supports read-access secondary endpoints, and applications need endpoint selection, retry logic, and monitoring of Last Sync Time. Private endpoints may require separate planning for primary and secondary access. Architects also review account failover impact, unsupported feature combinations, customer-managed key behavior, DNS, and operational authority. RA-GRS should be tested with real clients, not assumed from a portal setting. The design should also define how users are informed when the application is serving secondary, potentially stale data.

Security: Security impact is direct because RA-GRS creates a readable secondary copy of storage data. Access controls, keys, SAS tokens, RBAC assignments, encryption settings, customer-managed keys, firewall rules, and private endpoints must protect both primary and secondary access paths. A secondary endpoint can accidentally expose data if network and identity assumptions are only tested against the primary. Logs and diagnostics should show secondary reads during failover tests. Compliance teams should understand where replicated data resides and whether paired-region replication meets data residency, retention, and incident-response requirements. Security testing should verify both endpoint paths after key rotation, firewall changes, and private DNS updates.
Cost: Cost impact is direct because RA-GRS costs more than locally redundant options and may increase transaction, networking, monitoring, and operational testing effort. The business value is higher read availability and regional resilience, not cheaper storage. FinOps reviews should compare RA-GRS with GRS, GZRS, RA-GZRS, backups, and multi-region application designs. Secondary reads during tests or incidents can add transaction and bandwidth considerations. Teams should apply RA-GRS to data that truly needs regional read continuity rather than every storage account by habit. Ownership and recovery objectives should justify the premium. The decision should be reviewed per workload, not inherited automatically from a generic storage standard.
Reliability: Reliability impact is direct because RA-GRS is chosen to improve read availability during regional problems. The secondary copy is replicated asynchronously, so it can be stale; Last Sync Time tells operators what data is known to be replicated. Applications must be coded to use secondary endpoints and tolerate stale reads. Customer-initiated failover can promote the secondary, but it has consequences and should not be improvised. Reliable designs test secondary reads, monitor replication status, document failover authority, and combine RA-GRS with backups, soft delete, and application consistency controls. The design should also define recovery point expectations and customer messaging for secondary-read mode.
Performance: Performance impact is indirect for normal primary writes, but important for read-path design. Secondary reads can help during primary-region degradation, yet they may have higher latency for users or services outside the secondary region. Asynchronous replication means the fastest secondary read might still return stale data. Applications should measure primary and secondary endpoint latency, cache behavior, retry timing, and Last Sync Time under realistic conditions. RA-GRS does not make writes multi-region or instantly consistent. Performance testing should validate degraded-mode reads, DNS behavior, and whether stale data is acceptable. Degraded-mode performance should be measured before it becomes the only available read path during an incident.
Operations: Operators manage RA-GRS by checking storage account redundancy, primary and secondary endpoints, Last Sync Time, network rules, private endpoints, diagnostic logs, and failover readiness. Azure CLI is useful for inventorying accounts, confirming SKU names, exporting endpoint properties, and initiating failover only through approved incident procedures. Runbooks should describe how to test secondary reads without changing production writes, how to interpret replication lag, and who can authorize failover. Operations teams should also verify that monitoring workbooks and application health checks include secondary endpoint behavior. Operators should capture evidence during rehearsals because untested secondary endpoints often fail for networking reasons. Record test outcomes for compliance.

Common mistakes

Assuming RA-GRS automatically redirects application reads to the secondary endpoint during primary-region issues.
Ignoring Last Sync Time and promising zero data loss even though replication is asynchronous.
Creating private endpoints only for primary access, then discovering secondary reads fail during DR testing.
Treating RA-GRS as a backup replacement instead of combining it with soft delete, versioning, or backup policies.
Initiating account failover without business approval, stale-data review, or application endpoint planning.