Elastic File System (EFS)
AWS's managed, elastic NFS — a shared filesystem many instances mount at once, growing and shrinking automatically, priced well above block or object storage.
What is EFS?
Amazon EFS (Elastic File System) is a managed NFS filesystem: many EC2 instances, containers, or Lambda functions mount the same filesystem simultaneously and share files with standard POSIX semantics. It grows and shrinks automatically — no capacity to provision — and spans availability zones for durability. It fills the “shared filesystem” slot that neither block storage (EBS, one-instance) nor object storage (S3, HTTP API, no filesystem) occupies.
Block vs file vs object — placing EFS
The three storage models answer different questions. Block (EBS): a raw disk attached to one instance — fast, low-latency, for databases and boot volumes, but not shareable. Object (S3): infinitely scalable HTTP-accessed blobs — cheapest, for backups, media, data lakes, static assets — but no filesystem semantics (no rename, no partial writes, no POSIX). File (EFS): a shared, mountable POSIX filesystem for multiple concurrent clients — the answer when legacy apps expect a filesystem, when content must be shared across a fleet (shared uploads, CMS media, home directories), or when containers need shared persistent volumes. EFS is the “many readers/writers need real files” tool.
The cost and performance realities
EFS is convenient and correspondingly expensive — meaningfully pricier per GB than EBS and dramatically pricier than S3 — so it’s the wrong home for data that fits object or block models. Storage classes mitigate this: lifecycle policies move infrequently-accessed files to EFS-IA (much cheaper) automatically. Performance modes matter: throughput scales with stored data in bursting mode (small filesystems can starve for throughput — a surprise under load), or you provision throughput independently. And NFS latency is higher than local block storage, so latency-sensitive workloads (databases) belong on EBS, not EFS.
What people get wrong
- EFS for data that fits S3 or EBS — paying a large premium for shared-filesystem semantics the workload didn’t need.
- Bursting-throughput starvation: a small EFS filesystem throttling under load because throughput scales with size.
- Databases on EFS — NFS latency makes it the wrong tool; use EBS for single-instance low-latency storage.
Primary source: Amazon EFS documentation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.