Azure NetApp Files Breakthrough Mode GA: 80 GiB/s, Six Endpoints and Setup Limits

What actually went GA​

Microsoft's "What's new in Azure NetApp Files" changelog confirms the change and states its scope. It says breakthrough mode is now generally available (GA) in Azure NetApp Files regions where dedicated capacity is ordered and provisioned for you. That limit is the most important detail in the release. This is not a checkbox that turns on in every NetApp account in every region. GA applies where Microsoft has provisioned dedicated backend capacity for you.

The changelog describes the design this way: by leveraging six parallel storage endpoints on dedicated capacity, breakthrough mode can deliver up to 80 GiB/s throughput per volume while supporting petabyte-scale datasets and billions of files. Microsoft lists the target workloads as high-performance computing (HPC), electronic design automation (EDA), AI/ML data pipelines, and other metadata-intensive workloads requiring predictable, isolated performance at scale.

Summary: the feature is production-ready, but only in regions where dedicated capacity has been ordered and provisioned for you. It uses six parallel endpoints and Microsoft advertises up to 80 GiB/s per volume.

What changed between preview and GA​

The published throughput ceiling went up. When the preview arrived in November 2025, the Azure Updates text (preserved by the Azure Aggregator archive) said breakthrough mode supports large volumes up to 2PiB, delivering throughput up to 50GiBps, depending on workload characteristics. The GA changelog now says up to 80 GiB/s.

Microsoft's EDA solutions page on Microsoft Learn, updated September 24, 2026, has a table comparing a single breakthrough-mode volume in preview and at GA:

These figures come from an EDA benchmark in Microsoft's own test setup. They are not an SLA. The same Learn page lists breakthrough mode's headline traits as volumes up to 2 PiB, up to 80 GiB/s from one volume, up to about 2 million operations per second, and consistently sub-millisecond latency under load.

The preview-era numbers have independent backing. A SPECstorage Solution 2020 EDA_BLENDED result filed by Microsoft and NetApp, tested in January 2026, reports 2,880 Job_Sets, 1,296,040 ops/sec, 20,910 MB/s, and an overall response time of 0.51 ms. The disclosure shows twelve RHEL 9.5 clients on Standard_D32_v5 VMs in Germany West Central, spread round-robin across the volume's six endpoints (two clients per endpoint). Latency at the top load point was 1.561 ms. That per-point figure is different from the 0.51 ms overall response-time metric, and it's easy to mix the two up. Separately, Aung Oo, Microsoft's Vice President of Azure Storage, wrote on the Azure Blog that a scaled breakthrough-mode configuration reached 17,280 EDA_BLENDED jobs at a 0.60 ms overall response time.

Summary: the advertised ceiling rose from 50 to 80 GiB/s, and Microsoft's single-volume EDA benchmark nearly doubled from preview to GA. Treat all of these as tested configurations, not guarantees.

Why six endpoints matter​

A standard ANF large volume presents one storage endpoint. Enough clients hitting that single mount target will eventually hit its ceiling. Microsoft's large volumes overview describes breakthrough mode as leveraging six storage endpoints on dedicated capacity to deliver high-performance, low-latency access with high concurrency data paths for large-scale workloads, like HPC/EDA. The same page says a large volume can deliver two to three times higher performance at scale than a regular volume, while breakthrough mode achieves up to eight times the performance of a regular volume.

In practice, you get six mount targets for one namespace. That removes the usual workaround of splitting one hot dataset across several volumes and teaching your scheduler which job mounts which share. Microsoft's EDA guidance recommends breakthrough mode for:

• Large-scale regression testing with thousands of concurrent simulation jobs
• Workloads with very high file counts and heavy metadata churn
• Single-namespace deployments where spreading data across many volumes adds operational complexity
• High-performance workloads that need predictable throughput and latency at scale

Here's my analysis. There's a catch the marketing doesn't stress: you still have to distribute clients across the six endpoints. In the SPEC test, each client mounted one endpoint and clients were assigned round-robin. If your whole compute fleet mounts the first IP address it finds, you get far less benefit.

Summary: breakthrough mode gives one namespace six parallel data paths. You only get the benefit if clients are actually spread across those paths.

Requirements and limitations to check first​

The current Microsoft Learn requirements page for ANF large volumes (last updated September 17, 2026) lists these breakthrough-mode rules:

• Size range: 2,400 GiB up to 2,400 TiB (2 PiB). That's much smaller than the 50 TiB minimum for standard large volumes, so smaller hot datasets can qualify.
• Throughput: up to 80 GiB/s, depending on workload characteristics and system placement.
• Service levels: Flexible, Standard, Premium, and Ultra.
• No migration assistant: the ANF migration assistant isn't supported for breakthrough-mode large volumes, so plan data movement another way.
• Cool access afterward only: cool access can only be enabled after the breakthrough-mode volume is created.
• Snapshot restore limit: you can't restore a snapshot from a breakthrough-mode large volume to a new volume. Check your recovery runbooks before you rely on it.
• General large-volume rules still apply: a regular volume can't be converted to a large volume, and Microsoft says large volumes currently aren't suited for database data and log volumes such as SAP HANA, Oracle, or SQL Server.

The EDA page also warns that availability depends on backend storage capacity and region. Customers planning breakthrough mode should contact their Microsoft account team or ANF support early to confirm feasibility and timelines. Given that the GA wording is tied to provisioned dedicated capacity, start that conversation before you promise anything to your chip designers.

Summary: check the size range, the lack of migration assistant support, the snapshot restore limit, and the database guidance before you commit.

Onboarding: where the docs disagree​

The documentation is currently out of sync. The GA changelog is live, but some indexed copies of the requirements page and the What's new page still say Large volumes breakthrough mode is currently in preview. The Learn page updated on September 17 has already dropped that preview line and raised the ceiling to 80 GiB/s. It still says you must request the feature before first use, and its registration section still tells you to submit a waitlist request.

What Microsoft documents today:

1. Request access to breakthrough mode through the request process on the Learn requirements page (currently labeled a waitlist). Expect this to be tied to dedicated-capacity provisioning under GA.
2. Check registration with Azure PowerShell:
   Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFBreakthroughMode
   The Azure CLI az feature show command also shows registration status. The page says to wait for the state to change from Registering to Registered.
3. Create the volume. The Microsoft/NetApp SPEC disclosure shows the volume being created with az netappfiles volume create and a --breakthrough-mode true parameter, on a Flexible-tier pool with manually set throughput.
4. Mount across endpoints. Spread NFS clients across the six storage endpoints instead of pointing them all at one.

Treat the waitlist wording as possibly outdated, not as a confirmed GA requirement. No GA-specific pricing, regional rollout list, or updated onboarding form was published with the announcement. If the portal or your account team tells you something different from the docs, follow them.

Summary: registration uses the ANFBreakthroughMode feature flag. The wording around access requests hasn't been updated consistently for GA.

The tuning is part of the result​

Microsoft's EDA tests and the SPEC disclosure both used heavily tuned Linux NFSv3 clients. The mount options were nocto, actimeo=600, noatime, nconnect=8, and 256 KiB rsize/wsize, along with larger TCP buffer sysctls. Microsoft's own EDA guidance says those metadata-caching options aren't universally applicable in spirit, and warns that individual workload requirements matter. Relaxing close-to-open consistency is fine for some EDA tools and dangerous for applications that expect strict coherence. If you want numbers in the benchmark's range, you'll probably need similar tuning, and you should test whether your applications can tolerate it.

The bigger picture​

This is Microsoft competing with on-premises storage in one of the industries most reluctant to move storage to the cloud. In the Azure Blog post, Oo names AMD and ASML as production ANF users for EDA and design workloads. The Tech Community engineering write-up notes that the six-region benchmark layout was selected for resource availability reasons, which is a frank admission that capacity, not code, often sets the real limit.

So who should care? Teams whose storage is the bottleneck that keeps thousands of licensed EDA seats waiting on I/O, and HPC or AI shops tired of splitting one dataset across many volumes. Everyone else, including most file shares, VDI profiles, and database volumes, can stay on regular or standard large volumes, which Microsoft says handle most production workloads fine.

Bottom line: GA brings a higher ceiling and production support. It also depends on dedicated capacity, includes a few operational limits, and the docs are still catching up. Check your region, your recovery workflow, and your client mount layout before you plan around 80 GiB/s.