Because “my storage is highly available” shouldn’t mean “I have a spreadsheet of failover runbooks and a nervous twitch.”
Azure NetApp Files has a newly introduced Elastic zone-redundant storage service level that brings built-in multi–availability zone (multi-AZ) high availability directly into the service—so you can ride out an entire zone going offline without bolting on external replication or managing “secondary volumes” yourself.
I’ll put it like this: Elastic is for the moments when the business says “we need this file service to keep working” and you’d like your answer to be something other than nervous laughter(.
What is Elastic zone-redundant storage?
Elastic is an advanced high-availability service level designed for continuous data access with zero data loss, even if a whole Azure Availability Zone becomes unavailable.
A useful mental model:
- Classic approach: “I’ll deploy in one zone and then replicate somewhere else, manage failover, test it, maintain it…”
- Elastic approach: “The service is already multi-AZ and handles zone failure within the platform.”
Also worth noting: Microsoft’s documentation describes the Elastic service level as running on Azure infrastructure with built-in zone redundancy and low single-digit millisecond latency.
How it works (the reasonably technical bit)
Elastic uses zone-redundant architecture with synchronous replication at the file storage layer.
Writes: “two (or three) copies before I say ‘OK’”
When your application writes data, Azure NetApp Files writes the data across availability zones before acknowledging the write-back—so each zone’s copy stays identical.
Reads: “pick a home zone for performance”
You can choose a preferred (active) zone to align storage with compute and reduce read latency, while keeping seamless failover if that zone disappears for a while.
The headline benefit
It “bakes in” zone resilience so you don’t need to stitch together availability with external replication and secondary volume management.
Where it’s currently supported
At the time of writing, Microsoft lists these supported regions for Elastic zone-redundant storage: Australia East, Canada Central, Central US, South Central US, West Europe, West US 3.
Also: some regions may only have two availability zones available for this feature, so it’s recommended to confirm what’s supported before deployment.
Getting started (high-level workflow)
1) Create a NetApp Elastic account (this is important)
Elastic requires a NetApp account explicitly designated for Elastic zone-redundant storage—and that account is only for Elastic.
2) Create an Elastic capacity pool and set zone preferences
Elastic capacity pools let you define a failover preference order (up to three zones, depending on the region).
Microsoft also calls out checking zone support using the REST API:
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.NetApp/locations/{location}/elasticRegionInfo?api-version=2025-09-01-preview
3) Create volumes (NFS or SMB) as usual
From there, it’s the familiar Azure NetApp Files experience: pick the pool, name the volume, set quota, and configure snapshot policy / advanced options as needed.
4) Tooling notes
Microsoft recommends using the latest Azure CLI / latest Az.NetAppFiles PowerShell module for Elastic-related operations.
And if you’re using custom roles with availability zones, ensure your RBAC permissions are correct to avoid portal issues.
Workloads that make Elastic feel like cheating (in a good way)
Microsoft calls out Elastic as well-suited for metadata-heavy workloads across VMs and containers, including AI, analytics, and Kubernetes/OpenShift environments, plus general file shares.
It’s also positioned for regulated/critical industries that want “always-on” storage availability without home-grown DR scripts.
Practical limits and “nerdy bits” to be aware of
A few Elastic-specific limits from Microsoft’s published resource limits include:
- Capacity pool size: 1 TiB min, 128 TiB max
- Volume size: 1 GiB min, 16 TiB max
- Volumes per pool: 50
- Snapshots per volume: 255
maxfiles (inode) planning
Elastic volumes have a default inode ceiling based on volume size; Microsoft notes each inode requires 32 KB of space, and provides example maxfiles values (e.g., 1 TiB ≈ 31.8M, 10 TiB ≈ 318.7M).
Zone resilience isn’t the same as regional DR
Elastic is about surviving a zone outage inside a region. For truly catastrophic regional scenarios, Microsoft’s broader storage guidance notes that ZRS alone might not fully protect against a regional disaster.
So for end-to-end resilience, you may still pair Elastic with a second-region strategy (for example, Azure NetApp Files supports cross-zone and cross-region replication features—depending on your requirements).
Summary
If your goal is “keep the file service online even if a whole zone goes dark”—and you want to achieve it with fewer moving parts—Azure NetApp Files Elastic zone-redundant storage is a big step forward: synchronous multi-AZ writes, preferred-zone performance alignment, and built-in failover behavior.
For more information on the Azure NetApp Files service, check out the What’s new in Azure NetApp Files page.