# RA-GRS

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/ra-grs

## Quick definition

RA-GRS is a storage setting in Microsoft Azure that makes three extra copies of your data in another data center far away, and lets you read from those copies at any time. It gives you high durability and availability, even if the main region suffers a disaster. You pay a little more for this extra protection and flexibility.

## Simple meaning

Think of RA-GRS like having a safety deposit box at two different banks in two different cities. You keep your most important documents in your main box at Bank A. RA-GRS automatically makes a perfect copy of everything and puts it in Bank B, which is in a different city. If Bank A has a flood or a fire, you can still go to Bank B and read your documents. The key difference from simpler backup options is that with RA-GRS you can read from Bank B all the time, not just when Bank A is broken. That might be useful if you have customers all over the country and want them to read data from the bank that is closer to them, as long as the main bank is also working.

From a technical standpoint, RA-GRS stands for Read-Access Geo-Redundant Storage. It is a replication strategy offered by Microsoft Azure for Blob Storage, Table Storage, Queue Storage, and Azure Files. When you enable RA-GRS, Azure writes your data to the primary region first. Then it asynchronously copies that data to a paired secondary region that is at least several hundred miles away. The key feature is the 'Read-Access' part: you are allowed to read from the secondary copy at any time, not only during a failover event. This contrasts with the simpler Geo-Redundant Storage (GRS) option, where the secondary copy exists for disaster recovery but cannot be read unless Microsoft initiates a failover.

The extra copy and the ability to read from it give you a higher level of data durability and availability. Microsoft guarantees that with RA-GRS, data is durable even if the entire primary region is lost. This is because the data exists independently in two geographic locations. The trade-off is cost and potential for slightly stale reads from the secondary region. Because replication is asynchronous, the secondary copy may lag behind the primary by a few minutes. Applications that need absolutely up-to-the-second data should not rely on the secondary endpoint for reads. However, for many workloads like content distribution, backup archives, or read-heavy applications, RA-GRS offers an excellent balance of cost, availability, and durability.

## Technical definition

RA-GRS (Read-Access Geo-Redundant Storage) is a replication option for Azure Storage accounts that builds upon the base Geo-Redundant Storage (GRS) model. In GRS, data is replicated synchronously three times within a primary region (using Locally Redundant Storage, LRS), and then replicated asynchronously to a single physical location in a paired secondary region, where it is again stored three times with LRS. RA-GRS adds an explicit read-access endpoint for the secondary region (`<storageaccount>-secondary.blob.core.windows.net`), allowing clients to read data from the secondary copy at any time, not only during a Microsoft-initiated failover.

The underlying mechanism relies on Azure's geo-replication pipeline. When a write operation completes on the primary endpoint, the data is first committed to the primary LRS cluster. An asynchronous background process then copies the data to the secondary region. The replication link is a one-way, continuous stream of updates. The secondary region is automatically paired by Azure based on geographic proximity and data residency requirements (e.g., US East pairs with US West). This pairing is fixed and cannot be changed by the customer.

From a consistency perspective, RA-GRS offers eventual consistency for reads against the secondary endpoint. Because replication is asynchronous, it is possible for a read from the secondary to return data that is a few minutes older than the primary. This is a critical consideration for application architecture. The service-level agreement (SLA) for RA-GRS provides 99.99% availability for read access to the secondary endpoint, but only if the secondary is enabled with read access. The overall durability for RA-GRS is 99.99999999999999% (16 nines), meaning that the risk of losing all copies of your data is extremely low.

Implementation in Azure requires selecting the RA-GRS option when creating a storage account or by changing the replication setting on an existing account (note: some changes may require data migration). The storage account types that support RA-GRS include Blob Storage, Table Storage, Queue Storage, and Azure Files (Premium tier has different replication options). RA-GRS does not support Azure Disk Storage (managed or unmanaged disks), disks use LRS or ZRS only. Also, RA-GRS is not available for the cool or archive access tiers in some configurations; you may need to use GRS or LRS for those tiers.

Monitoring RA-GRS replication involves checking the 'Last Sync Time' property of the storage account, which indicates the most recent point in time when data was successfully written to the secondary region. This property is available via the Azure portal, REST API, or PowerShell. If the secondary falls too far behind (typically more than a few minutes), it may indicate a replication issue or high write load on the primary. In a disaster scenario, a manual or automated failover to the secondary region can be initiated, but this changes the secondary to become the new primary. RA-GRS is a core component of Azure's high-availability and disaster recovery strategy and is often tested in certification exams like AZ-900 and AZ-104.

## Real-life example

Imagine you run a small library that has a main branch in the city center. You keep a backup storage room in a suburb, but normally you never allow the public into the backup room. That is like GRS, the backup exists but is only used in an emergency. Now, consider that you want to offer a 'remote reading room' to your patrons. You set up a second reading room in the suburb, and you allow anyone to visit it at any time, not just when the main library is closed. You also have a courier service that, every few minutes, takes copies of any new books or changes from the main library and brings them to the suburban reading room. This is RA-GRS.

Think about the details: the suburban room will almost always have the same books as the main library, but there might be a slight delay. If a patron walks into the main library and checks out a book, that book is now 'checked out' on the main record. Within a minute or two, the courier updates the suburban records, but if someone walks into the suburban room right after the checkout, they might see the book as still available. That is acceptable for many things, like browsing the catalog or reading non-urgent materials, but it would be a problem for something like real-time stock trading data. In the same way, RA-GRS is perfect for content that does not need to be perfectly up-to-date every second, such as archived files, backup data, or static website content.

The RA-GRS setup also gives you an extra layer of safety. If the main library burns down, the suburban room still has all the books (with the same slight lag). You can then redirect all your patrons to the suburban room, and eventually rebuild the main library. But unlike a simple backup, the suburban room was already being used by patrons who lived closer to it, so it was never an idle resource. That is the real beauty of RA-GRS: you get disaster recovery plus extra read capacity, all from the same replicated data.

## Why it matters

RA-GRS matters because it directly affects the reliability, availability, and cost of cloud storage for organizations of any size. For IT professionals, choosing the right replication strategy is a fundamental design decision when building applications on Azure. RA-GRS sits between the lower-cost LRS (which protects only against rack failures within one data center) and the more expensive, complex options like geo-zone-redundant storage. It offers a compelling middle ground for workloads that need high durability across regions but do not require the absolute highest availability or zero recovery point objective.

In practice, RA-GRS is used for a wide variety of scenarios. Media companies use it to host video files that are read by users from multiple geographic locations, reducing latency by directing reads to the nearest region. Backup and archival solutions use RA-GRS because the secondary read endpoint allows immediate access to backups even if the primary is offline. Developers building content delivery networks or sharing large datasets often rely on RA-GRS for its cost-effective read scalability. The ability to read from the secondary without waiting for a failover is a huge operational advantage: you can test your disaster recovery plan regularly, offload read traffic during peak times, and even serve read-only workloads entirely from the secondary region.

From a management perspective, RA-GRS requires understanding of its limitations. The asynchronous replication means there is a potential for data loss of up to 15 minutes in the worst-case scenario (though typically much less). Applications that require strong consistency must either be designed to read only from the primary or use additional mechanisms like application-level write-through caches. Also, RA-GRS incurs higher storage costs than LRS because you are paying for six copies of your data (3 in primary, 3 in secondary) plus the network bandwidth for replication. However, for many organizations, the cost is justified by the peace of mind and the operational flexibility. IT certification learners need to understand RA-GRS not just as a concept, but as a real tool in the Azure administrator's toolbox.

## Why it matters in exams

RA-GRS is a recurring topic in Microsoft Azure certification exams, especially the foundational AZ-900 (Microsoft Azure Fundamentals) and the administrator-level AZ-104 (Microsoft Azure Administrator). In AZ-900, you will be expected to understand the basic differences between LRS, GRS, RA-GRS, and ZRS. Questions often take the form of 'Which replication option provides read access to a secondary region at all times?' or 'Your company needs to store archival data that must survive a regional disaster and also be readable immediately. Which storage option should you choose?' The answer is almost always RA-GRS. The exam also tests your understanding of the SLA differences: RA-GRS offers a higher read availability SLA (99.99%) compared to GRS (99.9% for reads, but only after failover).

In the AZ-104 exam, RA-GRS appears in more complex scenarios. You might be given a case study where a company has a globally distributed user base and needs to serve static assets with low latency while keeping a single source of truth. You will have to decide between RA-GRS and a combination of LRS with CDN. Another typical question involves disaster recovery planning: 'You need to ensure that data is replicated to a secondary region and that users can continue reading from that region if the primary is unreachable. What replication setting should you use?' The trick is to recognize that RA-GRS allows reads from the secondary without a failover, whereas GRS requires a failover step. Exams may also ask about limitations: 'Which of the following storage types supports RA-GRS?' The answer will exclude Azure Disk Storage and often Premium Blob Storage.

Beyond AZ-900 and AZ-104, RA-GRS might appear in the DP-900 (Azure Data Fundamentals) exam as part of data storage options. In all cases, exam questions will often pair RA-GRS with concepts like replication lag, consistency models, and cost. You must be able to explain why RA-GRS has eventual consistency for secondary reads and why this is acceptable for certain workloads but not for transaction processing systems. Memorize the 16 nines durability figure and the 99.99% read SLA for the secondary endpoint. Also, be prepared for questions that ask you to calculate costs or compare SLA percentages between options. A common exam trap is to assume that RA-GRS provides the same write availability as LRS, it does not, because writes are only acknowledged after being committed to the primary region's LRS. The secondary region's read availability is separate.

## How it appears in exam questions

RA-GRS questions in IT certification exams typically fall into four categories: definition/comparison, scenario-based selection, configuration tasks, and troubleshooting. For definition questions, you will see multiple-choice items like 'Which Azure storage replication option ensures data is replicated to a secondary region and allows read access to that secondary at any time?' The options will include LRS, GRS, RA-GRS, and ZRS. The correct answer is RA-GRS. Another variant: 'What is the primary difference between GRS and RA-GRS?' The answer focuses on the read-access capability of RA-GRS.

Scenario-based questions are more complex. For example: 'A company stores customer profile images in Azure Blob Storage. They need the images to be available for reading from two different geographic regions but only updated from one location. They also want to minimize costs. Which replication strategy should they use?' The correct response would be RA-GRS, because it provides a secondary read endpoint without needing a separate storage account or CDN. Another scenario: 'A financial application requires that read operations always return the most recent write. The application uses Azure Queue Storage. Which replication option is NOT suitable?' RA-GRS would be unsuitable because it provides eventual consistency for secondary reads; the stronger consistency needed would call for LRS or ZRS only.

Configuration questions test your knowledge of how to enable RA-GRS. You might be asked: 'When creating a new storage account using the Azure portal, under which section do you select RA-GRS?' The answer is 'Replication' in the 'Basics' tab. You might also see: 'You have an existing storage account using LRS. You want to change it to RA-GRS. What is the impact?' The answer involves data migration and possible downtime, or that it is not always a direct change and might require creating a new account. Troubleshooting questions could present: 'Users report that reads from the secondary endpoint for a storage account are returning data that is 10 minutes old. What is the likely cause?' The answer is the asynchronous replication lag, which is expected behavior, and the solution might be to read from the primary if consistency is required, or to monitor the 'Last Sync Time' property.

You may also see questions that test your understanding of the 'Last Sync Time' metric. For instance: 'The Last Sync Time for your RA-GRS storage account shows a time that is 30 minutes old. What does this indicate?' The correct interpretation is that the secondary region has not received the most recent 30 minutes of writes, which could be due to a large number of writes or a replication issue. This is important for failover planning. Overall, exam questions on RA-GRS reward a clear understanding of when eventual consistency is acceptable and when it is not, and the trade-offs between cost, durability, and availability.

## Example scenario

Contoso Ltd. is a medium-sized company that provides online training videos. They host the video files in Azure Blob Storage. Currently, they use Locally Redundant Storage (LRS) which protects against a single data center failure but not a regional outage. The company has users in both the United States and Europe. They want to ensure that if the US data center experiences a problem, European users can still access the videos. They also want to improve read speed for European users without paying for a full CDN.

The IT team decides to migrate the storage account to RA-GRS. They choose a primary region in US East and, as Azure automatically pairs it, the secondary region becomes US West. This does not directly help European users because the secondary is still in the US. So they reconsider: they create a new storage account with the primary region in US West and a secondary in US West? That does not help either. Actually, Azure paired regions are fixed; US West 2 pairs with US West? No, that is not correct. The correct pairing for US East is US West. So to serve European users better, they might need a separate storage account in Europe. This scenario illustrates that RA-GRS is not a magic bullet for global latency; it is primarily for disaster recovery and limited geographic read distribution.

After setting up RA-GRS, Contoso configures their video player application to try reading from the secondary endpoint first for European users. If the secondary read fails (e.g., due to a regional outage), the application falls back to the primary. This works well because the videos do not change frequently; the replication lag of a few minutes is acceptable. The company also benefits from the 16 nines durability, knowing that even a catastrophic event in the primary region will not lose their content. They monitor the 'Last Sync Time' to ensure replication is healthy. This scenario shows RA-GRS in a practical, exam-relevant context: a trade-off between cost, complexity, and latency improvement, with a primary goal of disaster recovery.

## Common mistakes

- **Mistake:** Believing RA-GRS provides read access to the secondary only after a failover.
  - Why it is wrong: RA-GRS explicitly allows read access to the secondary endpoint at any time, not just after a failover. GRS (without Read-Access) does require a failover for secondary reads.
  - Fix: Remember that the 'RA' in RA-GRS stands for Read-Access, meaning you can always read from the secondary copy.
- **Mistake:** Thinking RA-GRS guarantees strong consistency for reads from the secondary endpoint.
  - Why it is wrong: RA-GRS offers eventual consistency for the secondary endpoint because replication is asynchronous. The secondary might lag behind the primary by minutes.
  - Fix: Use RA-GRS only for workloads that can tolerate stale data reads. For strongly consistent reads, use LRS and read from the primary.
- **Mistake:** Assuming RA-GRS is available for all Azure storage types, including Azure Disk Storage.
  - Why it is wrong: RA-GRS is available for Blob Storage, Table Storage, Queue Storage, and Azure Files (standard tier only). Managed and unmanaged disks do not support RA-GRS; they use LRS or ZRS.
  - Fix: When selecting replication for disk storage, look at LRS or ZRS options. For general-purpose storage accounts, RA-GRS is an option.
- **Mistake:** Confusing RA-GRS with Azure CDN or content delivery networks.
  - Why it is wrong: RA-GRS replicates data to a single secondary region, not multiple edge locations globally. For global low-latency reads, a CDN or multiple storage accounts with different primary regions are needed.
  - Fix: Use RA-GRS for disaster recovery and limited geographic read redundancy. Use CDN for global content distribution.
- **Mistake:** Forgetting that RA-GRS costs more than LRS because it stores six copies of the data (three in primary, three in secondary) plus replication bandwidth.
  - Why it is wrong: Learners sometimes think RA-GRS is only slightly more expensive, but the cost is roughly double that of LRS due to the additional storage and network traffic.
  - Fix: Always consider cost in design decisions. If you don't need the secondary region, LRS or ZRS might be more cost-effective.
- **Mistake:** Thinking that RA-GRS replication is synchronous between regions.
  - Why it is wrong: Geo-replication in Azure is always asynchronous. Synchronous replication across regions would be too slow due to network latency and is not supported in standard Azure Storage.
  - Fix: Understand that asynchronous replication means there is always a potential for data loss in the worst case (up to 15 minutes). Plan accordingly.

## Exam trap

{"trap":"A question asks: 'Which replication option provides the highest durability for your data in Azure Blob Storage?' The correct answer is often RA-GRS or GRS, but learners may incorrectly choose ZRS thinking zone redundancy is better than geo-redundancy.","why_learners_choose_it":"Learners assume that zone redundancy (three copies across availability zones within a region) is stronger than geo-redundancy (two regions). While ZRS protects against a single zone failure, it does not protect against a full region outage. RA-GRS protects against a full region outage by having a copy in a separate geographic region.","how_to_avoid_it":"Remember that 'durability' refers to the probability of losing all copies. RA-GRS/GRS have 16 nines (99.99999999999999%) durability, which is higher than ZRS's 11 nines, because geo-redundancy protects against region-level disasters. Always compare durability based on the number and geographic distribution of copies."}

## Commonly confused with

- **RA-GRS vs GRS (Geo-Redundant Storage):** GRS is identical to RA-GRS in terms of replication, there are six copies across two regions. The only difference is that GRS does not allow read access to the secondary region unless a failover is initiated by Microsoft. RA-GRS explicitly allows reading from the secondary at any time. (Example: You have a storage account with GRS. After a primary region outage, you must wait for Microsoft to fail over before you can read from the secondary. With RA-GRS, you can read from the secondary immediately during the outage.)
- **RA-GRS vs LRS (Locally Redundant Storage):** LRS creates three synchronous copies of your data within a single data center in the primary region. It does not replicate to a secondary region at all. RA-GRS replicates to a secondary region and provides six copies, which gives much higher durability. (Example: An LRS storage account loses all data if the entire data center is destroyed. An RA-GRS storage account survives such a disaster because the secondary region has a copy.)
- **RA-GRS vs ZRS (Zone-Redundant Storage):** ZRS replicates data synchronously across three Azure availability zones within a single region. It protects against a zone failure (e.g., one data center failing) but not against a full region outage. RA-GRS protects against a full region outage by using a geographically separate region. (Example: A ZRS storage account survives a power failure in one availability zone because the data exists in other zones in the same city. A RA-GRS storage account survives a hurricane that takes out the entire city, because data is replicated to a different city.)

## Step-by-step breakdown

1. **Create or select a Storage Account** — Begin by creating a new Azure Storage account or selecting an existing one that supports RA-GRS. For standard general-purpose v2 accounts, RA-GRS is available. Note that premium accounts and Azure Disk Storage do not support RA-GRS.
2. **Choose the Replication option** — In the 'Basics' tab of the storage account creation wizard, under 'Data protection' or 'Replication', select 'Read-access geo-redundant storage (RA-GRS)'. This enables the secondary region pairing and creates the read-only endpoint.
3. **Azure pairs the primary region with a secondary region automatically** — You cannot choose the secondary region; Azure uses a fixed pairing (e.g., US East pairs with US West). This ensures geographic separation. The pairing is designed to balance disaster recovery and latency.
4. **Data is written to the primary region and replicated asynchronously** — When you write data to the primary endpoint, it is first stored synchronously three times (LRS) in the primary region. Then, a background process copies the data to the secondary region, where it is also stored three times. This asynchronous replication means a possible lag.
5. **Access the secondary read endpoint** — Once the storage account is created, you can access the secondary endpoint using a URL of the form `<storageaccount>-secondary.blob.core.windows.net`. You can read data from this endpoint at any time using the same authentication methods as the primary.
6. **Monitor replication health using Last Sync Time** — Check the 'Last Sync Time' property in the Azure portal or via APIs. This value indicates the most recent time when all data from the primary was successfully written to the secondary. If the time is far in the past, replication may be lagging or failing.
7. **In a disaster, initiate failover (if needed) or continue using secondary reads** — If the primary region fails, you can still read from the secondary endpoint. If you need to make the secondary region the new primary for writes, you must perform a manual failover (which is a destructive process that makes the secondary the new primary). RA-GRS does not automatically failover.

## Practical mini-lesson

RA-GRS is one of the most important replication options in Azure Storage. As an IT professional, you need to understand when and how to use it. Start by evaluating your workload: do you need to tolerate a regional disaster? If yes, RA-GRS is a strong candidate. Then, assess your read consistency requirements. If your application can handle a few minutes of staleness, RA-GRS works well. For example, a static website or a media library can serve slightly stale content without issues. However, an e-commerce checkout system cannot use RA-GRS for reading inventory because it must see the latest stock levels.

When you configure RA-GRS, you will see that the storage account has two endpoints. The primary endpoint ends with `.blob.core.windows.net` and the secondary ends with `-secondary.blob.core.windows.net`. You can use the same SAS tokens or access keys for both. This means you can build applications that switch between endpoints based on latency or availability. A common pattern is to have a routing layer that tries the secondary endpoint for read requests, and only goes to the primary if the secondary is unavailable or if the data needs to be absolutely fresh. You can implement this with Azure Traffic Manager or with application logic.

One practical pitfall: monitoring replication lag is crucial. Azure provides the 'Last Sync Time' property, but it is not real-time. If you have a high write volume, the lag might increase. You should set up alerts based on this metric. Another consideration is cost: RA-GRS storage costs roughly double that of LRS because you are paying for six copies (3 in primary, 3 in secondary) plus network egress for replication. Do not enable RA-GRS for every storage account; reserve it for critical data. Also, remember that RA-GRS does not provide automatic failover. You must plan for manual failover or use higher-level services like Azure Site Recovery for full application failover.

Finally, always test your RA-GRS setup. Simulate a read from the secondary endpoint and verify that the data is accessible. Include RA-GRS in your disaster recovery drills. This practical knowledge will serve you well in your IT role and in exams where configuration and troubleshooting scenarios are common.

## Memory tip

RA-GRS = Read-Access Geo-Redundant Storage: you can ‘Read’ the ‘A’ copy (secondary) anytime, even before a disaster.

## FAQ

**Can I change an existing storage account from LRS to RA-GRS without downtime?**

Yes, you can change the replication setting from LRS to RA-GRS for a standard general-purpose v2 storage account without downtime, but it may trigger a full data copy to the secondary region, which takes time. No data loss occurs.

**Does RA-GRS guarantee that reads from the secondary will always return the latest data?**

No. Because replication is asynchronous, reads from the secondary endpoint are eventually consistent. The secondary may lag behind the primary by a few minutes. For strongly consistent reads, read from the primary.

**Can I use RA-GRS for Azure Disk Storage (managed disks)?**

No. RA-GRS is not supported for Azure Disk Storage. Disks use LRS or ZRS. For disaster recovery of VMs, use Azure Site Recovery or snapshot replication.

**What happens if the primary region fails? Can I still read from the secondary?**

Yes, because RA-GRS provides read access to the secondary at all times. You can continue reading from the secondary endpoint even before any failover is initiated.

**How do I access the secondary read endpoint?**

The secondary endpoint URL is `<storageaccount>-secondary.blob.core.windows.net`. Use the same access keys or SAS tokens that you use for the primary endpoint.

**Is RA-GRS available for Azure Files?**

Yes, for standard file shares (not premium). RA-GRS is available for Azure Files in standard tier storage accounts.

## Summary

RA-GRS, or Read-Access Geo-Redundant Storage, is a critical Azure Storage replication option that provides high durability by replicating data to a secondary geographic region and, uniquely, allows read-only access to that secondary copy at any time. This differentiates it from standard GRS, which only permits reads after a failover. Understanding RA-GRS is essential for IT certification exams like AZ-900 and AZ-104, where you will be tested on its characteristics, use cases, and limitations. The key takeaway is that RA-GRS offers an excellent balance of cost, durability, and availability for workloads that can tolerate eventual consistency on reads. It is not suitable for strongly consistent applications or for all storage types, such as disks. In practice, RA-GRS is used for disaster recovery, content distribution, and backup scenarios where immediate read access to a secondary copy is beneficial.

For exam success, remember the 'RA' stands for Read-Access, meaning the secondary is always readable. Memorize the 16 nines durability and the 99.99% read SLA for the secondary. Be ready to compare it with LRS, GRS, and ZRS in scenario-based questions. Also, understand the asynchronous replication lag and when it is acceptable. In your professional role, use RA-GRS selectively for critical data that needs regional protection but does not require absolute consistency. Monitor the 'Last Sync Time' and plan for manual failover procedures. With this knowledge, you will be prepared for exam questions and real-world Azure storage design decisions.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/ra-grs