Amazon FSx Alternatives for Multi-Cloud Teams

Amazon FSx does its job well. Whether you're running FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP, or FSx for OpenZFS, each one is built with a specific workload in mind and handles it with the kind of polish you'd expect from AWS. Windows File Server covers enterprise SMB file shares. Lustre is tuned for HPC and ML training. ONTAP and OpenZFS round out the family for teams that want those specific feature sets. None of that is in question.

What is in question: every single one of those four services only runs inside AWS. Any FSx variant pins the file system to AWS regions by design. A configuration choice can't change this; it's baked into how the service works. A team can tune throughput, adjust capacity, and switch deployment types, but none of it moves the file system an inch outside AWS's walls.

AWS has actually sharpened this tension internally. Amazon S3 Files went generally available in April 2026, and it mounts S3 buckets as NFS. The pricing splits the underlying storage at S3 rates from separate S3 Files cache and data-access charges, a different structure than the throughput-based pricing EFS uses. That gives AWS-only teams a real decision to make between S3 Files, EFS, and FSx for Lustre, since the cost gap between FSx for Lustre and S3 Files is large enough to matter for budgets.

But notice what all three of those options have in common: S3 Files, EFS, and FSx for Lustre all stop at the AWS perimeter. None of them help a team whose compute needs to move to Google Cloud, Azure, CoreWeave, or anywhere else. Optimizing which AWS storage product to use is a real optimization, but it answers the wrong question for a team whose problem is that storage doesn't travel with the workload. That's the question this article actually sets out to answer.

Multi-cloud is now the operational default

Running workloads across more than one cloud is now where most teams already live, not a forward-looking strategy. Enterprises spread workloads across providers so GPU capacity on one cloud running short doesn't strand them, so they can meet data residency and sovereignty rules that vary by country, so egress costs don't spiral, and so they stay flexible as accelerator hardware roadmaps shift between vendors.

A widely cited figure puts 70% of enterprises running workloads across two or more cloud providers in 2025. Most of those organizations are managing each cloud environment separately, with its own tools and its own processes, rarely talking to the others. FSx doesn't cause that fragmentation, but it reinforces the same silos by keeping storage locked to one of the clouds in that mix.

When storage lives only in AWS but compute needs to run wherever GPUs, pricing, or policy point, storage ends up deciding where workloads are allowed to run, which is backwards. Compute placement should follow policy, price, and GPU availability, not whichever cloud happens to be holding the data. Portable storage has stopped being a nice-to-have for most teams and is now the thing standing between a team and its own flexibility.

What a genuinely cloud-agnostic storage layer requires

Calling something "multi-cloud" because it happens to install on more than one cloud sets a low bar. If moving a workload from AWS to GCP still means a migration project, an ETL pipeline, and a round of code changes, that storage layer is cloud-portable with extra steps, not cloud-agnostic. The real test is simpler: does the same mount point behave identically no matter which cloud it's sitting on?

Four requirements fall out of that test. First, mount behavior has to be identical across AWS, GCP, Azure, and on-premises systems, with the same semantics and the same interface, and no per-cloud SDK or client library to install and maintain. Second, the storage needs an S3-compatible API, because that interface is now what AI frameworks and data science tooling expect. An option that can't speak S3-compatible hits an adoption wall immediately, regardless of how good it is underneath.

Third, it needs full POSIX semantics: atomic rename, file locking, mmap, hard links, symlinks, sparse files, the whole list. This is what separates genuine portability from a workaround held together with custom SDKs. When a serverless filesystem layer mounts existing cloud buckets as a real filesystem, teams get this by default, so code written years ago keeps running unmodified no matter which cloud now hosts the data behind it. Archil is one example of a product built this way.

Fourth, egress costs can't turn into a new trap. If reading data across cloud boundaries racks up punishing egress fees, a team hasn't escaped lock-in; it has just moved it somewhere else with a different invoice.

For AI and ML teams specifically, there's a fifth requirement riding alongside the first four: sub-millisecond latency at scale. GPU clusters are expensive to run and expensive to leave idle. When metadata lookups or data ingestion lag, GPUs sit there waiting instead of training, and that idle time is the real cost of picking the wrong storage layer. Everything else in this article gets measured against these five requirements.

The alternatives, evaluated on portability and performance

The field splits cleanly into two camps. One camp abstracts storage above any single cloud, so you get the same interface no matter where you run compute. The other camp replaces AWS lock-in with a different vendor's lock-in, which might still be a reasonable trade for some teams, but it's a different trade than true portability.

Archil sits in the first camp. It mounts directly against an existing S3, GCS, R2, or Azure Blob bucket as a real POSIX filesystem, with no migration, no ETL step, and no code changes needed to get started. The bucket stays the source of truth throughout, and access can be revoked at any time, so nothing about adopting it requires handing over permanent custody of the data. Reads come from a centralized caching layer at sub-millisecond latency; on a cache miss, data gets pulled from the source bucket and cached for next time, while writes replicate before confirming and flush to the bucket asynchronously afterward. Because Archil never holds a persistent copy of data outside the customer's own account, residency stays under the customer's control, with cache nodes co-located near compute and no cross-region movement happening unless someone configures it that way. Alongside the filesystem, Archil runs serverless execution, letting an agent run commands directly against the filesystem without managing a separate sandbox, which keeps context persistent across sessions and across parallel runs. Capacity is billed on what's actively cached rather than provisioned ahead of time, so a fine-tuning job that needs 1 MB of active cache costs like 1 MB, and one that needs 1 GB costs like 1 GB. The result: a team can run training on CoreWeave one week and shift the same job to GCP the next, without touching a single storage setting, because the mount behaves the same against any supported bucket regardless of which cloud is underneath it.

NetApp Cloud Volumes ONTAP takes a different approach. It delivers block and file storage with multicloud mobility across AWS, Azure, and Google Cloud, managed centrally through the NetApp Console. Rather than abstracting storage above the clouds, ONTAP runs natively on each one. NetApp has also leaned into deepening FSx itself: in December 2025 it announced S3 Access Points for FSx for NetApp ONTAP, letting AWS AI and analytics services reach NetApp file data directly without relocating it, and it launched the AI Data Engine with NVIDIA, a unified AI data platform with a global metadata catalog for finding and preparing data for production AI workloads. ONTAP has to be deployed and managed separately on each cloud, so operational work scales up with every cloud added, and it's more portable than FSx, but a sophisticated buyer should expect some integration effort at each boundary rather than true drop-in portability.

Nasuni builds around a global file system model, combining edge appliances and caching on top of object storage, spanning Azure, AWS, Google Cloud, Oracle Cloud Infrastructure, and on-premises object stores. Its orchestration and caching reduce egress fees and local storage footprint, and the whole design assumes multi-cloud from the start rather than bolting it on later. It fits distributed file collaboration, think branch offices or creative teams sharing assets, better than it fits high-throughput AI training, because the global file system model wasn't built to feed GPUs at sub-millisecond speed.

CTERA takes a governance-first angle. Its Cloud Storage Routing feature applies policy-based rules to send file data to different cloud providers, on-premises object stores, regions, and buckets, with control fine enough to set by tenant, user, or individual directory. CTERA Zones let enterprises split their global file system by geography or department. Multi-cloud flexibility comes along with that design, but compliance and governance drive it, not AI throughput.

CoreWeave AI Object Storage, launched at NVIDIA GTC, is S3-compatible and built for GPU-intensive training at exabyte scale. Its Local Object Transport Accelerator, or LOTA, caches frequently used datasets and stages them directly onto the local NVMe disks of GPU nodes, cutting network latency during training. In April 2026, CoreWeave rolled out LOTA Cross-Cloud in limited availability, extending that caching across Google Cloud and other providers without transaction or egress fees. It's a meaningful step toward portability, but the object storage stays tightly bound to CoreWeave's own GPU infrastructure, and teams whose primary compute lives elsewhere will still feel some of that coupling.

Azure Files rounds out the comparison as the direct Azure-native equivalent of FSx for Windows File Server. It's a fully managed SMB file share mountable from Windows, macOS, and Linux at once, and G2 reviewers rate it easier to set up and better at meeting requirements than FSx for Windows File Server, though pricier. Azure Files is Azure-native, full stop, and doesn't extend to other clouds, so choosing it means trading AWS lock-in for Azure lock-in, a sensible move only for a team that has already decided Azure is its long-term home.

The Atlassian case: a working multi-cloud storage pattern

A CNCF write-up from September 2026 describes how Atlassian built shared storage for its ML platform, which supports training and inference behind product features like search and ranking. As Atlassian's models grew into the tens of billions of parameters, the team needed storage that behaved reliably and repeatably without forcing ML engineers to become infrastructure experts on the side.

Atlassian's answer was a Lustre integration exposed through a CSI driver as an ordinary ReadWriteMany PersistentVolumeClaim. The filesystem mounted at the same path in every worker pod, with per-namespace and per-job subdirectories handling isolation between teams and jobs. No matter which compute nodes picked up a given job, the storage interface looked exactly the same to it.

Performance data from the same environment shows how much that consistency mattered. When a multi-node fine-tuning run fell back to TCP, it ran at roughly half the throughput of the same hardware running RDMA. That gap came entirely from the storage and network path, not from the GPUs themselves, which sat there burning expensive compute time regardless of whether the data feeding them arrived fast enough to use it.

What Atlassian picked matters less than the pattern it followed. Storage acted as a stable, compute-agnostic layer: the mount path stayed constant no matter which node or cloud happened to run the job, and the only variable that mattered for performance was how well the storage layer kept GPUs fed. You can carry that pattern into any multi-cloud storage decision, regardless of which product ends up underneath it.

Which teams should leave FSx

FSx earns its keep for teams that are fully committed to AWS and have no near-term plans to change that. FSx for Lustre, specifically, remains a strong fit for HPC or ML training workloads that need the Lustre protocol's parallel striping across multiple storage servers and direct S3 integration for importing data. Within AWS's own walls, FSx for Lustre delivers the sub-millisecond latencies that HPC and ML training both depend on. FSx for Windows File Server holds up just as well for teams running pure Windows SMB workloads anchored to AWS, since it plugs into Active Directory and existing enterprise tooling in ways a cloud-agnostic layer isn't built to replicate.

The calculus changes the moment a team's compute starts crossing cloud boundaries. Teams splitting training runs between AWS and neoclouds like CoreWeave or Lambda, because GPU availability or pricing makes that the smart move, run into an immediate problem with AWS-only storage: data has to be downloaded before training can even start somewhere else. That download step costs time and money, and it reintroduces exactly the kind of friction a multi-cloud strategy was supposed to eliminate. Teams with data residency requirements spanning jurisdictions that AWS's regions don't cleanly cover face a similar wall, because FSx's region-bound design wasn't built for that kind of flexibility.

For those teams, the decision isn't really about which FSx variant to pick or how to tune it further, but whether storage should be allowed to dictate where compute runs. A storage layer that mounts the same way against S3-compatible buckets on any cloud removes that constraint, so compute can go wherever policy, price, and GPU availability point.