EFS (Elastic File System)
Amazon EFS is a managed NFS file system for Linux instances and Linux-based applications — effectively network attached storage run as a service. Many clients mount the same file system at once and see the same directory tree, with ordinary POSIX file semantics.
- Speaks NFS version 4.1 (and 4.0), so standard Linux clients mount it without special software.
- Capacity is elastic: files are added and removed and the file system grows and shrinks with them, into the petabytes. Nothing is pre-provisioned, and billing follows what is stored.
- Supports thousands of concurrent connections.
- A Regional file system stores data across multiple Availability Zones and is reachable from all of them through mount targets.
- Provides read-after-write consistency.
NFS itself is not new: Sun Microsystems introduced it in 1984 as part of SunOS, and it has been the standard Unix file-sharing protocol ever since. EFS is that protocol delivered as a managed, multi-AZ service.
File system types
Section titled “File system types”| Regional | One Zone | |
|---|---|---|
| Data stored across | Multiple Availability Zones | One Availability Zone |
| Durability (designed for) | 99.999999999% | 99.999999999% |
| Availability SLA | 99.99% | 99.9% |
| Performance modes | General Purpose, Max I/O | General Purpose only |
| Typical use | Production workloads needing zone resilience | Development, test, backups, cost-sensitive data that can be rebuilt |
Regional is the recommended default. One Zone costs materially less but its data is confined to a single Availability Zone, so it should hold data that can be recreated or that is copied elsewhere.
Note that the eleven-nines figure is durability — the probability of not losing an object — and it applies to both types. What changes between them is availability, the SLA on being able to reach the data, and the blast radius of losing a zone.
Storage classes
Section titled “Storage classes”EFS has three storage classes, and a single file system holds files in more than one at a time.
- Standard is SSD-backed, for frequently accessed files. First-byte latency is around 1 ms for reads and 2.7 ms for writes.
- Infrequent Access (IA) is for data read a few times a quarter. Storage costs a fraction of Standard, with a retrieval charge and first-byte latencies in the tens of milliseconds.
- Archive is for data read a few times a year or less, cheaper again than IA, with the same tens-of-milliseconds latency.
Lifecycle management
Section titled “Lifecycle management”Lifecycle policies move files between classes automatically, based on how long a file has gone unread in Standard. A file system’s lifecycle configuration has three policies:
- Transition into IA — by default, files not accessed in Standard for 30 days.
- Transition into Archive — by default, files not accessed in Standard for 90 days.
- Transition into Standard — whether a file returns to Standard when it is read from IA or Archive. The default is that it does not. Set it to move on first access for latency-sensitive workloads, particularly ones handling many small files.
The transitions are per-file and invisible to the application, so the cheaper classes cost nothing in complexity. The usual reason a file system is expensive is that no lifecycle policy was ever configured.
Two details worth knowing. File metadata — names, ownership, directory structure — always stays in Standard, so listing a directory is fast whatever class its contents are in, and metadata operations do not count as access. And writes always land in Standard first, becoming eligible to transition again after 24 hours.
See the AWS lifecycle management documentation for the full set of transition periods.
Throughput modes
Section titled “Throughput modes”EFS offers three throughput modes. Elastic is the default and the mode AWS recommends.
Elastic
Section titled “Elastic”Throughput scales up and down automatically to match demand. Nothing is provisioned and no burst credits are involved; charges follow the volume of data and metadata read and written. It suits spiky or unpredictable workloads, and anything driving less than about 5% of its peak throughput on average.
A Regional file system on Elastic throughput reaches 20–60 GiBps of read and 1–5 GiBps of write throughput depending on the Region, and up to 1,500 MiBps per client with version 2.0 or later of the EFS client or CSI driver.
Provisioned
Section titled “Provisioned”A fixed throughput level is specified and billed regardless of use, independent of how much data the file system holds. It suits workloads whose requirements are known and which sustain 5% or more of peak on average. After switching to Provisioned or changing the amount, decreasing it or switching away is blocked for 24 hours.
Bursting
Section titled “Bursting”Throughput scales with the amount of data stored in the Standard class, at a baseline of 50 KiBps per GiB. Credits accrue below the baseline and are spent above it, allowing bursts to 100 MiBps per TiB (with a floor of 100 MiBps) while credits last; with none left, the file system drives 50 MiBps per TiB, minimum 1 MiBps. Reads are metered at one third the rate of writes, so read-heavy workloads get proportionally more.
A 100 GiB file system on Bursting therefore has a 5 MiBps write baseline and can hold 100 MiBps for roughly 72 minutes a day.
If a file system on Bursting is consistently using more than 80% of its permitted throughput, or exhausting its credits, that is the signal to move to Elastic or Provisioned.
Performance modes
Section titled “Performance modes”General Purpose has the lowest per-operation latency and is the default. Max I/O is a previous-generation mode for highly parallel workloads that tolerate higher latency; AWS recommends General Purpose for all file systems, and Max I/O is not available on One Zone file systems or with Elastic throughput. Treat it as legacy.
The PercentIOLimit CloudWatch metric shows how close a General Purpose file system is running to its operations limit.
Access from outside the VPC
Section titled “Access from outside the VPC”An on-premises network can mount EFS over AWS Direct Connect or a VPN — a direct connection is the sensible option for anything sustained, and mounting NFS across the raw internet is not appropriate.
For moving data rather than mounting it, AWS DataSync is the purpose-built service. It synchronises on-premises storage to EFS or S3, and EFS to EFS, over Direct Connect or the internet, with verification, scheduling and encryption in transit.
A typical architecture
Section titled “A typical architecture”A dynamic web application is the canonical fit. A fleet of web servers in an Auto Scaling group spans two Availability Zones; each zone has an EFS mount target, and every server mounts the same file system over NFS. Application code and user-uploaded content live on EFS rather than on each server’s own disk, so an instance can be replaced or added without copying state, and a zone can fail without the content becoming unreachable. Developers stage content on premises and DataSync keeps EFS in step.
How EFS compares with EBS and S3
Section titled “How EFS compares with EBS and S3”- Against EBS: no capacity to pre-provision, and many instances can mount it at once across zones, rather than one instance in one zone. Per GB it is significantly more expensive than gp3 — but a file system with a lifecycle policy moving cold data to IA and Archive is a different proposition from one sitting entirely in Standard, and the comparison should be made on the blended rate rather than the Standard rate.
- Against S3: EFS gives POSIX file semantics — directory trees, in-place modification, file locking — that S3 does not. S3 is much cheaper per GB and effectively unlimited, so data that is written once and read whole belongs there. Check current EFS and S3 pricing for the Region in question before deciding on cost grounds; rates differ by Region and by class.