Why EBS and S3 Aren't Enough
Imagine you run a bakery with 50 employees. You have one recipe binder (EBS) that only one person can use at a time — everyone else has to wait. You also have a warehouse (S3) full of ingredient boxes, but you can't cook directly in the warehouse; you have to order items and wait for them to arrive. Neither option works when all 50 bakers need to read and write to the same recipe book simultaneously, in real time.
That's the gap AWS EFS and FSx fill: shared, concurrent file access across many servers at once.
EBS is fast block storage, but it is (mostly) restricted to a single EC2 instance at a time. You cannot attach one EBS volume to 50 web servers and have them all read and write simultaneously. S3 is globally accessible object storage, but it is not a file system. You cannot mount it as a directory, use standard file locking, or run applications that expect POSIX file semantics (like open(), read(), write(), flock()).
When you need a shared folder — one that 100 servers can read and write to simultaneously, with standard directory structures and file locking — you need Network File Storage (NAS). AWS provides this through EFS (Elastic File System) and the FSx family of managed file systems.
The Decision Framework
Before diving into each service, internalize this routing table:
| Need | Service |
|---|---|
| Linux-native shared storage (NFS) | Amazon EFS |
| Windows-native shared storage (SMB + Active Directory) | FSx for Windows File Server |
| Extreme HPC/ML throughput, S3 integration | FSx for Lustre |
| Multi-protocol (NFS + SMB + iSCSI), enterprise features | FSx for NetApp ONTAP |
| OpenZFS workloads, Linux/macOS NFS clients | FSx for OpenZFS |