--- title: "Replicate Data Across Zones with Azure NetApp Files" description: "Configure cross-zone replication for Azure NetApp Files to protect against availability zone failures with asynchronous replication and zero network transfer fees." canonical: "https://adamtheautomator.com/replicate-data-across-zones-azure-netapp-files/" --- # Replicate Data Across Zones with Azure NetApp Files > Configure cross-zone replication for Azure NetApp Files to protect against availability zone failures with asynchronous replication and zero network transfer fees. Source: https://adamtheautomator.com/replicate-data-across-zones-azure-netapp-files/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Replicate Data Across Zones with Azure NetApp Files](https://adamtheautomator.com/wp-content/uploads/2026/02/featured_image-6.webp) # Replicate Data Across Zones with Azure NetApp Files [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)12 February 20268 min. read Categories: [Cloud](/category/cloud/) Tags:[Azure](/tag/azure/)[Azure CLI](/tag/azure-cli/) Table of Contents * [What Cross-Zone Replication Actually Does](#what-cross-zone-replication-actually-does) * [Prerequisites](#prerequisites) * [Create the Source Volume](#create-the-source-volume) * [Configure the Destination Volume](#configure-the-destination-volume) * [Monitor Replication Health](#monitor-replication-health) * [Test Failover](#test-failover) * [Resume Replication After Testing](#resume-replication-after-testing) * [Cost Implications](#cost-implications) * [Limitations to Understand](#limitations-to-understand) * [When to Use Cross-Zone Replication](#when-to-use-cross-zone-replication) * [Next Steps](#next-steps) You deployed your production workload to Azure. Everything runs smoothly until one Tuesday afternoon when an [availability zone](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview) goes offline. Your file storage—the volumes holding SAP HANA data, Oracle databases, and shared NFS mounts—becomes unreachable. By the time you realize the extent of the outage, recovery becomes the executive team’s problem. [Azure NetApp Files](https://learn.microsoft.com/en-us/azure/azure-netapp-files/azure-netapp-files-introduction) cross-zone replication (CZR) addresses this precise failure scenario. It asynchronously replicates volumes between availability zones within the same Azure region. When a zone fails, you fail over to the replica. No data loss beyond your recovery point objective (RPO), and—critically—no network transfer fees. ## What Cross-Zone Replication Actually Does Cross-zone replication creates a read-only copy of your source volume in a different availability zone. Azure availability zones are physically separate datacenters within a single region, each with independent power, cooling, and networking. If Zone 1 experiences a catastrophic failure, your replica in Zone 2 remains operational. The replication uses [NetApp SnapMirror technology](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-region-replication-introduction), which transfers only changed blocks rather than entire files. This block-level approach minimizes bandwidth consumption and shortens replication windows. The destination volume stays read-only until you break the replication relationship during a failover. | **Feature** | **Cross-Zone Replication** | **Cross-Region Replication** | | --- | --- | --- | | Scope | Same region, different zones | Different Azure regions | | Network Transfer Cost | None | Per-GiB charge | | Primary Use Case | High availability against zonal failures | Geographic disaster recovery | | Latency | Lower (intra-region) | Higher (inter-region) | Cross-zone replication provides the middle ground between local redundancy and full regional failover. You protect against datacenter-level disasters without incurring the bandwidth costs of [cross-region replication](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-region-replication-introduction). * * * **_Pro Tip: The “Zone 1” you select in the Azure Portal is a logical identifier, not a physical location. Azure maps logical zones to physical datacenters dynamically for each subscription. This prevents customers from clustering resources in the same physical zone by accident._** * * * ## Prerequisites Before configuring cross-zone replication, verify your environment meets these requirements: **Feature registration**: The Availability Zone Volume Placement feature must be registered in your subscription. Register it via Azure CLI: ```bash az feature register --namespace Microsoft.NetApp --name ANFAvailabilityZone ``` Check registration status: ```bash az feature show --namespace Microsoft.NetApp --name ANFAvailabilityZone ``` Wait until the status shows `Registered` before proceeding. This typically takes a few minutes. **Regional support**: Not all Azure regions support availability zones. Verify your target region has multiple zones with Azure NetApp Files available. Check the [Azure NetApp Files regional availability](https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region/?products=netapp) page. **Azure NetApp Files account and capacity pool**: You need an existing NetApp account and at least one capacity pool in the source zone. If you haven’t created these yet, follow the [Azure NetApp Files quickstart](https://learn.microsoft.com/en-us/azure/azure-netapp-files/azure-netapp-files-quickstart-set-up-account-create-volumes). **Delegated subnets**: Each availability zone requires a delegated subnet for Azure NetApp Files. The destination subnet must have sufficient free IP addresses. For NFS and SMB volumes, plan for at least four IPs per volume. **Protocol-specific requirements**: * **SMB volumes**: Both source and destination NetApp accounts require Active Directory connections. The destination AD connection must have DNS reachability to domain controllers from the delegated subnet. * **Dual-protocol volumes**: You must authorize replication before the initial baseline transfer begins. ## Create the Source Volume Your source volume lives in the primary availability zone and contains the production data you want to replicate. Getting the parameters right here saves you from recreating the volume later—and yes, that happens more often than anyone admits. Create the volume using Azure CLI: ```bash az netappfiles volume create \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name sourceVolume \ --location eastus \ --service-level Premium \ --usage-threshold 1024 \ --protocol-types NFSv3 \ --subnet-id "/subscriptions//resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/mySubnet-zone1" \ --zone 1 ``` Key parameters: * `--zone 1`: Places the volume in availability zone 1. This is a logical zone identifier. * `--service-level Premium`: Determines the [performance tier](https://learn.microsoft.com/en-us/azure/azure-netapp-files/azure-netapp-files-service-levels). Choose Standard, Premium, or Ultra based on your workload requirements. * `--protocol-types NFSv3`: Specifies the file protocol. Use `CIFS` for SMB or include both for dual-protocol. * * * **_Reality Check: If a zone appears grayed out or unavailable in the Portal, it means Azure NetApp Files doesn’t have capacity provisioned in that zone for your subscription. Open a support ticket to request capacity._** * * * Verify the volume was created: ```bash az netappfiles volume show \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name sourceVolume ``` Note the `id` field in the output. You’ll need this resource ID when creating the replication relationship. ## Configure the Destination Volume The destination volume acts as your replication target. It must reside in a different availability zone within the same region. Think of this as your insurance policy—you’re paying for capacity you hope you never need to activate. Create the destination volume with [replication configuration](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-zone-replication-requirements-considerations): ```bash az netappfiles volume create \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name destinationVolume \ --location eastus \ --service-level Premium \ --usage-threshold 1024 \ --protocol-types NFSv3 \ --subnet-id "/subscriptions//resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/mySubnet-zone2" \ --zone 2 \ --replication-schedule _10minutely \ --remote-volume-resource-id "/subscriptions//resourceGroups/myResourceGroup/providers/Microsoft.NetApp/netAppAccounts/myNetAppAccount/capacityPools/myCapacityPool/volumes/sourceVolume" ``` Critical parameters: * `--zone 2`: Places the volume in a different zone than the source. * `--replication-schedule _10minutely`: Sets the replication frequency. Options include `_10minutely`, `hourly`, and `daily`. * `--remote-volume-resource-id`: The full resource ID of the source volume. | **Schedule** | **Typical RPO** | **Notes** | | --- | --- | --- | | 10 minutes | < 20 minutes | Tightest synchronization. Not supported for [Large Volumes](https://learn.microsoft.com/en-us/azure/azure-netapp-files/large-volumes-requirements-considerations) (> 50 TiB). | | Hourly | < 2 hours | Standard balance for critical workloads. | | Daily | < 2 days | Suitable for static datasets or archival data. | The 10-minute schedule offers the lowest RPO but requires sufficient bandwidth to transfer all changed blocks within the window. For volumes with high change rates or large sizes, consider hourly replication to avoid replication lag. Check replication status: ```bash az netappfiles volume replication status \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name destinationVolume ``` Initial status shows `Uninitialised`. After the baseline transfer completes, status changes to `Mirrored`. * * * **_Key Insight: The destination volume remains read-only while replication is active. You cannot mount it for writes until you break the replication relationship during failover. This prevents split-brain scenarios where both volumes accept writes simultaneously._** * * * ## Monitor Replication Health You don’t want to discover your replication is broken during the outage that makes you need it. Regular monitoring ensures the relationship stays healthy and your data remains protected. Check the replication relationship: ```bash az netappfiles volume replication status \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name destinationVolume \ --query "{status:mirrorState, lagTime:lagTime, lastTransferSize:lastTransferSize}" ``` Expected output: ```json { "status": "Mirrored", "lagTime": "00:05:23", "lastTransferSize": 1048576 } ``` | **Metric** | **Healthy Value** | **What It Tells You** | | --- | --- | --- | | `mirrorState` | `Mirrored` | Replication is active and current. Other states: `Uninitialised`, `Broken`, `Uninitialized`. | | `lagTime` | Below your target RPO | Time since the source’s last write was replicated. If this creeps up, you’re losing protection. | | `lastTransferSize` | Varies | Bytes transferred in the most recent update. Spikes mean high change rates on your source. | If `mirrorState` shows anything other than `Mirrored` during steady state, investigate immediately. Don’t wait for the next business day—replication lag during a zone failure means data loss. Common causes include network connectivity issues, insufficient bandwidth, or the source volume exceeding 95% capacity utilization. The [replication health monitoring documentation](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-region-replication-display-health-status) covers additional diagnostic steps. ## Test Failover Testing failover validates your disaster recovery procedures before an actual zone failure. This step confirms the destination volume contains usable data and your mount procedures work correctly. If you skip this, you’re trusting that everything works without evidence—and that trust has a shelf life. Break the replication relationship to activate the destination volume: ```bash az netappfiles volume replication suspend \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name destinationVolume ``` This command stops replication and converts the destination volume from read-only to read-write. The operation completes in approximately one minute. Verify the volume is now writable: ```bash az netappfiles volume show \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name destinationVolume \ --query "{name:name, provisioningState:provisioningState}" ``` Mount the destination volume from a virtual machine in Zone 2: ```bash sudo mkdir -p /mnt/anf-destination sudo mount -t nfs -o rw,hard,rsize=1048576,wsize=1048576,vers=3 10.0.2.4:/destinationVolume /mnt/anf-destination ``` Replace `10.0.2.4` with the actual mount IP address from the volume’s properties. You can retrieve it with `az netappfiles volume show` and check the `mountTargets` array in the output. Write a test file to confirm write access: ``` echo "Failover test $(date)" | sudo tee /mnt/anf-destination/test.txt cat /mnt/anf-destination/test.txt ``` If the write succeeds, your failover procedures work. Document the exact steps and timing for your [disaster recovery runbook](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-region-replication-manage-disaster-recovery). * * * **_Warning: Breaking replication during a test requires manual resynchronization to resume protection. Plan your tests during maintenance windows to avoid leaving volumes unprotected._** * * * ## Resume Replication After Testing Your volumes are sitting unprotected right now. The longer you wait to resume replication, the bigger your exposure window. Don’t let this step slide to “after lunch.” Resync the volumes: ```bash az netappfiles volume replication resume \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name destinationVolume ``` This command performs a [reverse resync](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-region-replication-manage-disaster-recovery), making the destination volume read-only again and resuming scheduled replication. Changed blocks are transferred back to align with the source. Verify replication has resumed: ```bash az netappfiles volume replication status \ --resource-group myResourceGroup \ --account-name myNetAppAccount \ --pool-name myCapacityPool \ --name destinationVolume ``` Wait until `mirrorState` returns to `Mirrored` before considering your volumes protected again. If the resync takes longer than expected, check whether the test writes added significant data that needs to be reconciled. ## Cost Implications One of the defining advantages of cross-zone replication over cross-region replication is the [absence of network transfer fees](https://learn.microsoft.com/en-us/azure/azure-netapp-files/azure-netapp-files-cost-model). Data replication between availability zones within the same region incurs no bandwidth charges. **What you pay for**: * Provisioned capacity of the destination volume, based on the capacity pool tier (Standard, Premium, Ultra). * Storage snapshots retained on the destination volume beyond the automatic SnapMirror snapshots. **What you don’t pay for**: * Data transfer between zones. * Replication operations themselves. You can optimize costs by placing the destination volume in a lower-tier capacity pool. For example, replicate from a Premium pool in Zone 1 to a Standard pool in Zone 2. During normal operation, the Standard tier provides sufficient performance for replication. If you fail over, you can migrate the volume to a Premium pool in Zone 2 for production performance. ## Limitations to Understand Cross-zone replication works well for most scenarios but has specific constraints you should evaluate against your requirements. **No automatic failover**: CZR requires manual intervention to break replication and activate the destination volume. There is no automated health check or failover trigger. You must detect zone failures through your monitoring systems and execute failover commands manually. **Read-only destination**: The destination volume cannot be used for production reads or writes while replication is active. Some disaster recovery strategies rely on active-active configurations or read replicas. CZR supports neither. **Large Volume schedule restrictions**: Volumes between 50 TiB and 1,024 TiB ([Large Volumes](https://learn.microsoft.com/en-us/azure/azure-netapp-files/large-volumes-requirements-considerations)) cannot use the 10-minute replication schedule. Only hourly and daily schedules are supported due to the time required to transfer changed blocks. **Topology limitations**: [Complex replication topologies](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-zone-replication-requirements-considerations) like fan-in (multiple sources to one destination) and cascading (A → B → C) are not supported. You can replicate one source to one cross-zone destination and one cross-region destination simultaneously, but not to multiple cross-zone destinations. **Volume utilization threshold**: If a volume exceeds 95% capacity utilization, replication operations may fail. SnapMirror requires free space to process snapshots and transfer blocks. Monitor volume usage and expand capacity before hitting this threshold. ## When to Use Cross-Zone Replication Cross-zone replication is purpose-built for high availability scenarios where you need protection against zone-level failures but don’t require geographic disaster recovery. **Use CZR when**: * You need RPO under 20 minutes for file storage. * Your compliance requirements mandate data residency within a specific region. * You want to avoid the bandwidth costs of cross-region replication. * Your application can tolerate manual failover with RTO measured in minutes. **Use cross-region replication instead when**: * You need protection against total region failure (natural disaster, widespread outage). * Compliance requires data copies in multiple geographies. * Your disaster recovery plan includes geographic failover for business continuity. For workloads requiring both zonal and regional protection, Azure NetApp Files supports [cross-zone-region replication](https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-zone-region-replication-configure), which replicates one source volume to both a cross-zone destination and a cross-region destination simultaneously. ## Next Steps Cross-zone replication protects your file storage against availability zone failures with minimal cost and configuration complexity. The manual failover process requires discipline, but the absence of network transfer fees makes CZR a cost-effective high availability solution. Test your failover procedures regularly. The difference between a documented runbook and a tested runbook becomes obvious during an actual outage. Schedule quarterly failover tests, measure your actual RTO, and refine the process until it becomes routine. For SAP HANA or Oracle workloads, review the [application-specific guidance](https://learn.microsoft.com/en-us/azure/azure-netapp-files/replication) for integrating CZR with application-consistent snapshots and log backup replication. File-level replication alone doesn’t guarantee database consistency without coordinating with application quiesce operations. Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Freplicate-data-across-zones-azure-netapp-files%2F&text=Replicate%20Data%20Across%20Zones%20with%20Azure%20NetApp%20Files)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Freplicate-data-across-zones-azure-netapp-files%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Freplicate-data-across-zones-azure-netapp-files%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/2026/04/featured_image-20.webp) ### [How to Secure Azure Service Accounts with Managed Identities](/secure-azure-managed-identities/) Learn how to replace secret-based Azure service accounts with managed identities, grant least-privilege Azure RBAC access, validate token-based authentication, ![](https://adamtheautomator.com/wp-content/uploads/2026/02/featured_image-17.webp) ### [Control Traffic with Network Security Groups](/control-traffic-network-security-groups/) Create and manage Azure NSG rules, service tags, and application security groups to control inbound and outbound traffic using Azure CLI. ![](https://adamtheautomator.com/wp-content/uploads/2026/02/featured_image-12.webp) ### [Prevent Azure VM Outages with Load Balancer Health Probes](/distribute-traffic-azure-load-balancer/) Create a Standard Azure Load Balancer with the Azure CLI, configure health probes and backend pools, and distribute traffic across zone-redundant VMs. ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)