Home / Reference / FSx for ONTAP

Amazon FSx for ONTAP: ONTAP as a managed AWS service

FSx for ONTAP is Amazon's managed service that runs real ONTAP file systems in AWS — same WAFL, same SnapMirror, same CLI — with AWS taking care of the controllers. It's the most common way teams get NetApp features in the cloud without operating hardware. This guide covers what it actually is, the latency reality, and when it beats (or loses to) Azure NetApp Files.

What FSx for ONTAP is (and isn't)

Real ONTAP: each FSx for ONTAP deployment is a pair of ONTAP controllers (an HA pair) running in AWS, exposed as one or more file systems with SVMs, volumes, snapshots, SnapMirror, and all the usual ONTAP features.
Managed by AWS: you don't patch ONTAP, replace failed controllers, or manage shelves. AWS owns the lifecycle; you manage SVMs, volumes, and data.
Not your own cluster: you can't boot into node shell, and some low-level ONTAP features are restricted or handled differently. It's ONTAP with a managed-control-plane layer on top.
Access: NFS (3/4.x), SMB, iSCSI, and NVMe/TCP (on newer configurations) over the AWS VPC — no public internet path needed.

FSx for ONTAP vs on-prem ONTAP

Dimension	FSx for ONTAP	On-prem ONTAP
Controllers	AWS-managed HA pair per file system	Your hardware (AFF/FAS/ASA)
Patching/upgrades	AWS does them (maintenance windows)	You run the upgrade runbook
Performance model	SSD IOPS/throughput tiers per file system	Hardware-defined; scale-out nodes
SnapMirror	FSx→FSx (same or cross-region), FSx↔on-prem	Full SnapMirror to any ONTAP
Latency	VPC-internal is good; cross-region is the real cost	Depends on your network
Billing	Per-GiB-month + SSD tier + throughput	Hardware + support + power/space

From an admin's perspective the daily experience is nearly identical: you still create SVMs, volumes, qtrees, and snapshots with the same commands and REST API.

The region and latency reality

The classic mistake is deploying FSx for ONTAP in one AWS region and expecting low latency for users in another region or on-prem. NFS/SMB round trips are chatty; every stat and directory listing crosses the wire. Reality checks:

Same-AZ workloads: excellent latency (sub-millisecond to a few ms) — this is the sweet spot for databases, VDI, and app data.
Cross-region (e.g. us-east-1 users in EU): 60–150 ms+ round trips; fine for file sync/backup, painful for interactive NAS workloads.
On-prem → cloud: treat it as WAN storage; use it for DR, migration staging, and replication targets, not as primary NAS for on-prem users.

The standard fix for "cloud storage is slow for my users" is FlexCache at the edge: a small ONTAP FlexCache volume (on-prem or in a local region/AZ) caches hot data from the central FSx volume, serving reads locally while writes go through. See FlexGroup/FlexCache deep-dive for the mechanics.

FlexCache commands that matter here

# Create a FlexCache volume (edge cache) that fronts a remote FSx volume
volume flexcache create \
  -vserver svm_edge \
  -volume cache_vol \
  -peer-vserver svm_fsx \
  -peer-volume data_vol \
  -size 5TB

# Show cache population / hit statistics
volume flexcache show
statistics volume flexcache show

# Mount and serve it locally (export from the edge SVM)
vserver export-policy rule create \
  -vserver svm_edge -policyname default -protocol nfs \
  -clientmatch 10.0.1.0/24 -rorule any -rwrule any

FlexCache volumes are read-mostly caches: they hold a subset of the origin volume's data, evict automatically, and never become the source of truth — which makes them ideal for branch offices and cloud edge workloads.

SnapMirror with FSx for ONTAP

FSx for ONTAP participates in SnapMirror on both sides:

FSx → FSx: same-region or cross-region replication between FSx file systems; handy for DR and test/dev clones.
FSx ↔ on-prem: replicate from an on-prem ONTAP cluster into FSx (cloud DR target) or from FSx back to on-prem (migration/cold copy).
Setup: create a SnapMirror relationship via the ONTAP CLI on the FSx SVM (peer clusters/Vservers first), exactly like on-prem — see the SnapMirror troubleshooting guide.

This is the killer feature: an on-prem ONTAP shop can stand up a cloud DR copy of its volumes in minutes without re-architecting the data path.

FSx for ONTAP vs Azure NetApp Files vs Google Cloud NetApp Volumes

Service	Cloud	Notes
Amazon FSx for ONTAP	AWS	Full ONTAP; best for AWS-native + hybrid (SnapMirror to on-prem)
Azure NetApp Files (ANF)	Azure	Also real ONTAP under the hood; capacity pools, ultra/standard/premium/performance tiers; strong Azure-native integration
Google Cloud NetApp Volumes	GCP	Managed NetApp for GCP; newer and smaller footprint but same ONTAP core

All three run ONTAP underneath — the choice is mostly which cloud you're in, then tiering/performance options. If you're multi-cloud, the consistent ONTAP API and SnapMirror story are the reason to standardize on them rather than on each cloud's native file service.

When FSx for ONTAP is the right call

You run on-prem ONTAP and want a cloud DR target or test/dev environment with the same tooling.
You need NFS+SMB (dual protocol) in AWS with snapshots and efficiency features.
You want NetApp features (FlexClone, SnapMirror, FlexGroup) without operating hardware.

When it's not: when you need maximum raw performance per dollar (native AWS EFS/FSx for Lustre may win for specific workloads), or when your users are in a different region and the workload is latency-sensitive — fix that with FlexCache or region choice, not by hoping the WAN gets faster.