How to Attach Amazon EFS in EC2 Launch Wizard?

Attaching an Amazon Elastic File System directly during the Amazon EC2 launch instance wizard automates package installation, directory creation, and file system table configuration without manual scripting. When you select an existing shared file system or create a new one in the storage configuration section of the wizard, AWS automatically generates and injects a cloud-init user data script into the instance. This script installs the required amazon-efs-utils helper package, creates the local mount point directory, appends the persistent mount entry to the fstab file using recommended network options, and mounts the file system at first boot. It also optionally creates and associates the security groups needed to permit Network File System traffic on port 2049 between your compute instance and the file system mount targets.

Prerequisites for Automated EFS Mounting

Before using the EC2 launch wizard to attach an EFS file system, your environment and chosen configuration must meet specific networking and operating system requirements:

  1. Supported Amazon Machine Image (AMI): The automated user data script relies on cloud-init and the amazon-efs-utils package. Supported Linux distributions include Amazon Linux 2023, Amazon Linux 2, Red Hat Enterprise Linux (RHEL), CentOS, Ubuntu, and SUSE Linux Enterprise Server.
  2. Same Virtual Private Cloud (VPC): The EC2 instance and the EFS file system must reside in the same VPC.
  3. Mount Target Availability: The EFS file system must have an active mount target in the Availability Zone where you launch the EC2 instance (or you must allow the wizard to create a new file system with regional mount targets).
  4. DNS Settings: The VPC must have both enableDnsHostnames and enableDnsSupport set to true so the instance can resolve the EFS file system DNS name (fs-xxxxxxxx.efs.region.amazonaws.com).

Step-by-Step Guide to Attaching EFS in the EC2 Launch Wizard

Follow these steps in the AWS Management Console to attach an EFS file system and automate /etc/fstab configuration during instance creation:

1. Configure Basic Instance and Network Settings

  1. Open the Amazon EC2 console and choose Launch instances.
  2. Enter a name for your instance and select a supported Linux AMI (such as Amazon Linux 2023).
  3. Select an instance type and a key pair for SSH or AWS Systems Manager Session Manager access.
  4. In the Network settings section, click Edit:
    • Select the VPC that contains (or will contain) your EFS file system.
    • Select the target Subnet. Ensure an EFS mount target exists in the Availability Zone associated with this subnet.

2. Add the EFS File System in Configure Storage

  1. Scroll down to the Configure storage section.
  2. Locate the File systems subsection (Directly below the EBS root volume configuration) and click Edit if it is not already expanded.
  3. Ensure the EFS tab is selected and click Add shared file system (or Create file system if you do not have an existing one).
  4. Configure the attachment options:
    • File system: Select your existing EFS file system from the dropdown list.
    • Mount point: Specify the absolute path on the EC2 instance where the file system will be mounted. By default, AWS assigns /mnt/efs/fs1.
    • Automatically create and attach security groups: Keep this box checked to have AWS automatically create and assign client and mount target security groups that allow inbound and outbound TCP traffic on port \(2049\).
    • Automatically mount shared file system by attaching required user data script: Keep this box checked. This option automates the /etc/fstab configuration and initial mount process.
    • Encryption in transit: Check this box (enabled by default) to mount the file system using Transport Layer Security (TLS) via the efs mount helper.

3. Review Generated User Data and Launch

If you expand the Advanced details section at the bottom of the launch wizard and scroll to User data, you can inspect the exact cloud-init configuration generated by the wizard. Click Launch instance to provision the instance.

How the Automated User Data Script Works

When you enable automatic mounting in the wizard, EC2 injects a multi-part cloud-init configuration into the instance user data. Below is an example of the configuration generated for an EFS file system with ID fs-0123456789abcdef0 mounted at /mnt/efs/fs1:

#cloud-config
package_update: true
package_upgrade: true
runcmd:
- yum install -y amazon-efs-utils
- apt-get -y install amazon-efs-utils
- yum install -y nfs-utils
- apt-get -y install nfs-common
- file_system_id_1=fs-0123456789abcdef0
- efs_mount_point_1=/mnt/efs/fs1
- mkdir -p "${efs_mount_point_1}"
- test -f "/sbin/mount.efs" && printf "\n${file_system_id_1}:/ ${efs_mount_point_1} efs tls,_netdev\n" >> /etc/fstab || printf "\n${file_system_id_1}.efs.us-east-1.amazonaws.com:/ ${efs_mount_point_1} nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev 0 0\n" >> /etc/fstab
- test -f "/sbin/mount.efs" && grep -ozP 'client-info]\nsource' '/etc/amazon/efs/efs-utils.conf'; if [ $? == 1 ]; then printf "\n[client-info]\nsource=ec2\n" >> /etc/amazon/efs/efs-utils.conf; fi;
- retryCnt=15; waitTime=30; while true; do mount -a -t efs,nfs4 defaults; if [ $? = 0 ] || [ $retryCnt -lt 1 ]; then echo File system mounted successfully; break; fi; echo File system not available, retrying to mount.; ((retryCnt--)); sleep $waitTime; done;

Breakdown of the /etc/fstab Entry and Mount Parameters

The script checks for the presence of /sbin/mount.efs (installed by amazon-efs-utils). Depending on whether the helper is available, it appends one of two lines to /etc/fstab:

  1. With EFS Mount Helper (/sbin/mount.efs present):

    fs-0123456789abcdef0:/ /mnt/efs/fs1 efs tls,_netdev
    • efs: Uses the amazon-efs-utils mount helper type.
    • tls: Enforces encryption of data in transit using TLS \(1.2\) or higher.
    • _netdev: Prevents the operating system from attempting to mount the file system until networking has been enabled on the instance, avoiding boot hangs.

  2. Fallback to Standard NFSv4.1 (/sbin/mount.efs absent):

    fs-0123456789abcdef0.efs.us-east-1.amazonaws.com:/ /mnt/efs/fs1 nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev 0 0
    • rsize=1048576 and wsize=1048576: Sets the maximum read and write buffer sizes to \(2^{20} = 1048576\text{ bytes}\) (\(1\text{ MiB}\)) for optimal throughput.
    • hard: Ensures that if the EFS mount target becomes temporarily unreachable, I/O operations retry indefinitely rather than failing and corrupting application data.
    • timeo=600: Sets the timeout duration to \(600\text{ deciseconds}\) (\(60\text{ seconds}\)) before retrying an NFS request.
    • retrans=2: Sets the number of retries to \(2\) before alerting that the server is not responding.
    • noresvport: Instructs the NFS client to use a new ephemeral TCP source port if a network reconnection occurs, ensuring uninterrupted availability after a recovery event.

The retry loop at the end of the runcmd block attempts to run mount -a -t efs,nfs4 defaults up to \(N = 15\) times with a delay of \(\Delta t = 30\text{ seconds}\) between attempts, allowing a maximum wait window of:

\[T_{\text{max}} = N \times \Delta t = 15 \times 30\text{ s} = 450\text{ seconds}\]

This \(7.5\text{-minute}\) window ensures that even if a brand-new EFS file system and its mount targets are still initializing when the EC2 instance finishes booting, the mount command will succeed as soon as the mount target transitions to the available state.

Verifying the Mount and /etc/fstab Configuration

Once your EC2 instance is running, connect to it via SSH or Session Manager and run the following commands to verify the setup:

  1. Check that the file system is mounted:

    df -hT /mnt/efs/fs1

    You should see /mnt/efs/fs1 mounted with type nfs4 (both mount.efs with TLS and standard NFS mounts report nfs4 in df).

  2. Verify the /etc/fstab entry:

    cat /etc/fstab

    Confirm that the line fs-xxxxxxxxxxxxxxxxx:/ /mnt/efs/fs1 efs tls,_netdev is present at the bottom of the file.

  3. Test reboot persistence without rebooting:

    sudo umount /mnt/efs/fs1
sudo mount -av

    If mount -av remounts /mnt/efs/fs1 without errors, your /etc/fstab configuration is valid and will persist across instance stops, starts, and reboots.

  4. Check cloud-init logs if the mount failed: If /mnt/efs/fs1 is empty or unmounted right after launch, inspect the execution log to diagnose package installation or security group connectivity issues:

    sudo cat /var/log/cloud-init-output.log