TECH **AWS EFS Deep Dive: Standard, Infrequent Access, & Performance Modes**

AWS EFS Deep Dive: Standard, Infrequent Access, & Performance Modes

A Hyper-Practical, Zero-Fluff Study Guide for AWS Solutions Architect – Associate

1. What This Is & Why It Matters

You’re a cloud engineer at a SaaS company. Your team runs multiple EC2 instances (web servers, batch processors, CI/CD workers) that all need shared, persistent storage—like a network drive that every server can read/write to simultaneously. S3 is too slow for this (object storage, not file system), and EBS is tied to a single EC2 instance (no shared access). Amazon EFS (Elastic File System) is your answer.

Why EFS Matters in Production

• Shared access: Multiple EC2 instances (or Lambda, ECS, EKS) can mount the same EFS volume at the same time—no data silos.
• Scalability: EFS grows (or shrinks) automatically as you add/remove files. No manual provisioning like EBS.
• Durability & Availability: Data is replicated across multiple AZs (unlike EBS, which is single-AZ).
• Cost vs. Performance Tradeoffs: You can optimize for frequently accessed files (Standard) or archival data (Infrequent Access).

What breaks if you ignore EFS?
- Performance bottlenecks: If you use EBS for shared storage, you’ll hit I/O limits (EBS is single-instance).
- Data inconsistency: If you sync files manually (e.g., rsync between EC2 instances), you’ll have race conditions.
- Cost overruns: If you store everything in EFS Standard when 80% of your data is rarely accessed, you’re wasting money.

Real-world scenario:
You’re migrating a legacy monolithic app to AWS. The app uses a shared /data directory for user uploads, logs, and temporary files. EFS is the only AWS service that lets you mount the same file system across dozens of EC2 instances without rewriting the app.

2. Core Concepts & Components

1. ? EFS File System

• Definition: A managed NFS (Network File System) that scales automatically and is accessible across multiple AZs.
• Production Insight:
• No capacity planning needed—EFS grows/shrinks as you add/remove files (unlike EBS, where you must pre-provision size).
• Pay for what you use (GB/month), not for provisioned capacity.

2. ? Mount Target

• Definition: An ENI (Elastic Network Interface) in a VPC subnet that EC2 instances use to connect to EFS.
• Production Insight:
• You need one mount target per AZ where you want EFS access.
• Security Groups must allow NFS traffic (port 2049) from EC2 instances.

3. ? EFS Standard (Default Storage Class)

• Definition: Frequently accessed files (e.g., active user uploads, logs, config files).
• Production Insight:
• Lowest latency (~1-2ms for reads/writes).
• Most expensive (~$0.30/GB/month in us-east-1).

4. ? EFS Infrequent Access (EFS IA)

• Definition: Cheaper storage for rarely accessed files (e.g., old backups, archived logs).
• Production Insight:
• ~85% cheaper than Standard (~$0.045/GB/month in us-east-1).
• Higher latency (~10-20ms for reads/writes).
• Minimum 30-day retention (you pay for 30 days even if you delete a file sooner).

5. ? Performance Modes

• Production Insight:
• General Purpose is fine for 90% of workloads.
• Max I/O is only needed for extreme workloads (e.g., 100+ EC2 instances hitting EFS simultaneously).

6. ? Lifecycle Management

• Definition: Automatically moves files from Standard → IA after a set period (e.g., 30 days of no access).
• Production Insight:
• Saves 85% on storage costs for old files.
• No downtime—files are still accessible (just slower).

7. ? Security (IAM + Network)

• IAM: Controls who can create/delete EFS volumes (not file-level permissions).
• Network: Security Groups must allow NFS (port 2049) from EC2 instances.
• Production Insight:
• EFS does not support encryption at rest by default—you must enable it at creation.
• Use IAM policies to restrict access (e.g., only allow efs:CreateFileSystem for admins).

8. ? Throughput Modes

• Production Insight:
• Bursting is free and works for most workloads.
• Provisioned is only needed if you need guaranteed throughput (e.g., a video rendering farm).

3. Step-by-Step: Deploy EFS with Lifecycle Management (Hands-On)

Prerequisites

✅ AWS account with admin IAM permissions
✅ VPC with at least 2 subnets in different AZs (for high availability) ✅ EC2 instance (Amazon Linux 2) in one of the subnets

Step 1: Create an EFS File System

# Create EFS with encryption & lifecycle policy (moves files to IA after 30 days)
aws efs create-file-system \
  --creation-token "my-efs-$(date +%s)" \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted \
  --tags Key=Name,Value=MyAppEFS \
  --lifecycle-policies TransitionToIA=AFTER_30_DAYS

Expected Output:

{
  "FileSystemId": "fs-12345678",
  "CreationToken": "my-efs-1678901234",
  "Encrypted": true,
  "LifeCycleState": "creating"
}

✅ Verify:

aws efs describe-file-systems --file-system-id fs-12345678

Step 2: Create Mount Targets (One per AZ)

# Get your VPC ID and subnet IDs
VPC_ID=$(aws ec2 describe-vpcs --query "Vpcs[0].VpcId" --output text)
SUBNETS=$(aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPC_ID" --query "Subnets[*].SubnetId" --output text)

# Create mount targets in each subnet
for SUBNET in $SUBNETS; do
  aws efs create-mount-target \
    --file-system-id fs-12345678 \
    --subnet-id $SUBNET \
    --security-groups sg-12345678  # Replace with your SG allowing NFS (port 2049)
done

✅ Verify:

aws efs describe-mount-targets --file-system-id fs-12345678

Step 3: Mount EFS on EC2

# SSH into your EC2 instance
ssh -i "your-key.pem" ec2-user@your-ec2-public-ip

# Install NFS client (Amazon Linux 2)
sudo yum install -y amazon-efs-utils

# Create a mount directory
sudo mkdir /mnt/efs

# Mount EFS (replace fs-12345678 with your FileSystemId)
sudo mount -t efs fs-12345678:/ /mnt/efs

# Verify
df -h | grep efs

Expected Output:

fs-12345678.efs.us-east-1.amazonaws.com:/  8.0E  0   8.0E   0% /mnt/efs

? Make it persistent (add to /etc/fstab):

echo "fs-12345678:/ /mnt/efs efs _netdev,tls,iam 0 0" | sudo tee -a /etc/fstab

Step 4: Test EFS (Create a File)

# Create a test file
echo "Hello, EFS!" | sudo tee /mnt/efs/test.txt

# Verify it exists
ls -l /mnt/efs/
cat /mnt/efs/test.txt

Expected Output:

-rw-r--r-- 1 root root 13 Mar 10 12:34 test.txt
Hello, EFS!

4. ? Production-Ready Best Practices

? Security

• Enable encryption at rest (use --encrypted when creating EFS).
• Restrict NFS access with Security Groups (only allow EC2 instances on port 2049).
• Use IAM policies to restrict who can create/delete EFS volumes.
• Enable EFS Access Points for granular file permissions (e.g., different apps get different /data directories).

? Cost Optimization

• Use EFS IA for old files (enable lifecycle management).
• Monitor PercentIOLimit CloudWatch metric—if it’s >70%, consider Max I/O mode.
• Delete unused EFS volumes (they cost money even if empty).

? Reliability & Maintainability

• Deploy mount targets in multiple AZs (for high availability).
• Use efs-utils for mounting (handles TLS encryption and retries).
• Tag EFS volumes (e.g., Environment=Prod, App=MyApp).

? Observability

• Monitor these CloudWatch metrics:
• BurstCreditBalance (if using Bursting throughput mode).
• ClientConnections (how many EC2 instances are mounted).
• PermittedThroughput (if using Provisioned throughput).
• Set alarms for:
• PercentIOLimit > 80% (performance bottleneck).
• StorageBytes > 1TB (cost warning).

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (AWS SAA)

Typical Question Patterns

1. "You need shared storage for multiple EC2 instances across AZs. Which service?"
2. ✅ EFS (shared, multi-AZ, NFS).

3. ❌ EBS (single-instance), S3 (object storage, not file system).

4. "You have 1TB of logs, 90% of which are accessed once a month. How do you reduce costs?"

5. ✅ EFS IA + Lifecycle Management (moves old logs to cheaper storage).

6. ❌ Keep everything in EFS Standard (expensive).

7. "Your app needs 10,000 IOPS for shared storage. What do you use?"

8. ✅ EFS Max I/O (high throughput).
9. ❌ General Purpose (limited to 7,000 IOPS).

⚠️ Trap Distinctions

7. ? Hands-On Challenge (With Solution)

Challenge:
You have two EC2 instances in different AZs. You need to: 1. Create an EFS volume with lifecycle management (30 days → IA).
2. Mount it on both instances.
3. Verify that a file created on Instance A appears on Instance B.

Solution:
1. Create EFS:
bash
aws efs create-file-system --creation-token "challenge-efs" --encrypted --lifecycle-policies TransitionToIA=AFTER_30_DAYS 2. Create mount targets in both AZs.
3. Mount on both EC2 instances:
bash
sudo mount -t efs fs-12345678:/ /mnt/efs 4. Test:
```bash
# On Instance A:
echo "Hello from A" | sudo tee /mnt/efs/test.txt

# On Instance B:
cat /mnt/efs/test.txt # Should output "Hello from A"
``` Why it works:
EFS is shared storage—any file written by one instance is immediately visible to others.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. AWS EFS Documentation (Official guide)
2. EFS Lifecycle Management (How to save costs)
3. EFS Performance Best Practices (AWS Blog)
4. AWS Well-Architected Framework (Storage) (Best practices for EFS)

Final Thought

EFS is the only AWS service that gives you shared, scalable, multi-AZ file storage without managing servers. Use it for:
✅ Web apps (shared /uploads directory) ✅ CI/CD pipelines (shared workspace) ✅ Batch processing (shared input/output)

Avoid it for:
❌ Databases (use EBS or RDS) ❌ Static assets (use S3) ❌ Single-instance workloads (use EBS)

Now go mount an EFS volume and see it in action! ?