What you will learn
- Why shared file storage exists and what problem EBS cannot solve
- EFS vs EBS vs Instance Store — the three storage types and when each is correct
- EFS performance modes — General Purpose vs Max I/O
- EFS throughput modes — Bursting, Provisioned, and Elastic (the recommended default)
- EFS storage tiers — Standard and Infrequent Access with lifecycle policies
- How EFS works across Availability Zones using Mount Targets
- Connecting EC2 instances and ECS Fargate tasks to EFS
- EFS security — Security Groups and IAM-based access policies
- EFS vs FSx — when to use which
Why this matters
At Hotstar, a video transcoding pipeline runs across 20 EC2 instances in parallel. Each instance reads the same source video file and writes output segments to a shared location. If each instance has its own EBS volume, none of them can see the other's output. EFS mounts as a shared filesystem — all 20 instances read and write to the same directory as if they were one machine. At Swiggy, configuration files and shared assets that all application servers need are stored in EFS. Add a new server — it mounts the same filesystem and immediately has access to all shared files. No S3 API calls, no syncing, just a regular filesystem.
EBS vs EFS vs Instance Store — The Three Storage Types
Understanding when to use each comes down to one question: how many servers need access at the same time?
EBS (Elastic Block Store): Attached to ONE EC2 instance at a time (except io1/io2 Multi-Attach) Like an external hard drive — plugged into one computer Data persists when instance stops AZ-specific — cannot cross availability zones Use for: OS disk, database storage, single-server application data EFS (Elastic File System): Mounted by MANY EC2 instances simultaneously Like a network drive — many computers access the same folder Data persists forever — independent of any instance Multi-AZ — same filesystem available across all AZs in a region Use for: shared content, ML training data, CMS media, config files Instance Store: Physically attached to the host hardware Lost permanently when instance stops or terminates Fastest possible IOPS — no network involved Use for: temporary data, caches, scratch spaceRememberEFS is the only AWS storage that multiple EC2 instances can mount simultaneously as a filesystem. If your application needs files shared across multiple servers, the answer is always EFS — not S3 (which is object storage accessed via API, not mountable as a filesystem).
How EFS Works — Mount Targets
EFS creates a Mount Target in each Availability Zone. Each Mount Target gets an IP address inside your VPC. EC2 instances connect to the Mount Target in their AZ.
EFS File System (regional — one filesystem) ├── Mount Target in ap-south-1a → IP: 10.0.1.50 ├── Mount Target in ap-south-1b → IP: 10.0.2.50 └── Mount Target in ap-south-1c → IP: 10.0.3.50 EC2 in ap-south-1a mounts via 10.0.1.50EC2 in ap-south-1b mounts via 10.0.2.50EC2 in ap-south-1c mounts via 10.0.3.50 All three EC2 instances see the SAME files.Write on EC2-A → EC2-B and EC2-C see it immediately.EFS replicates data across multiple AZs automatically. The filesystem survives a full AZ failure.
Performance Modes
General Purpose (default — use this for everything):
Lower latency per operationSuitable for: web serving, content management, home directories, most workloadsLimit: 35,000 IOPS maximumMax I/O:
Higher aggregate throughput and IOPSSlightly higher latency per operationSuitable for: big data, media processing, scientific workloads with thousands of instancesUse only when General Purpose hits its 35,000 IOPS ceilingRememberStart with General Purpose. Switch to Max I/O only if you see IOPS being throttled at scale. For most workloads including production web applications, General Purpose is the right choice.
Throughput Modes
Bursting (old default):
Throughput scales with filesystem sizeSmall filesystem = low throughput baselineCredit system for bursts above baselineProblem: if filesystem is small, baseline throughput is very lowProvisioned:
You specify throughput independently of filesystem sizePay for provisioned throughput whether you use it or notUse when: your filesystem is small but you need high consistent throughputElastic (recommended default):
Automatically scales throughput up and down based on workloadNo capacity planning neededPay only for what you useAWS recommends this for most new workloadsTipAlways use Elastic throughput mode for new EFS file systems unless you have a specific reason not to. It handles unpredictable workloads automatically, costs nothing when idle, and removes the complexity of sizing throughput in advance.
EFS Storage Tiers and Lifecycle
Like S3, EFS has tiers for hot and cold data. Files automatically move between tiers based on access patterns.
EFS Standard: For actively accessed files Higher cost per GB Sub-millisecond latency EFS Infrequent Access (EFS-IA): For files not accessed recently Up to 92% cheaper per GB Small retrieval fee when accessedLifecycle Policy:
Set a rule: move files not accessed in 30 days to EFS-IAFiles you access regularly stay in Standard automaticallyFiles you stop touching move to IA automatically EFS Intelligent Tiering: automatic movement between Standard and IASimilar to S3 Intelligent-Tiering — no manual management neededThis means you pay Standard prices only for files you actually use. Everything else is automatically cheaper.
EFS Security
Network access — Security Groups:
EC2 Security Group must allow: outbound NFS port 2049 to EFS Mount TargetEFS Mount Target Security Group must allow: inbound NFS port 2049 from EC2 Security GroupData access — IAM and EFS Access Points:
EFS Access Points enforce a specific POSIX user and directory per clientEach application or team gets its own Access PointApp A's Access Point → /app-a directory (cannot see /app-b)App B's Access Point → /app-b directory (cannot see /app-a)Encryption:
At rest: enabled during filesystem creation using KMSIn transit: TLS via amazon-efs-utils mount helperCannot enable at-rest encryption after creation — must create new filesystemEFS vs FSx — When to Use Which
EFS is Linux-only NFS. For other filesystems you need FSx.
| EFS | FSx for Windows | FSx for Lustre | |
|---|---|---|---|
| Protocol | NFS | SMB (Windows) | Lustre (HPC) |
| OS | Linux only | Windows | Linux |
| Use for | Shared Linux files | Windows file shares, Active Directory | HPC, ML, high-speed scratch |
| Multi-AZ | Yes | Yes | Single-AZ or Multi-AZ |
If your servers are Windows → FSx for Windows File Server If your workload is HPC or ML training → FSx for Lustre If your servers are Linux and need shared files → EFS
Hands-on Lab — Mount EFS on Two EC2 Instances
Step 1 — Create an EFS Security Group
EC2 → Security Groups → Create security groupName: efs-sg VPC: your VPCInbound rule: NFS (port 2049) from your EC2 security groupCreate security groupStep 2 — Create the EFS File System
EFS → Create file systemName: devops-shared-fsVPC: your VPCClick Customize: Performance mode: General Purpose Throughput mode: Elastic Lifecycle: 30 days since last access → EFS-IA Encryption: EnableNext Mount targets: ap-south-1a → select private subnet → security group: efs-sg ap-south-1b → select private subnet → security group: efs-sgNext → Create Wait for State: AvailableStep 3 — Mount on EC2 Instance 1
Copy the EFS filesystem ID (fs-xxxxxxxx)SSH into EC2 Instance 1:## Install EFS mount helpersudo yum install -y amazon-efs-utils ## Create mount pointsudo mkdir /shared ## Mount the EFS filesystemsudo mount -t efs -o tls fs-xxxxxxxx:/ /shared ## Write a fileecho "Written by EC2 Instance 1" | sudo tee /shared/test.txt ## Verifycat /shared/test.txtStep 4 — Mount on EC2 Instance 2 and verify sharing
SSH into EC2 Instance 2 (different instance, same VPC):sudo yum install -y amazon-efs-utilssudo mkdir /sharedsudo mount -t efs -o tls fs-xxxxxxxx:/ /shared ## Read the file written by Instance 1cat /shared/test.txt## Shows: Written by EC2 Instance 1 ## Write from Instance 2echo "Written by EC2 Instance 2" | sudo tee /shared/test2.txtBack on Instance 1:ls /shared/## Shows both test.txt and test2.txt — real-time sharing confirmedStep 5 — Make mount persistent across reboots
## Add to /etc/fstab so it mounts automatically on rebootecho "fs-xxxxxxxx:/ /shared efs _netdev,tls 0 0" | sudo tee -a /etc/fstabStep 6 — Cleanup
Unmount on both instances: sudo umount /sharedEFS → File systems → devops-shared-fs → DeleteEC2 → Security Groups → efs-sg → DeleteCommon Mistakes to Avoid
Common MistakeTrying to use S3 as a shared filesystem between EC2 instances. S3 is object storage accessed via HTTP API — it cannot be mounted as a filesystem with standard Linux tools. For shared filesystem access across multiple instances the answer is EFS, not S3.
Common MistakeForgetting to open NFS port 2049 in the EFS Security Group. The most common reason EFS mounts fail is a missing inbound rule on port 2049. Always check Security Group rules first when debugging mount failures.
Common MistakeEnabling at-rest encryption after creation. EFS encryption at rest can only be enabled when the filesystem is created. If you forget, you must create a new encrypted filesystem, copy the data, and switch over. Enable it at creation time — always.
TipUse EFS with ECS Fargate for persistent storage in containers. EBS cannot attach to Fargate tasks. EFS can. Any Fargate task that needs to read or write persistent files — ML models, configuration, uploads — should mount EFS. The same filesystem can be mounted by hundreds of Fargate tasks simultaneously.
