DEV Community

Tejas Shinkar
Tejas Shinkar

Posted on

AWS EFS Hands-On Lab

#aws #cloud #devops #sideprojects

A practical EFS exercise covering shared file access, NFS security, lifecycle management, persistent mounts, and an EBS-vs-EFS copy experiment.

Problem Statement

Build and validate a shared Amazon EFS filesystem that can be mounted by multiple EC2 instances in the same VPC.

The lab was designed to verify the setup through actual hands-on tests:

  • Mount the same EFS filesystem on two EC2 instances.
  • Prove that a file written by one instance is visible from the other.
  • Deliberately remove NFS access and observe the failure.
  • Configure EFS Lifecycle Management for a 7-day transition to Infrequent Access.
  • Make the EFS mount persistent across an EC2 reboot using /etc/fstab.
  • Compare a copy to local EBS-backed storage with a copy to EFS.

Lab Architecture 

                         Default VPC
        ┌─────────────────────────────────────────────┐
        │                                             │
        │   EC2-1                 EC2-2              │
        │   /mnt/efs              /mnt/efs            │
        │      │                     │                │
        │      └────── NFS :2049 ────┘                │
        │                     │                       │
        │              EFS Mount Targets              │
        │                     │                       │
        │                Amazon EFS                   │
        │                                             │
        └─────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Security Groups:

  • ec2-sg — SSH (22) from My IP
  • efs-sg — NFS (2049) from ec2-sg

EFS used (EFS_LAB, File System ID fs-083c15edb9f9076c7) was created in the same VPC as the EC2 instances, with mount targets available across the VPC's Availability Zones.

Lab Setup — Two EC2 Instances + One Shared EFS

Two Amazon Linux 2023 EC2 instances (EC2-1, EC2-2) were used. Both were associated with ec2-sg. The EFS filesystem used efs-sg.

Security rules:

  • ec2-sg inbound: SSH/TCP 22 from My IP
  • efs-sg inbound: NFS/TCP 2049 from ec2-sg

The EFS NFS rule was intentionally restricted to the EC2 security group instead of opening port 2049 broadly.

On both instances:

sudo yum update -y
sudo yum install -y amazon-efs-utils
sudo mkdir -p /mnt/efs
Enter fullscreen mode Exit fullscreen mode

EFS was mounted with:

sudo mount -t efs fs-083c15edb9f9076c7:/ /mnt/efs
Enter fullscreen mode Exit fullscreen mode

The mount was verified with:

df -h | grep efs
Enter fullscreen mode Exit fullscreen mode

Shared-File Test — EC2-1 Writes, EC2-2 Reads

On EC2-1:

echo "Hello from EC2-1" | sudo tee /mnt/efs/shared-file.txt
Enter fullscreen mode Exit fullscreen mode

On EC2-2:

cat /mnt/efs/shared-file.txt
Enter fullscreen mode Exit fullscreen mode

Output:

Hello from EC2-1
Enter fullscreen mode Exit fullscreen mode

This proved that both instances were using the same EFS filesystem:

EC2-1 writes → EFS (same filesystem) → EC2-2 reads

No manual file transfer between the EC2 instances was performed.

Failure Test — Remove NFS Access and Break the EFS Write

The NFS 2049 inbound rule was deliberately removed from efs-sg.

A new file write was attempted:

echo "Dummy text check from EC2-1" | sudo tee /mnt/efs/shared-file2.txt
Enter fullscreen mode Exit fullscreen mode

The operation could not complete while NFS access was blocked.

The NFS rule was restored (NFS TCP 2049 from ec2-sg). The same write was repeated successfully:

Dummy text check from EC2-1
Enter fullscreen mode Exit fullscreen mode

This demonstrated that the mount directory can remain present while network access to the EFS service is blocked.

Lifecycle Management — Configure 7-Day IA Transition

EFS Lifecycle Management was configured as:

  • Transition into Infrequent Access (IA): 7 days since last access
  • Transition into Archive: 90 days since last access (existing setting, unchanged)
  • Transition into Standard: None (existing setting, unchanged)

The 7-day IA policy was successfully configured.

The actual movement of a file into IA was not observed, because the lab did not wait seven days. The documentation therefore records the configuration rather than claiming an observed storage-class transition.

Persistent Mount Test — /etc/fstab

Two different behaviors were demonstrated.

EC2-1 — Manual Mount Only

EC2-1 was manually unmounted:

sudo umount /mnt/efs
Enter fullscreen mode Exit fullscreen mode

The mount was checked:

mount | grep efs
Enter fullscreen mode Exit fullscreen mode

No EFS mount remained.

After:

sudo reboot
Enter fullscreen mode Exit fullscreen mode

the EFS filesystem did not automatically return because no EFS entry existed in /etc/fstab.

EC2-2 — Persistent Mount

The existing /etc/fstab was inspected:

cat /etc/fstab
Enter fullscreen mode Exit fullscreen mode

There was no EFS entry initially. The following entry was added:

sudo sh -c 'echo "fs-083c15edb9f9076c7:/ /mnt/efs efs _netdev,tls 0 0" >> /etc/fstab'
Enter fullscreen mode Exit fullscreen mode

Before rebooting, the configuration was tested safely. The existing mount was removed:

sudo umount /mnt/efs
Enter fullscreen mode Exit fullscreen mode

Then /etc/fstab was applied:

sudo mount -a
Enter fullscreen mode Exit fullscreen mode

The mount was verified:

mount | grep efs
Enter fullscreen mode Exit fullscreen mode

After the test succeeded, EC2-2 was rebooted:

sudo reboot
Enter fullscreen mode Exit fullscreen mode

After reconnecting:

mount | grep efs
Enter fullscreen mode Exit fullscreen mode

showed that EFS was automatically mounted.

The shared file was also still accessible:

cat /mnt/efs/shared-file.txt
Enter fullscreen mode Exit fullscreen mode

Output:

Hello from EC2-1
Enter fullscreen mode Exit fullscreen mode

The final proof was therefore:

/etc/fstab → EC2 reboot → EFS automatically mounted → existing shared data available

EBS vs EFS Copy Experiment

Before the benchmark:

df -h /
df -h /mnt/efs
Enter fullscreen mode Exit fullscreen mode

The root EBS filesystem had approximately 8.0 GB total, 1.8 GB used, and 6.3 GB available.

Initial /tmp Problem

The first attempt created the test file under /tmp:

dd if=/dev/zero of=/tmp/efs-ebs-test-1GB.img bs=1M count=1024 status=progress
Enter fullscreen mode Exit fullscreen mode

It failed with:

No space left on device
Enter fullscreen mode Exit fullscreen mode

Only about 479 MB was written.

The cause was identified with:

df -h /tmp
Enter fullscreen mode Exit fullscreen mode

which showed:

tmpfs   457M   457M   0   100%   /tmp
Enter fullscreen mode Exit fullscreen mode

So /tmp was a 457 MB tmpfs, not the EBS-backed root filesystem.

The incomplete file was removed and the test moved to /home/ec2-user.

Create the 1 GiB Test File on EBS 

dd if=/dev/zero \
  of=/home/ec2-user/efs-ebs-test-1GB.img \
  bs=1M count=1024 \
  status=progress
Enter fullscreen mode Exit fullscreen mode

The resulting file was approximately 1.0 GiB.

EBS → EBS 

time cp \
  /home/ec2-user/efs-ebs-test-1GB.img \
  /home/ec2-user/efs-ebs-test-1GB-copy.img
Enter fullscreen mode Exit fullscreen mode

Observed:

real    0m0.005s
user    0m0.000s
sys     0m0.002s
Enter fullscreen mode Exit fullscreen mode

The copy succeeded.

This was not treated as a physical 1 GiB EBS throughput benchmark, because filesystem/page caching can make a local repeated copy appear extremely fast.

EBS → EFS

The EBS copy was removed.

The first EFS copy attempt without elevated privileges failed:

cp: cannot create regular file ... Permission denied
Enter fullscreen mode Exit fullscreen mode

The EFS mount itself was working; the issue was filesystem write permission.

The copy was repeated with sudo:

time sudo cp \
  /home/ec2-user/efs-ebs-test-1GB.img \
  /mnt/efs/efs-ebs-test-1GB-copy.img
Enter fullscreen mode Exit fullscreen mode

Observed:

real    0m7.506s
user    0m0.037s
sys     0m0.010s
Enter fullscreen mode Exit fullscreen mode

The destination file was verified successfully on EFS.

Benchmark Interpretation

EBS → EBS: ~0.005 seconds

EBS → EFS: ~7.506 seconds

These numbers should not be presented as a universal EBS-vs-EFS performance ratio.

The local EBS result was affected by filesystem/page caching and is not equivalent to a cold physical-storage benchmark.

The useful architectural observation is that EFS introduces network filesystem behavior, while EBS provides block storage directly associated with the EC2 workload.

Problems Encountered and Fixes

Problem What Happened Resolution
EFS write stopped after NFS rule removal Network access to EFS was blocked Restored TCP 2049 from ec2-sg to efs-sg
EFS did not persist after manual unmount/reboot No EFS entry existed in /etc/fstab Added the EFS mount configuration to /etc/fstab
grep failed after reboot Verification commands were entered in Windows PowerShell rather than Linux Reconnected to EC2 through SSH
1 GiB test file failed under /tmp /tmp was a 457 MB tmpfs Created the test file under /home/ec2-user
EFS copy returned Permission denied Current user lacked write permission at the EFS root Repeated the copy using sudo
EBS copy timing looked unrealistically fast Local filesystem/page caching affected cp Treated it as an observed lab result, not a production benchmark

Evidence Collected

  • Two EC2 instances successfully mounted the same EFS filesystem.
  • EC2-1 wrote shared-file.txt.
  • EC2-2 read the same file and returned Hello from EC2-1.
  • Removing NFS 2049 access prevented the EFS write from completing.
  • Restoring the NFS rule allowed the write again.
  • EFS Lifecycle Management was configured for a 7-day IA transition.
  • EC2-1 demonstrated that a manual mount does not persist after reboot.
  • EC2-2 automatically remounted EFS after reboot through /etc/fstab.
  • The shared file remained accessible after reboot.
  • A 1 GiB file was successfully copied to EFS.
  • The EBS-to-EFS copy completed in approximately 7.5 seconds in this lab environment.

Production-Relevant Takeaways

  • Restrict EFS NFS access by security group instead of exposing TCP 2049 broadly.
  • Use mount -a to validate an /etc/fstab change before rebooting an instance.
  • Use _netdev for persistent network filesystem mounts.
  • Separate network connectivity from filesystem permissions when troubleshooting EFS.
  • Use Lifecycle Management according to actual access patterns rather than assuming every file belongs in Standard storage.
  • EFS is appropriate when multiple compute resources need concurrent access to the same file system; EBS is appropriate for block-storage workloads attached to EC2.
  • Do not use a simple cp test as a production storage benchmark. Caching, EC2 instance type, EBS configuration, EFS throughput mode, network conditions, file size, and workload characteristics all affect the result.
  • Check what filesystem actually backs a directory before using it for storage tests; /tmp in this lab was a tmpfs.
  • Clean up EFS, EC2, security groups, and test files after the lab to avoid unnecessary charges.

Lab Completion

  1. Full EC2 + EFS shared filesystem lab ✅
  2. Break and restore NFS access ✅
  3. Configure 7-day EFS IA lifecycle policy ✅
  4. Persist EFS mount through EC2 reboot ✅
  5. EBS vs EFS copy experiment ✅

The lab went beyond a successful service setup: it included deliberate failure, troubleshooting, permissions, persistence testing, filesystem identification, lifecycle configuration, and a controlled storage experiment.

Top comments (0)