You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Zone-redundant storage (ZRS) protects data by synchronously copying it across three separate availability zones within a single Azure region. An availability zone is a distinct physical location with its own power, cooling, and network. This setup ensures your data remains available even if an entire data center fails. ZRS provides very high durability and is recommended for workloads that need high availability and must keep data within a specific geographic region for governance reasons. Unlike some other options, ZRS allows applications to continue reading and writing without interruption during a zonal outage.
For protection against a major disaster affecting an entire region, you can use geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS). Both options asynchronously copy your data to a secondary geographic region hundreds of miles away. The key difference is the protection in the primary region: GRS uses locally redundant storage (LRS), while GZRS uses the stronger ZRS. In both cases, the data in the secondary region is always stored using LRS. These options are critical for business continuity and provide the highest levels of data durability.
To maximize availability, you can enable read-access geo-redundant storage (RA-GRS) or RA-GZRS. These options provide a secondary, read-only endpoint in the paired region. If the primary region becomes unavailable, applications can be designed to shift their read operations to this secondary endpoint. It's important to know that data on the secondary side is eventually consistent, meaning it may be slightly behind the primary due to the asynchronous replication. Note that Azure Files does not support read-access geo-redundancy.
A failover is the process of making the secondary region the new active primary region. This is done by updating DNS records. An unplanned failover carries a risk of data loss because replication is asynchronous; the recovery point objective (RPO) is typically under 15 minutes. Importantly, initiating an unplanned failover converts the storage account to LRS in the new region, and you must manually re-enable geo-redundancy afterward. You must also consider data residency, as the paired secondary region is fixed by Azure and cannot be customized.
You configure storage redundancy through the Azure Portal, PowerShell, or CLI. Adding geo-redundancy is often a simple setting change, but switching to zone-redundancy usually requires a conversion process or a manual migration. There are important constraints: Premium SSD file shares only support LRS or ZRS, not native geo-redundancy. Higher redundancy levels like GZRS also incur higher storage costs and potential charges for cross-region data transfer.
Choosing an Azure Storage redundancy option is a direct way to support your data protection and disaster recovery plans. The redundancy model you select defines your recovery point objective (RPO), which is how much data loss you can tolerate, and your recovery time objective (RTO), which is how quickly you need to restore operations. These options protect against failures ranging from a single hard drive to an entire region.
For protection within your primary region, you have two main choices. Locally redundant storage (LRS) is the most cost-effective. It replicates your data three times within a single datacenter, protecting against hardware failures but not against a disaster that affects the whole building. Zone-redundant storage (ZRS) provides higher availability by synchronously replicating data across three physically separate availability zones in the same region. ZRS is recommended for applications that require continuous operation.
To protect against a regional outage, you use geo-redundant options. Geo-redundant storage (GRS) replicates data from an LRS primary to an LRS secondary region. Geo-zone-redundant storage (GZRS) replicates data from a ZRS primary to an LRS secondary region. A key feature of these options is support for storage account failover. During an outage, you can initiate this failover, which updates DNS so that the secondary region's endpoints become the new primary, restoring full read and write access.
For the highest availability design, you can use read-access geo-redundant storage (RA-GRS) or RA-GZRS. These provide read access to the secondary endpoint. This allows applications to continue serving read requests even if the primary region is completely down. Applications must be designed to handle eventual consistency, as the data in the secondary region will be slightly behind the primary.
Azure supports three failover types. A customer-managed unplanned failover is for real outages, while a customer-managed planned failover is for testing. A Microsoft-managed failover is initiated by Microsoft only in extreme, region-wide disasters and should not be relied upon for your recovery plans. After an unplanned failover, the account is converted to LRS, and you must manually re-enable geo-redundancy, which involves data transfer costs. Always check the Last Sync Time property before a failover to understand potential data loss.
Azure Storage ensures data is durable and available by keeping multiple copies. The different redundancy models protect against various levels of failure. Your choice balances cost against the level of protection you need for your data and applications.
The main redundancy options form a spectrum from least to most protective:
When evaluating which model to use, consider three main factors. First, balance cost versus availability: LRS is cheapest but offers the least protection, while GZRS offers the most at a higher price. Second, determine your replication needs: decide if you need protection only within a region (LRS/ZRS) or across regions (GRS/GZRS). Third, assess if your application needs read access during an outage, which would point you toward RA-GRS or RA-GZRS.
A system architecture diagram showing how GZRS synchronously replicates data across three availability zones in the primary region, then asynchronously replicates to an LRS secondary region for disaster recovery.
To apply these models effectively, follow some key practices. Use separate storage accounts for data with different redundancy needs. Have a clear disaster recovery plan that includes your failover strategy. Finally, actively monitor costs, as higher redundancy levels and cross-region data transfers increase your expenses.
Prepare and test your skills
Prepare and test your skills
The main difference is the level of replication in the primary region: geo-redundant storage (GRS) replicates data using locally redundant storage (LRS) within a single datacenter, whereas geo-zone-redundant storage (GZRS) uses zone-redundant storage (ZRS) across three availability zones. In both configurations, data is asynchronously replicated to a secondary paired region where it is always stored using LRS.
An unplanned failover updates DNS records so that the secondary region becomes the new active primary region, restoring read and write capabilities with a potential recovery point objective of under 15 minutes. Once the failover completes, the account is converted to locally redundant storage (LRS) in the new region, requiring you to manually re-enable geo-redundancy.
Read-access geo-redundant storage (RA-GRS) provides a secondary, read-only endpoint in the paired region so applications can continue serving read requests if the primary region becomes unavailable. Because replication between regions is asynchronous, applications using this secondary endpoint must be designed to handle eventually consistent data that may lag slightly behind the primary.
Premium SSD file shares in Azure Files support only locally redundant storage (LRS) and zone-redundant storage (ZRS). They do not support native geo-redundancy, and Azure Files does not support read-access geo-redundancy options.
StudyCerts
StudyCerts