EFS — Concept
What it is
Amazon Elastic File System (EFS) = fully managed, regional, POSIX-compliant NFS v4 file system that can be mounted by thousands of EC2 / Lambda / ECS / EKS / Fargate / on-prem clients simultaneously.
Why it exists
EBS is single-AZ and one-instance; S3 is object, not file. EFS fills the gap for shared file storage that scales elastically and is multi-AZ by default.
How it works
- Create an EFS file system → it gets a regional DNS name (e.g.
fs-xxx.efs.region.amazonaws.com). - Create mount targets in each AZ subnet you need (one per AZ).
- Clients mount via NFS using
efsmount helper or standard NFS client. - Storage automatically scales; you pay per GB-month + throughput.
Performance modes
| Mode | Use |
|---|---|
| General Purpose (default) | Low latency, ≤ ~35k IOPS — most apps |
| Max I/O | Very high parallelism (big data, media) — higher latency |
Throughput modes
| Mode | Use |
|---|---|
| Bursting (default) | Throughput scales with size; small FS bursts using credits |
| Provisioned | Fixed MiB/s independent of size |
| Elastic | Auto-scales up/down, pay per use — preferred for spiky workloads |
Storage classes & lifecycle
| Class | Use |
|---|---|
| Standard | Multi-AZ, frequently accessed |
| Standard-IA | Multi-AZ, infrequent (~92 % cheaper, retrieval fee) |
| One Zone | Single-AZ, ~47 % cheaper |
| One Zone-IA | Single-AZ + infrequent |
Lifecycle policy: move files to IA after N days (7–90) of no access; Intelligent-Tiering moves back automatically.
Security
- Network: VPC SG on mount target (allow NFS port 2049 from client SGs).
- IAM: file-system policies + IAM authentication for NFS clients.
- Encryption at rest (KMS) and in transit (TLS via mount helper).
- POSIX permissions (UID/GID) inside the FS.
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|---|---|
| EFS | EBS | Multiple EC2 / Lambda / Fargate need shared files |
| EFS | FSx for Windows | Linux NFS workload |
| FSx for Windows | EFS | Windows SMB / Active Directory |
| FSx for Lustre | EFS | HPC / ML with thousands of MiB/s |
| S3 | EFS | Object storage, no POSIX, no mounting |
Limits & defaults
- No size cap (petabyte-scale).
- Read-after-write consistency.
- Mount target uses port 2049 (NFS).
- Latency: low ms; not for ultra-low-latency block workloads (use EBS io2).
- Cross-region: replicate via EFS Replication (RPO ≈ 1 min).
- Cross-AZ access works (NFS over the VPC).
Common exam scenarios
- "WordPress on 5 EC2s needs shared
/var/www/html" → EFS (Standard or Elastic). - "Linux app, infrequently accessed files, cheapest" → EFS Standard-IA + lifecycle.
- "Single-AZ dev environment, cheap shared FS" → EFS One Zone.
- "Need SMB shares for Windows app" → FSx for Windows, not EFS.
- "HPC training reads TB of data at 1 TB/s" → FSx for Lustre, not EFS.
- "Lambda needs to read a 20 GB ML model" → mount EFS via VPC, or use S3+
/tmp.
Exam tip
If the question says "multiple EC2 instances need to share a file system" → it's almost always EFS. If it says Windows or SMB → FSx for Windows.