Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. This session covers Amazon EFS — shared storage that multiple EC2 instances can read/write simultaneously.

📋 Topics Covered

What is Amazon EFS?

EFS = Elastic File System — a fully managed, auto-scaling shared file system that multiple EC2 instances can mount and use at the same time, both reading and writing.

Analogy: Think of EBS as a personal hard drive — it belongs to one laptop only. EFS is like a shared Google Drive folder that your entire team can open simultaneously from different computers, see the same files, and edit them in real time.

Key characteristics:

• Uses the NFS 4.1 protocol (Network File System — standard Linux file sharing)
• Serverless — no capacity to provision, no servers to manage
• Auto-scales — grows from KB to PB automatically, shrinks when files are deleted
• Highly available — data replicated across multiple AZs in a Region
• Pay-as-you-go — billed per GB actually stored, no pre-provisioning

EFS vs EBS vs S3 — The Big Comparison

This is one of the most commonly tested comparisons in AWS certifications.

Simple decision rule:

Need a disk for ONE EC2 instance (like an OS drive)?        → EBS
Need a shared folder MULTIPLE EC2 instances can access?      → EFS
Need to store files accessible from anywhere via internet?   → S3

🎯 Interview Tip: "Can two EC2 instances share an EBS volume?" — Only with io1/io2 Multi-Attach, and even then both must be in the same AZ. EFS is the natural answer when the question is about shared access across multiple instances in different AZs.

EFS Architecture

EFS spans multiple Availability Zones within a Region. Here's how it's structured:

                    Amazon EFS File System
                  (stored redundantly across AZs)
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                      │
      AZ 1                  AZ 2                   AZ 3
   Mount Target          Mount Target           Mount Target
   (ENI + IP)            (ENI + IP)             (ENI + IP)
        │                     │                      │
   EC2 Instance          EC2 Instance           EC2 Instance
   /mnt/efs              /mnt/efs               /mnt/efs

   All instances access the SAME file system via NFS (port 2049)

Mount Target — this is the key piece. It's an ENI (Elastic Network Interface) that EFS creates inside each AZ of your VPC. It's the "doorway" through which EC2 instances in that AZ connect to EFS over NFS.

• One mount target per AZ (auto-created when you set up EFS)
• Has its own private IP and security group
• EC2 instances in that AZ connect to the local mount target for best performance

Mounting — What It Actually Means

Mounting is the process of attaching a file system to a directory on your OS so it behaves like a normal local folder.

Analogy: Mounting EFS is like plugging in a USB drive and having it appear as a folder you can open, save files into, and read from — except this "USB drive" lives in AWS and multiple computers can plug into it at once.

# Before mounting: /mnt/efs is just an empty folder
# After mounting: /mnt/efs IS the EFS file system
sudo mount -t nfs4 -o nfsvers=4.1 <EFS-DNS-Name>:/ /mnt/efs

Once mounted, every ls, cat, echo >, cp command on /mnt/efs is actually reading/writing to the shared EFS file system — not local disk.

Mount Targets & Security Group Configuration

This is the part that trips people up in labs — two separate security groups working together.

The Two Security Groups

EC2 Security Group (lab-ec2-sg)

Inbound:  SSH (22) from My IP
Outbound: NFS (2049) to EFS-SG  [allows EC2 to reach EFS]

EFS Security Group (lab-efs-sg)

Inbound:  NFS (2049) from lab-ec2-sg  [only EC2 instances can reach EFS]
Outbound: Allow all (default)

Why two security groups referencing each other?

This is a common AWS pattern — instead of allowing an IP range, you allow traffic from a specific security group. This means: "Only instances that have the EC2 security group attached are allowed to talk to EFS on port 2049." Clean, scalable, and secure — you never have to know or update IP addresses.

EC2 Instance (has lab-ec2-sg)
        │
        │  NFS traffic, port 2049
        ▼
EFS Mount Target (has lab-efs-sg, allows inbound from lab-ec2-sg)
        │
        ▼
Access Granted ✅

⚠️ Common lab mistake: Creating the EFS file system and trying to mount immediately — it fails because the EFS security group doesn't yet allow NFS traffic from the EC2 security group. You must add that inbound rule first.

Mount Target Requirements

• One mount target per AZ in your VPC
• Requires a subnet assignment
• Has a private IP auto-assigned
• DNS-based access — EFS gives you one DNS name that automatically resolves to the correct local mount target for whichever AZ you're connecting from

Persistence Across Reboots

By default, if your EC2 instance restarts, the EFS mount is gone — you'd have to mount it manually again. To make it automatic:

# Add to /etc/fstab
<EFS-DNS-Name>:/ /mnt/efs nfs4 defaults,_netdev 0 0

The _netdev option tells the OS to wait for networking to be ready before attempting the mount — critical since EFS is a network resource, not local disk.

EFS Storage Classes

How it works: Standard is the default — best for files you're actively using. IA is for files that just sit there most of the time (old logs, archived reports) — cheaper to store, but costs a small fee each time you access them. The trade-off only makes sense if access is genuinely rare.

EFS Lifecycle Management & Policies

This is automatic tiering — EFS moves files between Standard and IA based on actual usage, without you lifting a finger.

File created → Standard storage (full price)
        │
        │  Not accessed for X days (your chosen threshold)
        ▼
Auto-moved to Infrequent Access (cheaper)
        │
        │  Someone accesses the file again
        ▼
Auto-moved back to Standard

Configurable transition periods: 7, 14, 30, 60, or 90 days of inactivity (or disabled entirely).

Why this matters: You don't have to manually audit and move files — EFS handles cost optimization automatically based on real access patterns. Set it once during file system creation and forget about it.

🎯 Cert Perspective: "How do you reduce EFS storage cost for rarely accessed files without manual intervention?" → Enable Lifecycle Management with a transition policy to IA.

EFS Performance Modes & Throughput Modes

These are two separate settings that often get confused — performance mode is about latency/concurrency, throughput mode is about data transfer speed.

Performance Modes (set once, cannot change later)

Throughput Modes (can change later)

🎯 Cert Perspective: Know that Performance Mode is locked at creation, but Throughput Mode can be changed afterward. A scenario like "small file system but needs guaranteed high throughput" points to Provisioned Throughput.

Benefits of EFS

Security & Encryption

Network Security:

• Security groups control all access (as covered above)
• VPC isolation — EFS only accessible within your VPC by default
• NFS traffic always on port 2049

Data Encryption:

• At rest — via AWS KMS, enable when creating the file system
• In transit — via TLS, add -o tls to your mount command

Access Control (3 layers):

1. File System Policy — IAM-style resource policy on the EFS itself (grant/deny access)
2. POSIX file permissions — standard Linux permissions (chmod, chown) work exactly as expected
3. IAM integration — controls who can call EFS API operations (create, delete, modify)

Best practices:

• Always enable encryption when creating the file system (can't add it retroactively)
• Restrict security groups to required ports only — never open NFS to 0.0.0.0/0
• Use VPC security groups for isolation, exactly like the EC2-SG ↔ EFS-SG pattern above

EFS Pricing & Cost Optimization

What you pay for:

• Standard Storage — per GB stored
• Infrequent Access — ~50% lower per GB, plus a small fee each time data is retrieved

Cost optimization checklist:

✅ Enable Lifecycle Management — auto-move inactive files to IA
✅ Choose sensible transition days based on actual access patterns
✅ Use Bursting Throughput (default) unless you specifically need Provisioned
✅ Monitor usage via CloudWatch metrics
✅ Clean up unused files regularly

🧪 LAB — Full Hands-On Walkthrough

Lab Architecture

            VPC (Default)
        ┌─────────────────────────┐
        │   Availability Zone      │
        │  ┌──────────┐  ┌──────────┐
        │  │   EC2-1   │  │   EC2-2   │
        │  │ /mnt/efs  │  │ /mnt/efs  │
        │  └─────┬────┘  └─────┬────┘
        │        │  NFS (2049)  │
        │        └──────┬───────┘
        │                ▼
        │         Amazon EFS
        │       (Mount Target)
        └─────────────────────────┘

Security Groups:
  EC2-SG  → allows SSH (22) inbound from My IP
  EFS-SG  → allows NFS (2049) inbound from EC2-SG only

Lab Step 1 — Launch 2 EC2 Instances

Repeat this entire process twice (EC2-Instance-1 and EC2-Instance-2):

1. EC2 Console → Launch Instances
2. Name: EC2-Instance-1 (then EC2-Instance-2)
3. AMI: Amazon Linux 2 (HVM) — Free tier eligible
4. Instance type: t2.micro / t3.micro (Free tier)
5. Key Pair: Create new → lab-key-pair → .pem format
6. Network: Default VPC, any subnet, Auto-assign public IP: Enable
7. Security Group: Create lab-ec2-sg → Allow SSH (22) from My IP
8. Storage: 8 GB gp2 root volume (default)
9. Launch Instance — repeat for Instance 2

⚠️ Use the SAME key pair, VPC, and subnet for both instances — keeps the lab simple and ensures they can communicate.

Lab Step 2 — Create and Configure EFS

1. AWS Console → Services → EFS → Create file system
2. Name: lab-efs
3. VPC: Select SAME VPC as your EC2 instances
4. Quick Create (defaults) or Customize
5. EFS auto-creates mount targets in each AZ of the VPC
6. Edit mount target Security Group → create/use lab-efs-sg
7. Add Inbound Rule to lab-efs-sg: NFS (2049) from lab-ec2-sg
8. Create — note the File System ID: fs-xxxxxxxxx

EFS Settings used (defaults):

Performance mode:  General Purpose
Throughput mode:   Bursting
Encryption:        Enabled (KMS)
Storage class:     Standard (multi-AZ redundancy)

Security Group Rule Summary:

Lab Step 3 — Mount EFS on Both Instances

Open two separate SSH terminals — one per instance. Run identical steps on both.

# Step 1: Update packages
sudo yum update -y

# Step 2: Install NFS/EFS utilities
sudo yum install -y amazon-efs-utils
# (or: sudo yum install -y nfs-utils — depending on AMI)

# Step 3: Create mount directory
sudo mkdir efs
# or: sudo mkdir /mnt/efs

# Step 4: Mount EFS
sudo mount -t efs -o tls fs-012f61809a9d6e846:/ /efs
# or using DNS name:
sudo mount -t nfs4 -o nfsvers=4.1 <EFS-DNS-Name>:/ /mnt/efs

# Step 5: Verify the mount
df -h
# or
mount | grep efs

⚠️ If the mount fails on the first attempt — this is expected if you haven't yet added the NFS inbound rule to the EFS security group. Add it, then retry the mount command. This is intentional in the lab flow to show why the security group rule matters.

Lab Step 4 — Demonstrate File Sharing (The Core Proof)

On EC2 Instance 1 (Writer):

cd /mnt/efs

# Write a file
echo 'Hello from EC2 Instance 1!' | sudo tee shared-file.txt

# Append a timestamp
echo "Timestamp: $(date)" | sudo tee -a shared-file.txt

# Create a folder and copy a file into it
sudo mkdir /mnt/efs/shared-folder
sudo cp /etc/hostname /mnt/efs/shared-folder/host1.txt

On EC2 Instance 2 (Reader) — same EFS mount:

cd /mnt/efs

# List files — see what Instance 1 wrote, instantly
ls -la /mnt/efs
# Output: shared-file.txt  shared-folder/

# Read the file Instance 1 created
cat shared-file.txt
# Output:
# Hello from EC2 Instance 1!
# Timestamp: Mon Jan 01 10:00:00 UTC

# Write back from Instance 2
echo 'Reply from Instance 2!' | sudo tee -a shared-file.txt

Verify on EITHER instance:

cat /mnt/efs/shared-file.txt
# Hello from EC2 Instance 1!
# Timestamp: Mon Jan 01 10:00:00 UTC
# Reply from Instance 2!

What this proves:

• Both instances read/write the same file system simultaneously
• Changes from one instance are instantly visible on the other
• No manual file transfer, sync, or copying needed — this is the entire value of EFS

Permissions Note

# Grant full access to all users on the mount
sudo chmod 777 /mnt/efs

# Now you can write without sudo
echo 'No sudo needed!' > /mnt/efs/test.txt
cat /mnt/efs/test.txt

🧹 Cleanup Checklist (Don't Skip This!)

✅ Unmount EFS on both instances: sudo umount /mnt/efs
✅ Terminate both EC2 instances
✅ Delete EFS file system (lab-efs)
✅ Delete security groups: lab-ec2-sg, lab-efs-sg
✅ Delete key pair if no longer needed

⚠️ EFS bills per GB stored — even small test files left running add up over time if forgotten. Always clean up after labs.

📝 Assignment — Independent Repeat

Complete this without step-by-step guidance, using everything from the lab above:

1.  Launch EC2 #1 — Amazon Linux 2, t2.micro, new key pair, public IP enabled
2.  Launch EC2 #2 — same config, same key pair, same VPC/subnet
3.  Create EFS — name: my-efs, default VPC, default settings
4.  Configure SGs — EC2 SG: SSH (22). EFS SG: NFS (2049) from EC2 SG
5.  Mount on EC2 #1 — install nfs-utils, mkdir /mnt/efs, mount EFS
6.  Mount on EC2 #2 — same mount steps
7.  Verify Mounts — run df -h on both, confirm EFS appears
8.  Write from EC2 #1 — create a file with your name at /mnt/efs/yourname.txt
9.  Read from EC2 #2 — cat /mnt/efs/yourname.txt, confirm visible
10. Write from EC2 #2 — append a second line to the same file
11. Cleanup — unmount, terminate instances, delete EFS and SGs

Submission deliverables (screenshots):

1. EC2 Instances list — both Running
2. EFS file system page — showing created file system
3. df -h output on Instance 1 — /mnt/efs mounted
4. df -h output on Instance 2 — /mnt/efs mounted
5. Terminal — file written on Instance 1
6. Terminal — same file read from Instance 2

Grading breakdown: EC2 launch (25 pts) · EFS + SG config (25 pts) · Mounted on both (25 pts) · File sharing both ways (25 pts)

⚡ Quick Revision

WHAT IS EFS
  Fully managed, shared, auto-scaling NFS file system
  Multiple EC2 instances mount it simultaneously
  Protocol: NFS v4.1, Port: 2049

EFS vs EBS vs S3
  EBS = single instance, block storage, AZ-locked
  EFS = multiple instances, NFS, Region-wide (multi-AZ)
  S3  = internet/API access, object storage, unlimited

ARCHITECTURE
  Mount Target = ENI in each AZ, the doorway to EFS
  One per AZ, auto-created, has its own private IP + SG

SECURITY GROUP PATTERN
  EC2-SG  → outbound NFS to EFS-SG
  EFS-SG  → inbound NFS (2049) FROM EC2-SG only
  Never open NFS to 0.0.0.0/0

STORAGE CLASSES
  Standard = frequent access, higher cost
  IA       = infrequent access, ~50% cheaper + access fee

LIFECYCLE POLICY
  Auto-moves files Standard → IA after X days inactive (7/14/30/60/90)
  Auto-moves back to Standard when accessed again

PERFORMANCE MODES (set once)
  General Purpose = default, lowest latency, most workloads
  Max I/O = max throughput, more concurrency, big data

THROUGHPUT MODES (changeable)
  Bursting     = default, scales with FS size
  Provisioned  = fixed guaranteed throughput
  Max I/O      = highest throughput/ops

ENCRYPTION
  At rest  → KMS (enable at creation)
  In transit → TLS (-o tls in mount command)

MOUNT COMMAND
  sudo mount -t efs -o tls fs-xxxx:/ /efs
  or
  sudo mount -t nfs4 -o nfsvers=4.1 <EFS-DNS>:/ /mnt/efs

PERSISTENCE
  Add to /etc/fstab with _netdev option to survive reboot

💼 Interview Questions

Q1: What is the main difference between EFS and EBS?
EBS is block storage attached to a single EC2 instance within one AZ — like a personal hard drive. EFS is a shared NFS file system that multiple EC2 instances across multiple AZs can mount and access simultaneously — like a shared network drive.

Q2: Why does an EFS mount initially fail in the lab even though the file system was created successfully?
The EFS security group doesn't yet have an inbound rule allowing NFS (port 2049) traffic from the EC2 security group. Until that rule is added, EC2 instances cannot reach the mount target, so the mount command times out or fails.

Q3: How does EFS achieve high availability?
EFS automatically creates a mount target in each Availability Zone of your VPC and stores data redundantly across multiple AZs within the Region — so it tolerates an AZ failure without data loss or downtime.

Q4: What's the difference between EFS Performance Mode and Throughput Mode?
Performance Mode (General Purpose or Max I/O) is set once at creation and determines latency characteristics — it can't be changed later. Throughput Mode (Bursting, Provisioned, or Max I/O) controls how much data transfer capacity you get and can be changed after creation.

Q5: A company has files that are rarely accessed after 30 days but must remain available. How would you optimize EFS costs?
Enable EFS Lifecycle Management with a transition policy set to 30 days. Files inactive for 30 days automatically move to Infrequent Access storage class at roughly 50% lower storage cost. If accessed again, they automatically move back to Standard.

Q6: Why do EC2-SG and EFS-SG reference each other instead of using IP addresses?
Referencing security groups instead of IPs is more secure and scalable — it means "only resources carrying this specific security group can connect," regardless of how many instances exist or what their IPs are. No manual IP management needed as you scale.

🔬 Practice Tasks

1. Complete the Assignment above independently (full EC2 + EFS lab without referring to lab steps).
2. After mounting EFS on one instance, deliberately remove the NFS inbound rule from the EFS security group, then try writing a new file. Observe what happens. Re-add the rule and confirm it works again.
3. Enable Lifecycle Management on your EFS with a 7-day transition to IA. Create a file, wait (or simulate), and check the EFS Console to see which storage class it reports.
4. Add your EFS mount to /etc/fstab on one instance. Reboot the instance and confirm the mount persists automatically without running the mount command again.
5. Compare: create a 1GB file directly on EBS root volume vs on the EFS mount. Time how long a cp operation takes on each, and note any latency differences.

AWS Session 5 — EFS Essentials | Cloud + DevOps learning journey — Systems Engineer → Cloud/DevOps Engineer