NetApp AFX: Disaggregated ONTAP for the AI Era

Applications that require high performance storage have always existed alongside those that just need more capacity than a single server can handle.  The world of machine learning and generative AI, particularly at scale, has capacity and performance needs that can exceed the capabilities of your enterprise standard storage system.  On the market, the options are seemingly endless, each providing more performance than the last. What many of them lack is interoperability with the rest of your data estate, meaning it's harder and takes longer to get data onto the AI array so you can churn through it. 

In recent years, storage systems have turned into plumbing – you need it to be there, and it must be capable, but it's invisible infrastructure.  The reality is, storage is the bedrock of your data environment. In the data totem pole, all infrastructure components are critical, but storage is the base upon which the rest stands. The capabilities of modern storage systems juggle numerous clients, myriad snapshot sets, DR replication, handling and healing from failures without loss of service all while providing hundreds of thousands of transactions per second.  In the world of AI, costly GPU-powered servers need low latency storage performance to keep them fed with data and to minimize the users' perception of processing time to keep them from losing patience which, for public-facing sites, can cause lost revenue or negative perception.

To address this need, NetApp recently released their newest ONTAP personality, AFX.  NetApp AFX is a disaggregated, all-flash storage platform, whose mission is to support the needs of high-performance data environments in both performance and scale.  Its architecture is somewhat unique for NetApp (more on this later), but its ecosystem integration has all the hallmarks of NetApp.

What "Disaggregated ONTAP" Actually Means

Before discussing hardware, it is important to establish a vocabulary distinction that NetApp is being deliberate about. There are now two ONTAP personalities in the world.

Unified ONTAP is the architecture that has powered FAS, AFF, and C-Series systems for three decades. In this model, each controller node has a fixed relationship with its own disks or, more recently, partitions. The node owns its disks/partitions, manages its own aggregate, and HA failover is handled via a direct NVRAM connection between the two nodes in an HA pair. Storage and compute scale together; when you need more throughput, you typically add nodes and capacity in tandem.

Disaggregated ONTAP breaks this coupling entirely. In AFX, every controller node sees every disk in the cluster through a shared ethernet fabric. There is no node-to-shelf ownership, no per-node aggregate, and no requirement that compute and capacity grow in lockstep. If you need more throughput, but your data volume isn't growing, you add controller nodes. If your dataset is growing but throughput is stable, you add shelves.

The name "AFX" doesn't stand for anything specific — "AF" is All Flash, and "X" refers to the visual representation of the architecture with compute nodes on top, storage nodes on the bottom, crossed in the middle by a high-speed network fabric. It's a fitting metaphor for a platform that is fundamentally about decoupling two traditionally bound things.

The Hardware Stack

Storage Controller Nodes: The AFX 1K

The AFX storage controllers are built on A1K nodes — each controller is a 2 rack unit form factor with no onboard disks. The controller nodes ship with dual 52-core CPUs and 1 TB of RAM. In a minimal 4-node configuration, the smallest supported AFX cluster, you have 416 CPU cores and 4 TB of memory available for storage processing.

Each node uses two cluster switch ports, one per switch connecting via 4x 100GbE breakout cables to each 400GbE switch port, for a total of 8x 100GbE connections per node into the backend fabric: 2 HA ports, 2 cluster network ports, and 4 storage ports. Nodes are added in pairs; single-node additions are not currently supported.

The boot media in AFX differs from unified ONTAP in an important way. Each AFX node has a local M.2 SSD for its boot media, storing boot images, core files, replicated databases, cluster configuration backups, and more. 

NX224 NVMe Storage Enclosures

The storage media layer consists of NX224 NVMe enclosures — a 2U shelf holding 24 NVMe SSDs, connected to the pair of backend switches. Shelves consume 4 switch ports each (2 per switch, 16x 100GbE ports in a 4:1 breakout configuration).

AFX supports four NVMe drive sizes: 7.6 TB, 15.3 TB, 30.7 TB, and 61.4 TB (the last added in ONTAP 9.18.1). Key purchasing constraints to know:

• Shelves are sold fully populated — no partial-shelf configurations.
• Drive sizes cannot be mixed within a single Storage Availability Zone.
• Once a shelf is added, it cannot be removed.
• For 15.3 TB drives, a single shelf is sufficient to start; all other drive types require a minimum of two shelves.
• Minimum rack footprint for a 4-node cluster with one shelf of 15.3 TB drives: 12U (8U controllers + 2U shelf + 2U switches).

The Backend Fabric: Cisco Nexus Switches

The backend network connecting all controllers to all shelves is built exclusively on Cisco Nexus switches, either the 9332D or 9364D. These are sold as part of the AFX configuration and configured using a NetApp-provided configuration file. 

The backend network carries several distinct traffic types, each isolated by VLAN: cluster database replication, node-to-shelf storage communication, HA (NVRAM/NVLOG) replication, and inter-node operations like SnapMirror. 

Client data traffic (NFS, SMB, S3) is served through dedicated front-end ports and switches. InfiniBand is not supported and is not planned; NFS over RDMA provides RDMA-level performance over standard Ethernet, making InfiniBand unnecessary.

Storage Availability Zones

If you take away one concept from this post, make it the Storage Availability Zone (SAZ). This is the mechanism that makes disaggregation work at the ONTAP level and understanding it changes how you think about almost everything else in the platform.

In unified ONTAP, capacity is organized into aggregates, each node owns its aggregate, which consists of the disks attached to that node. A volume created on Node A's aggregate can only consume capacity from Node A's aggregate. This creates implicit data silos.

In AFX, all shelves in the cluster are combined into a single Storage Availability Zone. Every controller node can read from and write to every disk in the SAZ; there is no concept of aggregate ownership. When a shelf is added, ONTAP automatically incorporates it and configures RAID group with no admin intervention required.

Capacity management is dramatically simplified. Because all nodes see all capacity, there are no per-node aggregates to monitor and balance. Additionally, you won't run out of space on one node's aggregate while another has 40 TB free. Volume thin provisioning is enabled by default; thick provisioning is not permitted in AFX because per-node aggregate domains don't exist.

Volumes automatically rebalance on cluster changes. When a node joins or leaves the cluster, ONTAP redistributes volumes automatically. In ONTAP 9.18.1, automatic performance-based rebalancing was introduced, where ONTAP monitors per-node CPU utilization and moves volumes when the utilization delta between source and destination nodes exceeds 50%, executing at most once per day.

RAID-TEC and Erasure Coding

AFX uses RAID-TEC by default, a triple-parity erasure coding scheme that protects against three simultaneous drive failures. A RAID group in AFX can contain up to 96 drives (92 data + 3 parity + 1 spare), a 3x increase over the 32-drive maximum in unified ONTAP. This larger RAID group size delivers significantly higher storage efficiency: with 92 data drives and only 4 overhead drives per RAID group, or a tick over 4%, the usable-to-raw ratio is excellent.

For the smallest configurations with 15.3 TB drives, RAID-DP (dual parity) is used initially. When a second shelf is added, ONTAP automatically converts RAID groups to RAID-TEC at a group size of 96. RAID groups are managed entirely autonomously; administrators do not configure RAID groups, assign disks, or manage rebuilds. RAID rebuilds are distributed across multiple cluster nodes simultaneously, dramatically accelerating rebuild times and reducing the post-failure risk window.

Data Protocols: File and Object Only

AFX is a NAS and object storage platform; block is not supported and there are no plans to do so. Supported protocols include SMB 2 and 3, S3, and NFSv3 through NFSv4.2. 

For AI workloads, the NFS and S3 protocol support covers essentially every pattern you will encounter: NFS for training dataset access from GPU compute, S3 for object-based data lake access and model artifact storage, and NFSv4.1 with pNFS for clients that can exploit parallelism across multiple controller nodes simultaneously.

For pNFS, each AFX controller node presents its own NFS endpoint, and pNFS-capable clients discover and connect to all available nodes, distributing I/O load across the full cluster fabric; more recent Linux distributions support the trunkdiscovery option. NetApp standard best practice is one IP address per node per protocol, so a larger AFX cluster directly translates to more parallel NFS endpoints and more aggregate bandwidth available to training jobs. Multichannel SMB in v3 operates similarly for Windows-based clients; clients will automatically find the additional paths, and multichannel is enabled by default.

NFS over RDMA is an important tool for high-performance GPU workloads. Standard NFS requires the CPU to participate in the data path; the data moves from the storage network, through the kernel, system memory, and to the GPU via PCIe. All those hops require data movement through system buffers.  RDMA allows the NIC to move data directly to/from memory without the CPU being involved.  Moving the vast volumes of data these applications require consumes a healthy amount of CPU cycles.  RDMA ultimately returns valuable CPU cycles back to the host. NFSv4.1 with RDMA transport achieves this over standard Ethernet infrastructure using RDMA-capable NICs in the clients.

Storage Efficiency in AFX

Storage efficiency features in AFX at the ONTAP 9.17.1 initial release include: FlexClone (instant space-efficient volume copies), inline volume-level deduplication and compression, and inline compaction; all are enabled by default.

One notable gap in the initial release is the absence of cross-volume (aggregate-level) deduplication. Currently (ONTAP 9.18.1), cross-volume deduplication is performed at the per-node level, bringing efficiency back to parity with unified ONTAP. Global deduplication across the entire SAZ is on NetApp's radar for the future.

Migration Paths: Getting Data to AFX

For organizations with existing NetApp infrastructure, the migration story is as good as it gets. AFX integrates with unified ONTAP environments, so SnapMirror is the primary migration mechanism. An existing AFF or FAS system running unified ONTAP can replicate volumes to AFX via standard SnapMirror relationships. SVM DR and SVM Migrate are also supported, offering additional benefits: in addition to data, they replicate the SVM configuration itself.  

For non-ONTAP source systems, file-level copy utilities are the migration path: NetApp XCP or Copy & Sync (formerly CloudSync) for fast transfers, standard tools like robocopy or rsync, or third-party solutions.

Where AFX Belongs in Your Enterprise Storage Environment

AFX is not a general-purpose storage replacement. It is a specialized platform optimized for a specific class of workloads. Being direct about fit is important here.

Primary Target: AI/ML and LLM Workloads

The primary and best-fit use case for AFX is AI/ML model training, fine-tuning, and inference at scale. The single-pool Storage Availability Zone means there are no capacity silos — every GPU-connected compute node can reach every dataset without hop penalties. Independent performance and capacity scaling means you can right-size the throughput layer for your specific GPU cluster without paying for storage capacity you don't need.

Checkpointing, which is saving model state periodically during training, is a write-intensive burst workload. A training job on a 512-GPU cluster may need to write hundreds of gigabytes in a short window every few hours. AFX's architecture, with write throughput distributed across all controller nodes and the full NVMe SSD pool, handles this without throttling the training run.

Secondary Use Cases: High-Performance NAS at Scale

Any workload that needs extreme NAS throughput, a single pool of capacity without data silos, and can use file or object protocols is a reasonable candidate. High-performance computing for scientific simulation, genomics, and financial risk modeling can take advantage of AFX's throughput and scale.

For non-AI workloads, AFX could be a fit if your application needs more performance than you can get out of a single HA pair, when you can take advantages of four or more controllers.

When Unified ONTAP Is Still the Right Answer

Unified ONTAP remains the primary storage solution for the vast majority of workloads. MetroCluster requirements point to unified ONTAP. Workloads that don't need extreme throughput, that are already running on existing hardware, or that require features not yet available in AFX, like FabricPool, belong on unified ONTAP.

A common deployment pattern we expect to see is AFX as the high-performance AI system with traditional ONTAP handling the rest of the enterprise data estate.  From there, SnapMirror feeds curated training datasets from AFF to AFX. Training jobs run against AFX. Models and artifacts move back to the AFF or object storage tier for longer-term retention. The two systems share the same ONTAP management tooling and data services as a single unified data fabric.

Management, APIs, and Tooling

Supported management tools are what you'd expect, including:

• NetApp System Manager (GUI-based management)
• NetApp Console (formerly BlueXP - centralized management plane)
• Grafana / Harvest / NAbox (metrics collection and monitoring dashboards)
• NetApp Trident v25.10 and later (Kubernetes persistent volume provisioning)
• NetApp Data Infrastructure Insights / DII (formerly Cloud Insights - observability)

REST API is the only option, in that ZAPI is not available in AFX. 

WWT's Advanced Technology Center and the AI Proving Ground

No discussion of AFX from a World Wide Technology perspective would be complete without talking about what we've built in our Advanced Technology Center, because the work we do there with AFX directly changes what's possible for customers evaluating this platform.

The ATC: Where Innovation Becomes Real

The WWT Advanced Technology Center, located at our global headquarters in St. Louis, Missouri, is one of the most comprehensive technology integration environments in the world. The ATC is purpose-built to give enterprise customers a safe space to design, test, and validate complex technology solutions.  It's a working lab where customers come to run their workloads, break things, measure results, and build confidence in architectural decisions before hardware is acquired.

The AI Proving Ground: AFX in Action

Inside the ATC is the AI Proving Ground (AIPG), WWT's dedicated AI infrastructure validation environment. The AIPG was built specifically to test and validate AI-oriented technologies in realistic production contexts with real AI workloads.

WWT's first NetApp AFX system, an 8-node configuration with 4 shelves is live and operational in the AI Proving Ground. This system was installed and configured in close collaboration with NetApp engineers, with every design decision made to maximize performance for AI workloads. The installation and commissioning process was a breeze, and within a few hours, we had a functional clustered storage system.

The ONTAP story is front and center in the AIPG deployment. The AFX runs the same ONTAP that our customers already know and trust: SnapMirror, FlexClone, FlexCache, Autonomous Ransomware Protection, and the full ONTAP data services stack are all available from day one. For customers who have invested in the NetApp data fabric, the AFX in the AIPG lets them see exactly how their existing ONTAP investments extend into the AI infrastructure layer, rather than being replaced by it.

Putting It All Together

After 30 years of ONTAP evolution, the AFX represents a significant architectural departure from the traditional ONTAP setup. Disaggregated compute and storage, the elimination of aggregates, the single storage pool, and near-instantaneous volume mobility are both evolutionary and revolutionary improvements. 

For AI and GPU-intensive workloads, the case for AFX is strong. Coupling AFX's multimode architecture with independent scaling of performance and capacity, NFS over ROMA, pNFS and nconnect for parallel multi-node access, and the ONTAP data management fabric all combine to make AFX a compelling foundation for enterprise AI infrastructure. The fact that it delivers ONTAP's three-decade data management heritage to the AI performance tier without requiring customers to start over with an unfamiliar platform, is a genuine competitive differentiation.

If that pattern describes your environment, or if you're building AI infrastructure from scratch and want to understand whether AFX belongs in the architecture, the best next step is a conversation with WWT and a session in the AI Proving Ground. The hardware is live, the workloads are running, and the results speak for themselves.

Results From Initial Testing

The WWT ATC deployment

The system is connected to high-performance GPU compute nodes in the AIPG.  Our AFX system is a production-ready, fully operational configuration, consisting of:

How we tested: methodology that reflects reality

One of the most common ways storage benchmarks mislead buyers is by testing against an empty system. An empty array always performs better than one that's been lived in, and that gap can be significant. During your time with a storage system, it's only empty on day one and never again.  WWT's testing methodology was designed to avoid exactly that.

Before any benchmark runs began, the AFX system was pre-filled to approximately 70% capacity. Tests were then executed against a working set on a separate volume. This approach ensures results reflect operating conditions that match what a real production environment looks like, not a best-case scenario empty box.

All tests were executed using elbencho, an industry-recognized open-source benchmark tool designed specifically for high-performance, distributed storage validation. Each test ran for 30 continuous minutes to capture sustained throughput, not a burst that could land solely in cache. Key metrics were collected in real time through Grafana dashboards, including:

1. Throughput (GiB/s)
2. IOPS
3. Latency
4. Storage platform power consumption
5. Client host resource utilization

The results

The AFX delivered across every test dimension, sequential write, sequential read, and random IOPS. Here are the headline numbers:

Sequential write single host

Using direct I/O across 224 threads, a single high-performance GPU host achieved a time-averaged write throughput of 57.6 GiB/s (61.8 GB/s) over the full 30-minute test window. Peak throughput reached 66.5 GiB/s (71.4 GB/s). After an initial ramp-up phase, throughput stabilized in a steady-state range of approximately 48–65 GiB/s (51.5–69.8 GB/s).

Storage platform power during write testing averaged 12.5 kW just 1.5 kW above the system's idle baseline of 11 kW. For the throughput delivered, that power profile is remarkably efficient.

Sequential read single host

Sequential read performance was even more impressive. A single GPU host achieved a time-averaged read throughput of 91.1 GiB/s (97.8 GB/s) essentially line-rate performance for the configuration, with a peak of 91.2 GiB/s. After ramp-up, throughput held in a tight band of 90–92 GiB/s with minimal variability.

Storage platform power during read testing averaged 11.2 kW, barely above idle. The AFX sustained near-maximum read throughput at baseline power draw.

Random IOPS

4K random read testing averaged 494,148 IOPS a result that demonstrates the AFX is equally capable for metadata-heavy and small-block workloads, not just the large sequential I/O typical of model training. This matters for inference workloads, data preprocessing pipelines, and environments where multiple jobs access the same storage concurrently.

Validate before you commit

WWT's AI Proving Ground exists for one reason: to let you prove technology works for your use case before you put it in production. The NetApp AFX is now part of that environment, and it's available for customer validation sessions today.

Whether you're evaluating storage for a first AI deployment, benchmarking against an existing solution, or looking to understand how the AFX fits into a broader data management strategy, our team is ready to run the tests that matter to you.

Reach out to your WWT account team to schedule a session or visit wwt.com to learn more about the AI Proving Ground.