Azure Storage Redundancy: LRS vs ZRS vs GRS vs GZRS Explained

Choose LRS for the cheapest, easily reconstructed data, ZRS when the data must survive the loss of a datacenter or availability zone, and GRS or GZRS when it must survive the loss of the whole region. GRS adds a second region to LRS, GZRS adds a second region to ZRS, and the RA variants add read access to the secondary copy. The setting applies to the whole storage account and you can change it later.

Who this is for and what you will have at the end

This guide is for architects, administrators and developers choosing or reviewing the redundancy of an Azure storage account for blobs, files, queues, tables or disks.

At the end you will have:

• A clear picture of how each option replicates data.
• The documented durability and availability figures side by side.
• A matching of failure scenarios to options.
• The service and account-type limits that rule options out.
• Commands for changing redundancy, and the restrictions that apply.

How the four options replicate data

Azure Storage always stores multiple copies of your data. The redundancy setting is shared by every service in the storage account, so all resources in one account have the same setting. If different data needs different redundancy, use separate accounts.

The difference between GRS and GZRS is only how data is replicated in the primary region. In the secondary region, data is always replicated synchronously using LRS.

Key points from the documentation:

• LRS replicates within one datacenter. Choosing a zone isn't supported, although Azure might move or expand LRS accounts across zones for load balancing. If a disaster such as fire or flooding strikes the datacenter, all replicas might be lost or unrecoverable, and a temporary event can make them temporarily unavailable.
• ZRS writes synchronously. A write returns only after the data is written to all replicas across the three availability zones, or all available zones if one is temporarily down. If a zone becomes unavailable, Azure performs networking updates such as DNS repointing, so applications should use retry policies with exponential back-off.
• GRS and GZRS write to the primary first, then replicate asynchronously to the secondary region, which is hundreds of miles away. The paired region is set by the primary region and can't be changed.
• RA-GRS and RA-GZRS add read access to the secondary. The secondary endpoint appends -secondary to the account name, for example myaccount-secondary.blob.core.windows.net, and the account keys are the same for both endpoints.

Durability and availability figures

For the cool and cold tiers the read figures are lower, as listed in the Microsoft page. Check the Azure Storage SLA for the exact terms before you quote these to a customer or auditor.

Durability is not availability. Durability is the chance the data still exists. Availability is the chance you can reach it at that moment.

Which failures does each option survive?

"After account failover" means that to restore write availability when the primary region is unavailable, you must fail over the account. During the failover process, data is inaccessible. After it completes, the secondary region becomes the primary and you can read and write. See the Azure Storage disaster recovery guidance for the process.

Plan for data loss

Because replication to the secondary region is asynchronous, the secondary is typically behind the primary. If the primary region can't be recovered, some recent writes could be lost and files within a directory or container may not be consistent. The interval between the latest write to the primary and the last write to the secondary is the recovery point objective (RPO). Azure Storage offers Geo priority replication, which keeps the RPO for block blobs to 15 minutes or less.

What redundancy does not cover

All replicas reflect the same current state. A deletion or overwrite applies to all copies at the same time, so redundancy protects against hardware failure and not against data-modifying operations. For accidental deletion use blob soft delete, versioning or backup. See /blog/azure-backup-vm-recovery-services-vault for VM backup, and /blog/azure-sql-database-backup-restore-pitr-ltr for the equivalent on databases.

Service and account-type support

Restrictions to note:

• Azure Files doesn't support RA-GRS or RA-GZRS.
• The archive tier for Blob Storage isn't supported for ZRS, GZRS or RA-GZRS accounts. It is supported for LRS, GRS and RA-GRS.
• Unmanaged disks don't support ZRS or GZRS, and Microsoft doesn't recommend GRS for them because of consistency issues with asynchronous geo-replication.
• Geo-zone redundancy needs a region with availability zones and a paired region.
• Standard general-purpose v2 accounts support all four options. Premium block blob and SSD file share accounts support LRS and ZRS only.
• Microsoft recommends ZRS for Azure Files workloads and for Azure Data Lake Storage workloads. For high availability, it recommends ZRS in the primary region and replicating to a secondary region as well.

Choosing: a decision guide

1. Can you rebuild the data from elsewhere, and is a datacenter outage acceptable? Choose LRS. It is the lowest-cost option and also fits data that must stay inside one region for governance reasons.
2. Must the data stay readable and writable if a zone or datacenter fails, within one region? Choose ZRS. Microsoft also recommends it to restrict replication to one region while still surviving a zone failure.
3. Must the data survive losing the whole region? Choose GRS if zone failures in the primary are acceptable to ride out, or GZRS to cover both zone and regional failures.
4. Must applications read during a primary outage without waiting for failover? Add read access: RA-GRS or RA-GZRS. Design the application to fall back to the -secondary endpoint.

Cost order, from least to most expensive: LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS. Check the Azure Storage pricing page for current per-GB prices in your region, since this guide does not quote them.

Change the redundancy of an existing account

You can change redundancy as needed, but some paths have limits. There are three methods:

• Add or remove geo-replication or read access with the portal, PowerShell or CLI.
• Add or remove zone redundancy with a conversion.
• Perform a manual migration where the first two aren't supported, or when you need a fixed timeline.

Geo-redundancy and read access can change in the same operation. Any change that involves zone redundancy must be done in a separate step. For example, LRS to GZRS is two steps: LRS to GRS first, then a conversion to GZRS, or the reverse order.

Portal

1. Open the storage account in the Azure portal.
2. Under Data management, select Redundancy.
3. Change the Redundancy setting and select Save.

Changing replication in the portal causes no downtime, including changes that need a conversion.

PowerShell and CLI

Change between locally redundant and geo-redundant storage with the -SkuName or --sku parameter:

Set-AzStorageAccount -ResourceGroupName <resource_group> `
    -Name <storage_account> `
    -SkuName <sku>

az storage account update \
    --name <storage-account> \
    --resource-group <resource_group> \
    --sku <sku>

To add or remove zone redundancy, start a conversion. Standard_ZRS is the target SKU in the documented examples:

Start-AzStorageAccountMigration `
    -AccountName <storage_account> `
    -ResourceGroupName <resource_group> `
    -TargetSku Standard_ZRS `
    -AsJob

az storage account migration start \
    --account-name <storage-account> \
    --resource-group <resource_group> \
    --sku Standard_ZRS \
    --no-wait

Track progress with Get-AzStorageAccountMigration or az storage account migration show --account-name <storage-account> --resource-group <resource_group> --name "default". The status moves from Submitted for conversion to In Progress and then Completed or Failed. If it fails, open a support request.

What to know about conversions

• A conversion needs no data loss or application downtime. HNS-enabled accounts might see a pause of under 30 seconds. Endpoints, keys and SAS tokens stay unchanged.
• There is no SLA for completion. A customer-initiated conversion typically begins within 72 hours but can take longer. If you need a hard date, plan a manual migration.
• After a zone-redundancy conversion, wait at least 24 hours before changing redundancy again.
• Adding geo-redundancy incurs a one-time egress charge for replicating the whole account, and later writes incur egress to replicate. Removing geo-redundancy is free, but the secondary data is deleted.
• If you remove read access (RA-GRS to GRS or LRS), the account is billed as RA-GRS for another 30 days.
• Failover to the secondary can't start until initial synchronization completes, even though enabling geo-redundancy appears instant.

Blocking conditions

Manual migration means copying data to a new account with a tool such as AzCopy. It can cause application downtime and is required to move to a different region.

Troubleshooting

Checklist

• Choose redundancy per account, based on the data it holds.
• Prefer ZRS in the primary region where high availability matters, and add geo-replication for regional disasters.
• Use RA-GRS or RA-GZRS only if the application can read from the -secondary endpoint.
• Check that region, account type, access tiers and features support your choice.
• Plan conversions with no completion SLA in mind, and use manual migration for hard deadlines.
• Add backup, soft delete or versioning, because redundancy doesn't protect against deletion.
• Review costs: egress when adding geo-replication, and higher per-GB cost for each step up.

References

• Azure Storage redundancy: https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy
• Change how a storage account is replicated: https://learn.microsoft.com/en-us/azure/storage/common/redundancy-migration
• Azure Storage pricing: https://azure.microsoft.com/pricing/details/storage/
• Service Level Agreement for Storage Accounts: https://azure.microsoft.com/support/legal/sla/storage/