Skip to content

SYSTEM Cited by 3 sources

Amazon FSx for NetApp ONTAP

Definition

Amazon FSx for NetApp ONTAP is a fully managed AWS storage service that provides the capabilities of NetApp's ONTAP file system as a cloud-native offering. It exposes multi-protocol access (NFS, SMB, iSCSI) and inherits ONTAP's enterprise data-management features — notably SnapMirror (cross-region asynchronous replication) and FlexClone (instant copy-on-write volume copies) — as first-class managed primitives on AWS.

Distinguished from the generic Amazon FSx umbrella by its ONTAP-specific capabilities: SnapMirror replication, FlexClone, storage virtual machines (SVMs), ONTAP CLI access, and the full ONTAP data-management stack running under AWS's managed control plane.

Key capabilities (as surfaced by ingested sources)

SnapMirror replication

Cross-region asynchronous block-level replication between FSx for NetApp ONTAP file systems. Configurable schedule (S&P Global uses 15-minute intervals). Data transferred is encrypted in transit using AES-256-GCM. See snapmirror-replication.

FlexClone technology

Instant copy-on-write volume copies from existing snapshots. Creates a writable clone in under 2 minutes that shares data blocks with the parent volume — consuming minimal additional storage. The clone operates independently of ongoing SnapMirror relationships. See flexclone-instant-volume-copy.

Security and encryption

  • Data at rest encrypted via AWS KMS keys
  • Data in transit encrypted via SMB Kerberos, NFS Kerberos, or AES-256-GCM (SnapMirror)

Production references

Oracle on Amazon EVS — NFS datastore + SnapMirror DR (2026-10-02)

An AWS Architecture Blog reference architecture uses FSx for NetApp ONTAP as the NFS-datastore storage tier for Oracle Database running on Amazon EVS (VCF 9.1 on bare metal). Several FSx-ONTAP sizing/operational facts this source canonicalises:

  • Access model = NFS datastore, not in-guest dNFS. ESXi hosts mount FSx ONTAP as NFS datastores; Oracle VMs see standard VMDKs on them. Each host has an independent NFS path to FSx ONTAP (bandwidth distributed across the cluster), deliberately bypassing the single NSX-Edge path that in-guest dNFS would force. Delivers sub-ms latency, up to 80,000 IOPS per file system, multiple GB/s throughput. FSx ONTAP also exposes NVMe over TCP alongside NFS/SMB/iSCSI.
  • Read/write throughput asymmetry (sizing trap). On a 6 GB/s file system, reads can hit 6 GB/s but writes are capped at ~1 GB/s — and that write ceiling is per HA pair. Scaling write throughput beyond one HA pair requires deploying a file system with more than one HA pair and manually distributing volumes across the additional aggregates (placement is not automatic). Size throughput capacity on the write workload.
  • 100% SSD, tiering none, 20% headroom for DB volumes. AWS recommends against capacity-pool tiering for Oracle volumes (keep tiering policy none). If the SSD tier fills, FSx ONTAP blocks writes — provision a minimum 20% free and monitor SSD utilization.
  • SnapMirror replicates data + logs + binaries cross-region; binary replication means no Oracle install is needed on recovery. Encrypted in transit via IPsec for the cross-region hop.
  • DR mount nuance (Oracle licensing). DR replica volumes are kept as data-protection (DP) volumes NOT mounted as NFS datastores until failover is declared — pre-mounting (even with no VM running) exposes Oracle binaries and may trigger Oracle licensing across the whole DR cluster. On failover: break SnapMirror → mount datastore → power on VM. See Oracle Database.

(Source: sources/2026-10-02-aws-architect-highly-available-oracle-database-on-amazon-evs-and-fsx-ontap)

Oracle on EVS — deployment runbook (CLI) (2026-10-02)

The step-by-step companion gives the operational CLI for the above architecture. FSx-ONTAP-specific procedure:

  • File system create: Single-AZ (required for EVS), SSD sized for data+logs+20% headroom, throughput 512–2,048 MB/s (sized on the write workload per the asymmetry note), IOPS automatic (3/GiB) or up to 80,000 user-provisioned. Disable FSx automatic daily backups — hand Oracle-aware scheduling to SnapCenter instead. Set the fsxadmin password and create an SVM with a vsadmin password; the security group allows NFS (TCP 2049, 111, 635) from the EVS management VLAN.
  • Volume create (over SSH to the management endpoint) — ssh fsxadmin@management-endpoint, then vol create:
vol create -volume oradb1bin  -aggregate aggr1 -size 50G  -tiering-policy none -junction-path /oradb1bin
vol create -volume oradb1data -aggregate aggr1 -size 500G -tiering-policy none -junction-path /oradb1data
vol create -volume oradb1log  -aggregate aggr1 -size 250G -tiering-policy none -junction-path /oradb1log

-tiering-policy none pins all data to the SSD tier (operational form of the 100%-SSD rule); the log volume is sized for 24 hours of archive logs. - SnapMirror DR setup (CLI): cluster peer create (intercluster IPs) → vserver peer create … -applications snapmirror → create -type DP (data-protection) volumes on the DR file system → snapmirror create -policy MirrorAllSnapshots -type DP + snapmirror initialize per volume (data / log / binary). - NFS datastore mount abstraction: ESXi hosts mount the volumes as NFS 3 datastores (svm-id.fs-id.fsx.region.amazonaws.com:/oradb1data); Oracle VMs then see VMDKs on those datastores as local XFS block devices — the guest has no NFS awareness, so no dNFS tuning and standard Oracle filesystem storage management applies. - Clean-up ordering (data-loss-safe): unmount datastores → delete SnapMirror relationships + DP volumes → delete file systems (permanent).

(Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

S&P Global Capital IQ (2026-07-07)

S&P Global's Capital IQ financial data platform uses FSx for NetApp ONTAP as the storage layer for a cross-region DR architecture spanning US-East-1 and US-West-2. A four-node geo-distributed WSFC provides the compute tier; SnapMirror at 15-minute intervals replicates to the DR region; daily-refreshed FlexClone volumes provide sub-15-minute read-only failover. The architecture delivers RPO of minutes-to-15-minutes and read-only RTO under 15 minutes for financial services regulatory compliance.

(Source: sources/2026-07-07-aws-sp-globals-disaster-recovery-fsx-netapp-ontap)

Positioning relative to other FSx variants

FSx for NetApp ONTAP is one of four FSx file-system types: - FSx for Windows File Server — SMB-only, Active Directory integration - FSx for Lustre — HPC/ML parallel file system - FSx for NetApp ONTAP — enterprise multi-protocol with ONTAP data management - FSx for OpenZFS — Linux workloads migrating from on-prem ZFS

The ONTAP variant is positioned for customers with existing NetApp workflows who want cloud-native infrastructure without losing ONTAP's mature data-management stack (snapshots, clones, replication, tiering).

Seen in

  • systems/aws-fsx — parent service family
  • systems/amazon-evs — EVS mounts FSx ONTAP as NFS datastores for Oracle VMs.
  • systems/oracle-database — the Oracle-on-EVS workload; DR-licensing shapes the SnapMirror mount runbook.
  • systems/netapp-snapcenter — the Oracle-aware control plane that schedules ONTAP snapshots + SnapMirror updates + FlexClone on this storage.
  • systems/aws-backup — complementary backup control plane (FSx coverage added by AWS Backup)
  • snapmirror-replication — the replication mechanism
  • flexclone-instant-volume-copy — the rapid-clone mechanism
  • snapshot-clone-rapid-failover — the composite DR pattern enabled by SnapMirror + FlexClone
Last updated · 854 distilled / 2,448 read