Free — no signup required

Introduction: The "Shared Drive" Problem

2 min read

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

This is one of 18 chapters

Get every chapter — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

See pricing