Change Redundancy Configuration for Azure Files
Azure stores multiple copies of data to meet availability and SLA requirements. This article explains how to change replication (redundancy) settings for an existing storage account that hosts Azure file shares, the available options, limitations, downtime considerations, and cost implications.
Applies to (high level)
Applies to Microsoft.Storage accounts (Provisioned v2, Provisioned v1, Pay-as-you-go) with HDD/SSD tiers — availability of SMB/NFS depends on specific SKU/plan. (Full table in original article.)
Replication options and trade-offs
Main choices:
LRS (locally redundant) — replicates within a single region.
ZRS (zone-redundant) — replicates across availability zones in a region.
GRS (geo-redundant) — replicates to a secondary geographic region.
GZRS (geo-zone-redundant) — combines zone redundancy and geo-replication.
Consider trade-offs: cost vs. availability and protection against regional disasters.
Note: RA-GRS and RA-GZRS (read-access geo-redundant variants) are not supported for Azure Files — if configured, file shares are treated and billed as GRS/GZRS.
For more detail: see Azure Files redundancy.
Ways to change replication
Two primary approaches:
Modify the redundancy setting (add/remove geo-redundancy or RA) using the Azure portal, PowerShell, or Azure CLI — often supported without application downtime.
Manual migration — copy data to a new storage account (required when converting across regions or when conversion isn't supported). Manual migration can incur downtime but gives control over timing.
Change via Portal / PowerShell / CLI
Portal: Update the storage account's Redundancy setting under Data management → Redundancy → Save.
PowerShell (change SKU):
Azure CLI (change SKU):
Changes made in the portal typically do not cause downtime for applications.
Manual migration
Use tools like AzCopy, storage client libraries, DistCp (with HDInsight/Hadoop), or other reliable tools to copy data to a new storage account.
Required when moving a storage account to another region.
Manual migration can cause downtime; use when you need a specific completion window or when conversion isn't supported.
See: Move an Azure Storage account to another region.
Limitations and conflicts
Region support: Not all regions support all replication options — verify support for your target configuration.
Feature conflicts: Some features are incompatible with geo-failover or other geo features; enabling certain features can block conversion to GRS/GZRS or require disabling before failover. See Unsupported features and services for details.
Storage account type: Some account types support only particular redundancy options. Check the storage account overview for supported redundancy per account type. (Article contains a table showing support and whether conversion/manual migration are available.)
Downtime
Changing redundancy via portal/CLI/PowerShell typically does not require downtime.
Manual migration requires downtime (but allows scheduling and control).
Costs
Replication options from least to most expensive: LRS → ZRS → GRS → GZRS.
Costs depend on storage and egress bandwidth. Geo-redundancy changes incur egress bandwidth charges because data is replicated to the secondary region; subsequent writes to primary also incur egress to replicate to secondary.
Removing geo-redundancy (e.g., GRS → LRS) has no charge for the change, but replicated data in the secondary region is deleted.
For pricing details: Azure Files Pricing page.
Important notes
RA-GRS and RA-GZRS aren't supported for Azure Files; if configured, file shares will be treated and billed as GRS/GZRS.
See also
Azure Files redundancy
Move an Azure Storage account to another region
Last updated in the original article: 11/11/2025.
Was this helpful?