AWS EFS Hands-On Lab

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                   │
        │                                             │
        └─────────────────────────────────────────────┘

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

EFS was mounted with:

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

The mount was verified with:

df -h | grep efs

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

On EC2-1:

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

On EC2-2:

cat /mnt/efs/shared-file.txt

Output:

Hello from EC2-1

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

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

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

The mount was checked:

mount | grep efs

No EFS mount remained.

After:

sudo reboot

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

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'

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

sudo umount /mnt/efs

Then /etc/fstab was applied:

sudo mount -a

The mount was verified:

mount | grep efs

After the test succeeded, EC2-2 was rebooted:

sudo reboot

After reconnecting:

mount | grep efs

showed that EFS was automatically mounted.

The shared file was also still accessible:

cat /mnt/efs/shared-file.txt

Output:

Hello from EC2-1

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

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

It failed with:

No space left on device

Only about 479 MB was written.

The cause was identified with:

df -h /tmp

which showed:

tmpfs   457M   457M   0   100%   /tmp

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

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

Observed:

real    0m0.005s
user    0m0.000s
sys     0m0.002s

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

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

Observed:

real    0m7.506s
user    0m0.037s
sys     0m0.010s

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

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.