DEV Community

Tejas Shinkar
Tejas Shinkar

Posted on Edited on

AWS EFS Hands-On Lab

#aws #cloud #devops #sideprojects

A practical project validating Amazon EFS as shared storage across multiple EC2 instances — covering NFS security, lifecycle management, persistent mounts, and a comparative EBS-vs-EFS copy test.

Objective

Build and validate a shared Amazon EFS filesystem mounted by multiple EC2 instances in the same VPC, proving each of the following through hands-on testing rather than configuration alone:

  • A file written by one instance is immediately visible from another.
  • Removing NFS network access breaks writes, and restoring it recovers them.
  • EFS Lifecycle Management can be configured to transition infrequently accessed data to a cheaper storage class.
  • An EFS mount can be made persistent across an EC2 reboot using /etc/fstab.
  • A copy to EFS behaves differently from a copy to local EBS-backed storage.

Architecture 

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

Two Amazon Linux 2023 instances (EC2-1, EC2-2) shared one EFS filesystem (EFS_LAB, File System ID fs-083c15edb9f9076c7), with mount targets available across the VPC's Availability Zones. Access was scoped tightly by security group rather than opening the NFS port broadly:

  • ec2-sg — inbound SSH/TCP 22 from My IP; attached to both EC2 instances
  • efs-sg — inbound NFS/TCP 2049 from ec2-sg only; attached to the EFS mount targets

Step 1 — Environment Setup

On both EC2-1 and EC2-2, the NFS client utilities were installed, a mount point created, the filesystem mounted, and the mount verified:

sudo yum update -y
sudo yum install -y amazon-efs-utils
sudo mkdir -p /mnt/efs

sudo mount -t efs fs-083c15edb9f9076c7:/ /mnt/efs

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

Both instances confirmed the EFS mount was active before moving on to the shared-access test.

Step 2 — Shared File Access Test

To prove both instances were genuinely using the same filesystem — not two independent local directories — EC2-1 wrote a file and EC2-2 read it back without any manual transfer between the two:

# On EC2-1
echo "Hello from EC2-1" | sudo tee /mnt/efs/shared-file.txt

# On EC2-2
cat /mnt/efs/shared-file.txt
Enter fullscreen mode Exit fullscreen mode 
Hello from EC2-1
Enter fullscreen mode Exit fullscreen mode

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

Step 3 — Security Failure Test

The NFS 2049 inbound rule was deliberately removed from efs-sg to observe the failure mode, then restored:

# With NFS 2049 blocked — write does not complete
echo "Dummy text check from EC2-1" | sudo tee /mnt/efs/shared-file2.txt

# After restoring NFS TCP 2049 from ec2-sg — the same write succeeds
echo "Dummy text check from EC2-1" | sudo tee /mnt/efs/shared-file2.txt
Enter fullscreen mode Exit fullscreen mode 
Dummy text check from EC2-1
Enter fullscreen mode Exit fullscreen mode

The mount directory remained present throughout — the failure was purely a network access issue, not a filesystem or client-configuration problem, confirming that network connectivity and filesystem permissions are two separate things to check when troubleshooting EFS.

Step 4 — Lifecycle Management Configuration

EFS Lifecycle Management was configured with:

  • 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 applied. The actual storage-class transition was not observed within the lab, since that requires waiting the full seven days — this step documents the configuration rather than an observed transition.

Step 5 — Persistent Mounts Across Reboot

The same test was run on both instances with opposite /etc/fstab configurations, to demonstrate that the mount itself does not survive a reboot unless it's explicitly declared.

EC2-1 — manual mount only, no persistence:

sudo umount /mnt/efs
mount | grep efs        # no output — mount removed

sudo reboot
# after reconnecting:
mount | grep efs        # still no output — EFS did not return automatically
Enter fullscreen mode Exit fullscreen mode

EC2-2 — persistent mount via /etc/fstab:

cat /etc/fstab           # no EFS entry present initially

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

# validate the new entry before rebooting
sudo umount /mnt/efs
sudo mount -a
mount | grep efs         # confirms the fstab entry mounts correctly

sudo reboot
# after reconnecting:
mount | grep efs         # EFS automatically mounted
cat /mnt/efs/shared-file.txt
Enter fullscreen mode Exit fullscreen mode 
Hello from EC2-1
Enter fullscreen mode Exit fullscreen mode

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

EC2-1 confirmed that a manual mount is lost on reboot; EC2-2 confirmed that an _netdev,tls entry in /etc/fstab restores it automatically, with no data loss in between.

Step 6 — EBS vs EFS Copy Comparison

Before benchmarking, the available space on both filesystems was checked:

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.

The first attempt to generate a 1 GiB test file under /tmp failed partway through:

dd if=/dev/zero of=/tmp/efs-ebs-test-1GB.img bs=1M count=1024 status=progress
df -h /tmp
Enter fullscreen mode Exit fullscreen mode 
No space left on device
tmpfs   457M   457M   0   100%   /tmp
Enter fullscreen mode Exit fullscreen mode

/tmp turned out to be a 457 MB tmpfs, not the EBS-backed root filesystem — so the test file was recreated under /home/ec2-user instead, and the copy comparison run from there:

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

# EBS -> EBS
time cp /home/ec2-user/efs-ebs-test-1GB.img /home/ec2-user/efs-ebs-test-1GB-copy.img

# EBS -> EFS (first attempt without sudo failed: Permission denied at the EFS root)
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 
EBS → EBS    real  0m0.005s
EBS → EFS    real  0m7.506s
Enter fullscreen mode Exit fullscreen mode

These numbers are not a valid EBS-vs-EFS performance benchmark — the near-instant EBS→EBS result reflects filesystem/page caching on a repeated local copy, not real disk throughput. The useful architectural takeaway is qualitative: EFS introduces genuine network filesystem behavior, while EBS is block storage directly attached to the instance, and the two are not interchangeable for performance-sensitive workloads without a properly controlled benchmark.

Troubleshooting Summary

Problem Cause 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 appeared to fail 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 as an observed lab result, not a production benchmark

Key Takeaways

  • Two EC2 instances mounted the same EFS filesystem and shared data with no manual file transfer.
  • Removing and restoring NFS access directly demonstrated that EFS access failures can be purely network-layer, independent of filesystem permissions.
  • A manual mount does not survive a reboot; _netdev,tls in /etc/fstab does — and should always be validated with mount -a before rebooting.
  • Restrict EFS NFS access by security group rather than opening TCP 2049 broadly.
  • Use Lifecycle Management according to actual access patterns rather than assuming every file belongs in Standard storage.
  • EFS suits workloads where multiple compute resources need concurrent access to the same filesystem; EBS suits block-storage workloads tied to a single EC2 instance.
  • Always confirm what actually backs a directory (df -h) before using it for a storage test — /tmp in this lab was a tmpfs, not EBS.
  • A simple cp timing test is not a valid production storage benchmark; caching, instance type, EBS configuration, EFS throughput mode, network conditions, and file size all affect the result.
  • Clean up EFS, EC2, security groups, and test files after the lab to avoid unnecessary charges.

Top comments (0)