Amazon EFS
Fully managed elastic NFS file system that many Linux servers can mount and share at the same time.
Verified against AWS documentation · 2026-09-09
Key facts
- 01Shared file storage — many EC2 instances, containers, and Lambda functions mount the same file system at once, across AZs (EBS attaches to one instance in one AZ)
- 02Elastic — capacity grows and shrinks automatically as files are added and deleted; nothing to provision, no minimum
- 03Regional (default, data across 3+ AZs) vs One Zone (single AZ, cheaper, data lost if that AZ is lost)
- 04Storage classes Standard → IA → Archive, moved automatically by a lifecycle policy; file metadata always stays in Standard
- 05Limits: NFS v4.0/4.1 over port 2049, Linux only (no Windows), one mount target per AZ, 47.9 TiB max file size
Exam triggers
Phrases and scenarios that point here.
- "Shared file system", "concurrent access", "multiple instances read and write the same files"
- Auto Scaling web fleet where every server must serve the same uploads directory → EFS, not one EBS volume per instance
- "Scales automatically to petabytes" / "no capacity planning" + file storage → EFS
- Lift-and-shift of a Linux app that expects a POSIX file path → EFS; rewriting it for object APIs is the wrong answer
Not this service
- Boot volume or database disk for one instance → EBS
- Windows, SMB, or Active Directory file shares → FSx for Windows File Server
- Objects fetched over HTTP APIs — static assets, backups, data lake → S3
- HPC, genomics, or ML training needing extreme parallel throughput → FSx for Lustre
Use cases
- 01WordPress or any CMS behind an Auto Scaling group — the uploads directory lives on EFS, so a newly launched instance serves the same media as the old ones with no sync step
- 02Lifting a legacy Linux app into AWS when it writes to /var/data and nobody is going to rewrite it to call S3
- 03Shared home directories and scratch space for a team of developers or data scientists spread across a fleet of EC2 instances
- 04Persistent writable state for stateless compute — ECS/Fargate tasks, EKS pods, and Lambda functions that need a large model file or dependency bundle without baking it into the image
- 05A worker fleet chewing through one directory tree — video transcoding, log parsing, batch jobs — where every worker reads inputs and drops outputs into the same shared path
How it's charged
- 01Pay per GB-month actually stored — no provisioned capacity, no minimum fee, and the bill shrinks when you delete files
- 02Storage class sets the rate: Standard is the premium tier; IA and Archive are dramatically cheaper per GB but add a per-GB charge each time data is read or tiered
- 03Throughput is a separate line: Elastic bills per GB read and written, Provisioned bills per MB/s-month above the baseline your Standard storage already earns, Bursting adds no throughput charge
- 04One Zone storage costs roughly half of Regional — the discount buys you less durability, not less performance
- 05Billing surprises: IA and Archive bill a 128 KiB minimum per file (painful with lots of tiny files), Archive has a 90-day minimum duration, and mounting a target in another AZ incurs cross-AZ data transfer charges
