AWS EFS: Mounting Shared Files on EC2 with NFS, IAM, and TLS

Purpose of This Lesson

This hands-on lesson demonstrates how to create an Amazon Elastic File System (EFS), connect EC2 instances in separate Availability Zones, and verify that both instances can read and write the same files. It also shows why enforcing encryption in transit changes the required mounting approach.

The workflow covers:

• Creating security groups for EC2 management and EFS network access
• Launching EC2 instances in two Availability Zones
• Creating a regional EFS file system with mount targets
• Mounting EFS with the standard NFS client
• Verifying shared data across instances
• Enforcing encryption in transit with an EFS file system policy
• Switching to the Amazon EFS mount helper when TLS is required

Key Concepts

Amazon EFS and EC2

Amazon EFS provides a shared file system that EC2 instances can mount. Multiple instances can access the same file system concurrently, including instances located in different Availability Zones, as long as the network and authorization requirements are satisfied.

An EC2 instance mounts the file system at a local directory, called a mount point. Files created through that directory are stored in EFS and are visible from other successfully mounted clients.

Mount DNS and Mount Targets

EFS provides mount DNS names for connecting clients. Mount targets are created in specific Availability Zones and provide network access to the file system from subnets in those zones.

For a multi-AZ design, create mount targets in the Availability Zones where the clients need access. In the lab, mount targets were created in us-east-1a and us-east-1b.

NFS and Port 2049

EFS uses the Network File System (NFS) protocol. The relevant inbound security group rule allows TCP port 2049 from the EC2 instances’ security group.

The important security-group relationship is:

• The EFS mount targets use a security group that permits inbound NFS traffic.
• The source of that traffic is the security group attached to the EC2 instances.
• SSH access was also allowed from anywhere in the lab for instance management, but that is a separate administrative rule and is not the EFS data path.

IAM Authorization, Resource Policies, and TLS

EFS access can involve both:

• Identity-based policies attached to IAM roles used by NFS clients
• A resource-based file system policy on EFS

When IAM authorization or Transport Layer Security (TLS) is required, the Amazon EFS mount helper must be used. The standard NFS client alone is not sufficient for the configuration demonstrated in this lesson.

EFS Connectivity and Mount Workflow

1. Create the Security Group

The lab created a security group named EFS Lab. Two types of inbound access were configured:

• SSH access on port 22 for management
• NFS access on port 2049 from the EC2 instances’ security group

When reusing commands from the course materials, replace placeholder security group IDs with the actual ID returned when the security group is created. The ID must be updated everywhere it is referenced, including both EC2 launch commands and the EFS mount-target configuration.

2. Launch EC2 Instances in Separate Availability Zones

Two EC2 instances were launched using the current Amazon Linux Free Tier AMI. The instances were placed in different Availability Zones:

• us-east-1a
• us-east-1b

Using separate Availability Zones makes the shared-file-system behavior clear and demonstrates that both instances can access the same regional EFS file system.

3. Create the EFS File System

The lab used these EFS settings:

• A regional file system
• The default VPC, matching the EC2 instances
• Default automatic backups and lifecycle settings
• Encryption at rest left enabled by default
• Normal throughput
• Mount targets only in the two required Availability Zones
• The EFS Lab security group attached to those mount targets

Wait until the file system and its mount targets become available before attempting to mount the file system from EC2.

4. Prepare Each EC2 Instance

Create a local mount point on each instance, such as an EFS mount directory. The lab also installed or verified the NFS client utilities before mounting.

The lesson demonstrated two client approaches:

• The standard NFS client, using the file system’s mount DNS name
• The AWS-specific Amazon EFS mount helper, supplied by the EFS utilities

5. Mount EFS with the Standard NFS Client

The initial mount used an NFSv4 command containing:

• The mount command
• NFS version 4 options
• The EFS mount DNS name
• The required :/ suffix after the file system endpoint
• The local mount-point directory

The endpoint format is conceptually:

<efs-mount-dns-name>:/ <local-mount-point>

After mounting, changing to the mount-point directory and creating a test file verified that the file system was available. The second EC2 instance was then mounted to the same EFS file system, and the test file was visible there as well.

6. Enforce Encryption in Transit

The EFS file system policy was edited to enforce encryption in transit for all clients. After saving that policy, the existing mounts were unmounted from both instances.

A standard NFS mount attempt then failed with access denied. This behavior demonstrated that the original mounting method did not satisfy the enforced TLS requirement.

7. Install and Use the EFS Mount Helper

The Amazon EFS utilities were installed on both EC2 instances. The file system was then mounted using the EFS mount helper and the same EFS DNS endpoint.

After switching to the helper, both instances mounted the file system successfully and could again see the shared test data. The key operational rule is:

> If EFS IAM authorization or TLS is required, use the Amazon EFS mount helper rather than the standard NFS mounting approach.

Exam- or Assessment-Relevant Takeaways

• EFS clients connect through mount targets associated with Availability Zones and subnets.
• The EFS security group must allow NFS traffic on port 2049 from the EC2 clients’ security group.
• EFS mount targets should be created in the Availability Zones that require access.
• EFS supports shared access from multiple EC2 instances, including instances in different Availability Zones.
• A regional EFS file system is used in this multi-AZ scenario.
• IAM authorization and TLS require the Amazon EFS mount helper.
• Enforcing encryption in transit can cause a standard NFS mount to fail with access denied.
• Encryption at rest and encryption in transit are separate considerations. The lab left encryption at rest enabled and later enforced encryption in transit with a file system policy.
• The EFS mount helper is AWS-specific, while the standard NFS client is a general NFS tool.

Tool / Feature Decision Guide

Requirement or situation	Recommended approach	Reason
Basic EFS mounting without the demonstrated IAM/TLS requirements	Standard NFS client	It can mount the EFS endpoint using NFSv4.
IAM authorization for the NFS client	Amazon EFS mount helper	The lesson specifies that IAM authorization requires the helper.
TLS or encryption in transit is enforced by the EFS policy	Amazon EFS mount helper	A standard NFS mount fails after TLS enforcement; the helper performs the required TLS-aware mount.
EC2 clients in multiple Availability Zones	Regional EFS with mount targets in the required AZs	Each client needs appropriate network access through the EFS mount-target design.
Restricting EFS network access	Security group rule allowing port 2049 from the EC2 security group	This limits NFS access to the intended client group rather than allowing unrestricted NFS traffic.

Common Traps / Misconceptions

• Confusing the EFS file system with its mount targets: The file system is the shared storage resource; mount targets provide network connectivity in selected Availability Zones.
• Opening the wrong port: EFS NFS access uses port 2049, not SSH port 22. Port 22 was used only for lab administration.
• Using the wrong security-group source: The EFS rule should allow port 2049 from the EC2 instances’ security group.
• Assuming one mount target automatically covers every AZ: The lab explicitly created mount targets in both us-east-1a and us-east-1b.
• Forgetting the :/ endpoint suffix: The mount command uses the EFS endpoint followed by a colon and slash before the local mount point.
• Trying the original NFS command after enabling TLS: Once encryption in transit is enforced, the standard command can return access denied.
• Assuming EFS utilities are interchangeable with the generic NFS client: The EFS utilities provide the AWS-specific mount helper required for the IAM/TLS scenario.
• Mounting before the file system is available: Creation of the file system and mount targets must finish before the client mount is attempted.
• Treating a temporary EC2 connection problem as an EFS failure: The lab experienced an instance-connect issue that was resolved by checking the instance and rebooting it; this was separate from EFS mounting.

Real-World Engineer / Analyst Notes

• Keep track of which EC2 instance is in each Availability Zone while testing. Clear labeling helps distinguish an AZ-specific connectivity issue from a shared-storage issue.
• Validate the EFS network configuration before troubleshooting client commands: VPC, subnet, mount-target availability, and security group rules are foundational.
• Test shared behavior with a small file created on one client and read from another. This confirms that both clients are attached to the same EFS file system rather than merely having local directories with the same name.
• Use the actual security group ID and current AMI ID when adapting lab commands. Placeholder IDs and outdated AMI references are common causes of failed setup commands.
• After changing an EFS file system policy, unmount and remount clients so the new access requirements are exercised.
• A successful mount command with no error is not the only validation step; inspect the mount-point contents and verify cross-instance visibility.
• Clean up temporary resources after the exercise by terminating the EC2 instances and deleting the EFS file system.

Quick Reference Summary

• EFS protocol: NFS
• NFS port: 2049
• Administrative access in the lab: SSH on port 22
• Client resources: EC2 instances in us-east-1a and us-east-1b
• Storage design: Regional EFS file system
• Network design: EFS mount targets in the required AZs, using the EFS lab security group
• Basic mounting: Standard NFS client with the EFS mount DNS name and :/
• IAM or TLS mounting: Amazon EFS mount helper from the EFS utilities
• TLS enforcement result: Standard NFS mounting fails with access denied; helper-based mounting succeeds
• Shared-data test: Create a file on one instance and confirm it appears on the other

Flashcards

Q: An EC2 instance must mount EFS, and the EFS mount target’s security group currently allows only SSH. What network change is required?

A: Allow NFS traffic on port 2049 from the EC2 instances’ security group. SSH on port 22 does not provide EFS data access.

Q: Why create EFS mount targets in both Availability Zones used by the lab instances?

A: Mount targets provide network access to EFS in specific Availability Zones. Creating them in both client AZs supports the intended multi-AZ connectivity design.

Q: Two EC2 instances in different Availability Zones both mount the same EFS file system. What should happen when one creates a file in the mounted directory?

A: The other instance should be able to see the same file because both clients are accessing the same shared EFS file system.

Q: Which mounting approach should be selected when an EFS file system policy enforces encryption in transit?

A: Use the Amazon EFS mount helper. The standard NFS mount used initially fails with access denied after TLS is enforced.

Q: What is the decisive difference between the standard NFS client and the EFS mount helper in this lesson?

A: The standard NFS client is general-purpose, while the EFS mount helper is AWS-specific and required for the demonstrated IAM authorization and TLS scenarios.

Q: What does the :/ portion of the EFS mount source represent in the mount command?

A: It follows the EFS mount DNS name as part of the NFS source syntax before the local mount-point path.

Q: An EFS file system exists, but a client cannot mount it immediately after creation. What should be checked first?

A: Confirm that the file system and its mount targets have become available. The lab waited for this state before mounting.

Q: Which two policy mechanisms can be used to control EFS access in the lesson?

A: IAM identity-based policies associated with client roles and a resource-based policy on the EFS file system.

Q: What happened when the lab tried the original NFS mount after enabling the EFS policy that enforced TLS?

A: The mount returned access denied, showing that the original client method did not meet the new encryption-in-transit requirement.

Q: What is the purpose of the local EFS mount point on an EC2 instance?

A: It is the directory through which the operating system accesses the mounted EFS file system. Files created there are stored in shared EFS storage.

Q: Why should the EFS security group rule use the EC2 security group as its source instead of an unrestricted source?

A: Referencing the EC2 security group limits NFS access to the intended client instances and avoids exposing port 2049 broadly.

Q: In the lab, what separate purposes did ports 22 and 2049 serve?

A: Port 22 supported SSH-based instance management, while port 2049 carried NFS traffic between EC2 clients and EFS.

Practice Questions

Question 1

An operations team enables an EFS file system policy that requires encryption in transit. Existing clients were mounted with a standard NFSv4 command, and remount attempts now return access denied. What is the best next step?

A. Open SSH port 22 on the EFS security group
B. Create another EFS file system in the same VPC
C. Install the Amazon EFS utilities and mount with the EFS mount helper
D. Remove all EFS mount targets and recreate them

Correct answer: C

The decisive clue is the TLS requirement. The lesson requires the EFS mount helper for TLS, while the standard NFS approach fails after encryption in transit is enforced.

Question 2

Two EC2 instances are in us-east-1a and us-east-1b. Both need to access a regional EFS file system. Which configuration best supports the stated design?

A. One mount target in an unrelated Availability Zone and an open SSH rule
B. Mount targets in both required Availability Zones with NFS access from the EC2 security group
C. One mount target only, with port 22 allowed from the EC2 security group
D. Two independent EBS volumes, one attached to each instance

Correct answer: B

The lab created mount targets in both client Availability Zones and allowed port 2049 from the EC2 security group. EBS volumes do not provide the demonstrated shared EFS behavior.

Question 3

An engineer can connect to an EC2 instance using Instance Connect but receives an error when mounting EFS. The EFS mount target is available, but its security group does not allow inbound traffic from the instance security group. What is the most likely correction?

A. Add an inbound port 2049 rule sourced from the EC2 security group
B. Add an inbound port 443 rule sourced from anywhere
C. Enable automatic backups on the EC2 instance
D. Move both instances into the same Availability Zone

Correct answer: A

EFS uses NFS on port 2049. The EFS security group must permit that port from the EC2 clients’ security group.

Question 4

A test file created through the EFS mount on an instance in us-east-1a is visible from an instance in us-east-1b. What does this verify?

A. The instances are using separate local directories with synchronized names
B. The instances are reading and writing to the same mounted EFS file system
C. SSH traffic is being shared between the instances
D. The EC2 instances have automatically replicated their root volumes

Correct answer: B

The shared file’s visibility from both clients confirms that both instances are accessing the same EFS storage.

Question 5

A learner copies the lab commands but leaves the placeholder security group ID in the EC2 launch and EFS configuration commands. Which result is most likely?

A. The commands may reference the wrong or nonexistent security group, preventing the intended access configuration
B. EFS automatically replaces the placeholder with the correct ID
C. The placeholder affects only encryption at rest and not networking
D. The AMI ID is automatically corrected by the security group reference

Correct answer: A

The lab explicitly replaced the fake group ID with the actual ID returned during security-group creation. Failing to do so can break the intended EC2 and EFS network setup.

WordPress Metadata

Suggested Slug:
aws-efs-mount-files-ec2-nfs-tls

Meta Description:
Learn how to connect EC2 instances across Availability Zones to Amazon EFS, configure NFS security, enforce TLS, and choose the correct mount method.

Tags:
AWS EFS, Amazon EC2, NFS, EFS mount helper, TLS, IAM authorization, security groups, Availability Zones, AWS CloudOps, shared file systems