Chapter 43: AWS Elastic File System

AWS Elastic File System (EFS)

Many beginners hear “file system” and think “oh, that’s just like a shared folder on Windows or NFS on Linux”. And yes — that’s exactly what it is… but on steroids, infinitely scalable, fully managed, and living in the cloud.

Let me explain it like we’re sitting together in a Gachibowli café with a whiteboard — slow, clear, full of everyday Hyderabad analogies, real startup examples, 2026 pricing & features, and exactly when & how to use it.

1. What is Amazon EFS? (Simple First)

Amazon Elastic File System (EFS) is a fully managed, elastic, scalable, shared file storage service that works like a classic NFS (Network File System) — but built for the cloud.

• Multiple EC2 instances, ECS/Fargate containers, Lambda functions, or on-premise servers can mount the same EFS file system at the same time
• Everyone sees the same files & folders — exactly like a shared network drive
• You can read, write, delete, rename — all standard file operations
• EFS automatically grows and shrinks as you add/remove files — no provisioning capacity
• It lives inside your VPC, is highly durable & available, and supports thousands of concurrent connections

Official short line (still perfect in 2026): “Amazon EFS provides a simple, serverless, set-and-forget elastic file system for use with AWS Cloud services and on-premises resources.”

In plain Hyderabad language: Imagine you have a big family function hall in Banjara Hills. Different caterers, decorators, DJs, photographers all need to access the same set of folders (menu list, guest list, playlist, photos). Instead of giving everyone a USB drive or Dropbox folder (which gets messy), you put one giant shared whiteboard + file cabinet inside the hall — everyone mounts it over the network and works on the same files simultaneously.

EFS = that shared file cabinet in the cloud — but infinite size, never runs out of space, never crashes, and can be mounted from hundreds of machines at once.

2. Why Do Teams Use EFS? (Real 2026 Reasons in Hyderabad)

• Shared access — many servers/containers need the same files at the same time (read + write)
• No capacity planning — grows/shrinks automatically (pay for what you use)
• High availability — multi-AZ by default (Standard mode)
• Linux-friendly — standard NFSv4 protocol
• Works with Lambda — Lambda can mount EFS (great for data processing)
• On-premise too — mount from your Hyderabad data center via Direct Connect / VPN

Common Hyderabad use cases 2026:

• WordPress / CMS sites — shared wp-content/uploads folder across multiple EC2 / ECS instances
• Content management / media teams — shared folder for designers & editors (videos, PSDs, raw footage)
• Data science / ML workflows — shared dataset folder mounted by multiple training instances
• Legacy apps — applications that require a shared file system (NFS/SMB style)
• CI/CD pipelines — shared build cache / artifacts folder
• Home directories — shared /home for developers using bastion hosts

3. EFS Performance & Storage Classes (2026 – Important Choices)

EFS has two main performance modes & two storage classes — choose carefully.

2026 tip for Hyderabad teams: → 90% of cases → General Purpose + Standard → Only use One Zone for dev/test or secondary copies → Max I/O is almost never needed anymore — General Purpose bursts are usually enough

4. Real Hyderabad Example – Shared Media Folder for Content Team

Your short-video startup in Madhapur:

Problem:

• Content creators upload raw footage & thumbnails
• Editors, thumbnail designers, and moderation team all need to access the same folder simultaneously
• You have 3 EC2 instances + 5 Fargate containers + some Lambda functions
• Traditional solution (one EC2 NFS server) → single point of failure, manual scaling

Solution with EFS:

1. Create EFS file system in ap-south-2 (Standard mode)
2. Mount target in each AZ (a, b, c) → high availability
3. Security group → allow NFS port 2049 from your VPC CIDR
4. Mount EFS on all instances/containers:
   Bash

   PHP

   0 1 2 3 4 5 6

   sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-12345678.efs.ap-south-2.amazonaws.com:/ /mnt/efs

5. Everyone mounts the same folder (/mnt/efs/shared-media)
6. Creators upload raw.mp4 → editors open immediately → moderators tag → all see changes in real time

During viral moment (Sankranti festival):

• 20× more uploads → EFS automatically handles thousands of concurrent connections
• No manual scaling of file servers
• Cost: ~₹5,000–15,000/month for 2–5 TB shared storage (vs ₹30,000+ for self-managed NFS cluster)

5. Quick Hands-On – Mount Your First EFS (Free Tier Friendly)

1. EFS console → Create file system
   • Name: “hyderabad-shared-media”
   • VPC: your default VPC
   • Mount targets: one in each AZ (automatic)
2. Launch EC2 t4g.micro in ap-south-2 (same VPC)
3. Security group → allow NFS (TCP 2049) from your IP or VPC CIDR
4. SSH in → install NFS client:
   Bash

   PHP

   0 1 2 3 4 5 6

   sudo yum install -y amazon-efs-utils

5. Mount:
   Bash

   PHP

   0 1 2 3 4 5 6 7 8

   sudo mkdir /mnt/efs sudo mount -t efs fs-12345678:/ /mnt/efs df -h   # see it mounted

6. Create file → echo “Hello from Hyderabad” > /mnt/efs/test.txt
7. Launch second EC2 → mount same EFS → see the file

Cost? Usually ₹0–50 for testing (first 5 GB free tier, low throughput)

Summary Table – EFS Cheat Sheet (2026 – India Focus)

Teacher’s final note: EFS is the “shared Google Drive / network folder” of AWS — but infinite, highly available, and fully managed. In 2026, every Hyderabad startup that has more than one server/container needing to read/write the same files ends up using EFS (WordPress multisite, media teams, build caches, shared datasets…).

Got it? This is the “how do multiple machines share the same folder safely & scalably?” lesson.

Next?

• Step-by-step: Set up EFS + ECS Fargate + Lambda all mounting the same file system?
• EFS vs FSx for Windows vs EBS Multi-Attach?
• Or EFS performance tuning + monitoring?

Tell me — next whiteboard ready! 🚀📁