Understanding RA-GRS and RA-GZRS in Azure Storage Accounts

Introduction

When it comes to ensuring data durability, availability, and accessibility, Azure Storage offers robust redundancy options. Two key options designed for high availability across regions are:

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

Let’s break these down without the technical fluff so you can decide what works best for your needs.

RA-GRS: Read-Access Geo-Redundant Storage

What is it?

RA-GRS ensures your data is copied to a primary region and then asynchronously replicated to a secondary region hundreds of miles away. In case of a disaster in the primary region, you can still read your data from the secondary region.

Key Points:

1. Replication Levels:
   • Data is stored three times in the primary region.
   • Data is also replicated three times in the secondary region.
2. Read Access:
   • Your application can read data from the secondary region (read-access feature) even if the primary region is available.
3. Use Cases:
   • Disaster recovery for critical applications.
   • Businesses needing high availability across regions.
4. Costs:
   • Slightly cheaper than RA-GZRS, but with slightly lower durability guarantees.

RA-GZRS: Read-Access Geo-Zone Redundant Storage

What is it?

RA-GZRS takes data durability a step further. It combines zone redundancy in the primary region with geo-redundancy. This means your data is:

1. Copied across multiple availability zones in the primary region (for higher resilience).
2. Then asynchronously replicated to the secondary region.

Key Points:

1. Replication Levels:
   • Data is copied across three zones in the primary region.
   • Data is also replicated across three zones in the secondary region.
2. Read Access:
   • Like RA-GRS, your application can read data from the secondary region even when the primary is operational.
3. Use Cases:
   • Applications requiring extremely high durability and availability.
   • Businesses in disaster-prone areas.
4. Costs:
   • More expensive than RA-GRS but worth it for applications needing ultra-resilient data.

How to Select the Secondary Region?

Azure automatically pairs your primary region with a secondary region for geo-redundancy. While you can’t manually choose the secondary, understanding region pairing ensures it aligns with your needs.

Key Considerations:

1. Azure Region Pairs:
   • Predefined pairs ensure data compliance and low latency (e.g., East US paired with West US).
   • Check Azure Region Pair Documentation.
2. Latency:
   • Ensure latency from your paired regions meets your application’s performance requirements.
3. Disaster Recovery:
   • Select a primary region with a geographically distant secondary to avoid simultaneous disruptions.
4. Compliance:
   • Confirm the paired region meets your regulatory requirements (e.g., GDPR, CCPA).
5. Cost:
   • Secondary region costs may vary; factor this into your decision.
6. Availability:
   • Ensure the secondary region supports necessary Azure services for failover and recovery.

Pro Tip:

Plan for scalability and redundancy by reviewing the capabilities of your paired regions before finalizing your architecture.

How to Read Data from the Secondary Region?

When using RA-GRS or RA-GZRS, Azure provides a secondary endpoint to access data replicated in the secondary region. Here’s how you can read from it:

1. Enable Read-Access Geo-Redundancy:
   • Ensure your storage account is configured with RA-GRS or RA-GZRS.
2. Locate the Secondary Endpoint:
   • Azure automatically provides a secondary endpoint. The format is:https://<storage_account_name>-secondary.blob.core.windows.net
3. Access the Secondary Endpoint:
   • Use Azure SDKs, APIs, or tools like Azure Storage Explorer to connect to the secondary endpoint.
     Example with SDK:secondary_endpoint = "https://<storage_account_name>-secondary.blob.core.windows.net"
4. Simulate Primary Failure (Optional):
   • Test read-access by explicitly directing your application to use the secondary endpoint.

Key Points to Remember:

• Read-Only Access: The secondary endpoint allows only reads unless a failover is performed.
• Consistency: Replication to the secondary region is asynchronous; recent writes might not immediately reflect.

What Happens If the Primary Region is Down?

1. Without Failover:
   • The secondary region is read-only. You can read data using the secondary endpoint, but write operations will not work.
2. With Failover:
   • Initiating a failover promotes the secondary region to become the new primary.
   • After failover:
     • Both read and write operations are handled by the new primary region.
     • Your application must update to use the new primary endpoint.

Failover Process:

To initiate failover, use the Azure Portal or Azure CLI:

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

Comparison Table: RA-GRS vs. RA-GZRS

Feature	RA-GRS	RA-GZRS
Primary Region Redundancy	Three copies in a single zone	Three copies across multiple zones
Secondary Region Redundancy	Three copies in a secondary region	Three copies in a secondary region
Read-Access to Secondary	Yes	Yes
Durability	High	Ultra-High
Cost	Lower than RA-GZRS	Higher than RA-GRS
Use Case	General disaster recovery	Mission-critical apps needing extreme durability

 

When to Use What?

• Choose RA-GRS if:
  • Cost is a concern.
  • Your application can tolerate some risk of zone-level failures in the primary region.
• Choose RA-GZRS if:
  • You need the highest level of durability.
  • Your application is mission-critical and cannot afford downtime or data loss.

Conclusion

Both RA-GRS and RA-GZRS are excellent choices for cross-region redundancy. The decision boils down to:

1. How much risk you can tolerate.
2. Your application’s availability requirements.
3. Your budget.

By understanding the benefits of each, you can ensure business continuity and peace of mind with geo-redundant accessibility. 

See also

Read about Azure storage account failover types at understanding-failover-types-in-azure-storage-account.