EFS Multi-AZ Mount Targets

Amazon EFS is a fully managed, scalable, and elastic NFS file system for use with AWS EC2 instances and on-premises servers via AWS Direct Connect or VPN. It is designed to provide shared file storage that can be accessed concurrently by thousands of EC2 instances. By default, when you create an EFS file system, you specify a set of Availability Zones (AZs) where mount targets will be created. A mount target is an NFS endpoint in a specific subnet within an AZ. For high availability, you should create mount targets in multiple AZs. This ensures that if an AZ becomes unavailable, instances in other AZs can still access the file system through their local mount target. The EFS file system itself is replicated across all AZs in the region automatically — this is not something you configure; it is inherent to EFS. The data is stored redundantly across multiple AZs, providing 99.999999999% (11 nines) durability and 99.99% availability for Standard storage classes.

When you create an EFS file system, you choose a region. AWS automatically replicates the data across multiple AZs within that region. You then create mount targets in specific subnets. Each mount target is an elastic network interface (ENI) in that subnet with a private IP address. EC2 instances in the same VPC can mount the EFS file system by connecting to any mount target. The NFS protocol (version 4.1 or 4.0) is used. When an instance reads or writes data, the request goes to the mount target, which then communicates with the EFS backend. The backend ensures that all writes are synchronously replicated across all AZs before acknowledging the write. This synchronous replication provides strong consistency: after a write is acknowledged, any subsequent read from any mount target will see the updated data. The replication happens at the storage layer, transparent to the client.

To create an EFS file system with Multi-AZ mount targets using AWS CLI:

# Create file system
aws efs create-file-system --creation-token my-efs --region us-east-1

# Create mount targets in different AZs
aws efs create-mount-target --file-system-id fs-12345678 --subnet-id subnet-abc123 --security-group sg-xyz789
aws efs create-mount-target --file-system-id fs-12345678 --subnet-id subnet-def456 --security-group sg-xyz789
aws efs create-mount-target --file-system-id fs-12345678 --subnet-id subnet-ghi789 --security-group sg-xyz789

# Verify mount targets
aws efs describe-mount-targets --file-system-id fs-12345678

Output example:

{
    "MountTargets": [
        {
            "OwnerId": "123456789012",
            "MountTargetId": "fsmt-abc123",
            "FileSystemId": "fs-12345678",
            "SubnetId": "subnet-abc123",
            "LifeCycleState": "available",
            "IpAddress": "10.0.1.12",
            "NetworkInterfaceId": "eni-abc123",
            "AvailabilityZoneId": "use1-az2",
            "AvailabilityZoneName": "us-east-1a",
            "VpcId": "vpc-12345"
        },
        {
            "OwnerId": "123456789012",
            "MountTargetId": "fsmt-def456",
            "FileSystemId": "fs-12345678",
            "SubnetId": "subnet-def456",
            "LifeCycleState": "available",
            "IpAddress": "10.0.2.12",
            "NetworkInterfaceId": "eni-def456",
            "AvailabilityZoneId": "use1-az4",
            "AvailabilityZoneName": "us-east-1b",
            "VpcId": "vpc-12345"
        }
    ]
}

To mount on an EC2 instance:

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-12345678.efs.us-east-1.amazonaws.com:/ /mnt/efs

When you create mount targets in multiple AZs, the EFS file system is already replicated across AZs. If one AZ fails, the mount targets in that AZ become unreachable. However, because the data is replicated, instances in other AZs can still access the file system through their local mount target. The DNS name resolves to the IP addresses of all available mount targets. If a mount target becomes unhealthy, DNS may automatically remove its IP from the resolution (this is not instantaneous but typically within a few minutes). Therefore, it is best practice to mount using the general DNS name rather than a specific AZ DNS name. Additionally, you can use an Application Load Balancer (ALB) in front of EFS for advanced routing, but that is not common.

Each mount target must have a security group that allows inbound NFS traffic (TCP port 2049) from the CIDR of the VPC (or specific instance security groups). For Multi-AZ, ensure that the security group allows traffic from all relevant subnets.

EFS costs are based on storage used (per GB-month) and throughput (for Provisioned mode). There is no charge for mount targets themselves. However, data transfer between AZs is not charged for EFS traffic (it stays within AWS network). This is an advantage over solutions like EBS snapshots or S3 cross-region replication.

A common mistake is to create only one mount target in a single AZ. While the file system is still replicated across AZs, if that AZ fails, instances cannot mount the file system because the mount target is unavailable. Even though data is safe, access is lost. The exam will test that you need mount targets in each AZ where you have instances. Also, you cannot have more than one mount target per subnet (but you can have one per AZ subnet).

A large e-commerce platform runs a web application across multiple EC2 instances in an Auto Scaling group spanning three AZs. The application serves product images and static assets from a shared EFS file system. The team creates mount targets in each AZ's public subnet. They use the general DNS name in the mount command. During a major AZ outage in us-east-1a, the instances in that AZ fail, but the Auto Scaling group launches new instances in the remaining AZs. These new instances mount EFS using the DNS name and connect to the healthy mount targets. The application continues serving content without interruption. The key lesson: always mount using the general DNS, not an AZ-specific endpoint.

A media company uses a pipeline of EC2 instances and AWS Batch jobs to transcode video files. The input and output files are stored on EFS. The pipeline spans three AZs. They create mount targets in each AZ and use provisioned throughput to handle the high I/O. During a partial AZ failure affecting the mount target's network, the jobs in that AZ fail to mount. However, the job scheduler retries the jobs in other AZs, where mount targets are healthy. The pipeline recovers automatically. The team also uses lifecycle policies to move older files to Infrequent Access to reduce costs. A common mistake was initially using a single mount target; after an AZ failure, all jobs failed. They redesigned to Multi-AZ mount targets.

A company provides virtual desktops using Amazon WorkSpaces or EC2 instances with Linux. User home directories are stored on EFS. With Multi-AZ mount targets, if a user's WorkSpace in one AZ fails, they can be redirected to a WorkSpace in another AZ and still access their home directory. This requires that the EFS file system is mounted using the general DNS. The IT team also sets up a security group that allows NFS traffic only from the WorkSpaces security group. They use encryption at rest and in transit for compliance. A misconfiguration occurred when they accidentally created mount targets in subnets with no route to the internet (for a private workload) but forgot to add a VPC endpoint for EFS; they fixed it by using AWS PrivateLink.