Right, so you’ve decided you need a proper filesystem in AWS, not just the “it’s fine, I guess” of EFS. Good choice. But now you’re staring at the FSx menu, and it’s less “choose your fighter” and more “choose your very specific, expensive, and slightly confusing fighter.” Let’s demystify the two options that look the most like the filesystems you’d run on-prem: FSx for NetApp ONTAP and FSx for OpenZFS.

The first thing to wrap your head around is that both of these are emulations. AWS isn’t handing you a physical NetApp filer or a bare-metal ZFS server. They’re running the real ONTAP or OpenZFS software on their own hypervisor. This is why the performance is so predictable and why they can nail the compatibility—it’s the actual code, just virtualized. The upside is you get all the enterprise-grade features without the capital expenditure and the 3 AM support calls. The downside is, well, it’s not cheap. You’re paying for that privilege.

The ONTAP Power Play

Think of FSx for ONTAP as the enterprise heavyweight. It’s for when you need every single feature under the sun: multi-protocol access (NFS, SMB, iSCSI), insane efficiency through block-level deduplication and compression, and rock-solid snapshots that don’t murder your performance.

Its secret weapon is the concept of storage virtual machines (SVMs) and FlexVol volumes. You create one SVM (which gets its own endpoints and security style), and inside it, you can spin up dozens of volumes. The magic is that these volumes all share the underlying pool of provisioned throughput capacity (MB/s) and IOPS. Need a new project volume? Whip one up in seconds; it doesn’t need its own provisioned capacity. It’s brilliantly efficient.

Here’s how you’d create one with the AWS CLI. Notice how you’re provisioning the aggregate capacity and throughput, not per-volume.

# Create the FSx for ONTAP file system
# You're provisioning the whole SVM's performance cap here
aws fsx create-file-system \
    --file-system-type ONTAP \
    --storage-capacity 1024 \          # 1 TiB of SSD storage
    --throughput-capacity 256 \        # 256 MB/s of throughput
    --subnet-ids subnet-12345678 \
    --ontap-configuration DeploymentType=SINGLE_AZ

Now, create a volume inside that SVM. See? No throughput or IOPS specified here. It just lives within the limits of its parent.

# Create a volume within the SVM
aws fsx create-volume \
    --volume-type ONTAP \
    --name my-project-data \
    --client-configuration JunctionPath=/my-project,SecurityStyle=UNIX \
    --ontology-configuration StorageVirtualMachineId=svm-1234567890abcdef0 \
    --size 100 \                      # 100 GiB

The JunctionPath is key—that’s the mount path you’ll use on your Linux clients. To mount it, you’d point directly at the SVM’s DNS name and the junction path:

# Mounting an ONTAP volume
sudo mount -t nfs svm-1234567890abcdef0.fs-12345678.fsx.us-east-1.amazonaws.com:/my-project /mnt/myfs

Pitfall Alert: The default security style is mixed, which can cause permission nightmares on Linux. If it’s a Linux-only volume, set SecurityStyle=UNIX from the get-go. Trust me on this.

The OpenZFS Simplicity

FSx for OpenZFS is a different beast. It’s the straightforward, “I know exactly what I’m getting” option. You’re getting a single ZFS filesystem. Not an SVM full of volumes, just one filesystem per deployment. You provision IOPS and storage directly for it. It’s simpler, but that means if you need multiple volumes, you’re deploying multiple (and paying for multiple) filesystems.

Where it shines is raw performance for workloads that need it, native ZFS snapshots, and its clone functionality. If you have a workload that needs to be blisteringly fast and you don’t need the multi-protocol gymnastics of ONTAP, this is your pick.

Creating one is a more direct affair. You’re defining the storage and performance for this one filesystem.

# Create an FSx for OpenZFS file system
aws fsx create-file-system \
    --file-system-type OPENZFS \
    --storage-capacity 500 \           # 500 GiB
    --throughput-capacity 512 \        # 512 MB/s (or you can provision IOPS instead)
    --subnet-ids subnet-12345678 \
    --open-zfs-configuration DeploymentType=SINGLE_AZ

Mounting is just as simple, as you’re mounting the root of the entire ZFS pool.

# Mounting an OpenZFS volume
sudo mount -t nfs fs-12345678.fsx.us-east-1.amazonaws.com:/fsx /mnt/myfs

Best Practice: Use the -o noresvport mount option. It fixes a stubborn NFS client issue that can cause random transport failures. It’s a lifesaver.

sudo mount -t nfs -o noresvport fs-12345678.fsx.us-east-1.amazonaws.com:/fsx /mnt/myfs

So, Which One Do You Pick?

This isn’t a coin toss. It’s a decision tree.

  • Choose ONTAP if: You need multi-protocol access (Windows and Linux clients), want to create many volumes without multiplying cost, or need insane storage efficiency via dedupe/compression for things like VM stores or developer workspaces.
  • Choose OpenZFS if: You need the absolute lowest latency for a high-performance computing (HPC) workload, you’re deeply familiar with ZFS and want its specific snapshot/clone semantics, or your needs are simple and single-volume.

Both services integrate beautifully with DataSync for migrating data in and out, and both back up to S3 automatically via their native snapshot systems. The cost is significant, but you’re paying for managed service that removes a massive operational burden. Just don’t walk in expecting it to be as cheap as an EBS volume. You’re not paying for raw disk; you’re paying for the decades of filesystem engineering that sits on top of it.