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.
Last reviewed: July 25, 2026
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
EFS’s Elastic, Pay-for-What-You-Use Model
Unlike block storage volumes, which require pre-provisioning a specific capacity that can be resized but doesn’t automatically shrink, EFS grows and shrinks automatically as files are added and removed, with billing based on actual storage consumed at any given time rather than a pre-allocated capacity — eliminating the need to guess future storage requirements upfront or manage capacity expansion as usage grows. This elastic model, combined with EFS’s ability to be mounted simultaneously by many EC2 instances or containers across multiple availability zones, makes it particularly well suited to workloads needing genuinely shared file access — content management systems, shared application configuration, or home directories in a multi-server environment — where block storage’s single-attachment limitation would require a completely different, more complex architecture to achieve the same shared access.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.