Fix EFS Mount Timeout and Performance Issues

An ECS service backed by EFS started throwing mount timeouts on exactly one task out of a dozen, every single deployment, always the same failure rate. The other eleven tasks landed in AZs with an EFS mount target already provisioned; the twelfth kept landing in an AZ that had never had a mount target created because it was added to the subnet group after the EFS file system was originally set up. The fix took five minutes once found — creating one missing mount target — but it took a day to find because “one task out of twelve fails intermittently” doesn’t obviously point at “one specific AZ has no mount target.”

EFS mount problems are almost always availability zone or security group mismatches; performance problems are almost always throughput mode limits being hit quietly. Here’s how to isolate each.

The Problem

Mounts fail outright, or succeed but perform worse than expected:

Symptom	What It Means
Mount hangs then times out	No mount target in the client’s AZ, or security group blocking NFS port 2049
Mount fails immediately with connection refused	Mount target doesn’t exist in that VPC/subnet at all
Works from EC2, fails from Lambda/ECS	Different subnet/AZ placement for the compute type, or missing VPC config on the function
Reads/writes slow under load	Burst credit balance exhausted under General Purpose mode’s bursting throughput model
Metadata operations (`ls`, `stat`) especially slow	High latency inherent to network-attached file metadata, worse under Bursting Throughput mode with depleted credits

Nearly every EFS issue is either “the client can’t reach a mount target” or “the client can reach it, but the throughput mode is now the bottleneck.”

Why Does This Happen?

No mount target in the client’s Availability Zone: EFS requires one mount target per AZ you intend to mount from. If a subnet group is expanded (new AZ added to an ECS/EKS cluster, a new Lambda subnet) after the file system was created, the new AZ has no mount target until one is explicitly created.
Mount target security group blocking NFS: The mount target’s security group must allow inbound TCP 2049 from the client’s security group or CIDR — a default or overly restrictive security group silently blocks every mount attempt from that source.
Lambda functions not configured with matching VPC/subnet/security group: A Lambda function accessing EFS must be attached to the same VPC, in a subnet with a mount target, with a security group that’s allowed by the mount target’s security group — missing any piece produces a mount error at invocation time, not at deploy time.
General Purpose mode with Bursting Throughput hitting credit exhaustion: Bursting Throughput mode grants baseline throughput proportional to storage size, with burst credits accumulated during quiet periods. Sustained high-throughput workloads on a relatively small file system exhaust burst credits and fall back to a low baseline, which looks like a sudden, unexplained slowdown.
Access point or POSIX permission mismatches: An EFS access point enforcing a specific POSIX user/group ID that doesn’t match the file ownership on disk causes Permission Denied errors that look like a mount problem but are actually a file-level ACL problem surfacing only through the access point’s enforced identity.
One Zone storage class mount targets in the wrong AZ: EFS One Zone file systems only have a mount target in a single AZ by design — attempting to mount from any other AZ fails, which is expected behavior but easy to forget when a file system was provisioned as One Zone for cost reasons.

The Fix

Step 1: Confirm a Mount Target Exists in the Client’s AZ

aws efs describe-mount-targets \
  --file-system-id fs-0abc123def \
  --query "MountTargets[*].{MountTargetId:MountTargetId,SubnetId:SubnetId,AZ:AvailabilityZoneName,State:LifeCycleState}" \
  --output table

Cross-check against the AZ your ECS task, EC2 instance, or Lambda function is actually running in. If the AZ isn’t listed, create the missing mount target:

aws efs create-mount-target \
  --file-system-id fs-0abc123def \
  --subnet-id subnet-0missingaz456 \
  --security-groups sg-0efsmountsg123

Step 2: Check the Mount Target’s Security Group

aws ec2 describe-security-groups \
  --group-ids sg-0efsmountsg123 \
  --query "SecurityGroups[0].IpPermissions[?ToPort==\`2049\`]"

If NFS (port 2049) isn’t allowed from the client’s security group, add it:

aws ec2 authorize-security-group-ingress \
  --group-id sg-0efsmountsg123 \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0clientsg456

Step 3: Test the Mount Directly From an EC2 Instance in the Same Subnet

sudo mount -t efs -o tls fs-0abc123def:/ /mnt/efs

If this hangs, check basic network reachability to the mount target’s IP first:

nc -zv 10.0.1.45 2049

A closed or filtered result confirms a security group or NACL problem rather than an EFS-side issue.

Step 4: Verify Lambda’s VPC Configuration Matches an EFS-Reachable Subnet

aws lambda get-function-configuration \
  --function-name process-uploads \
  --query "VpcConfig"

Confirm the listed subnet IDs have mount targets (Step 1) and the listed security groups are permitted by the mount target’s security group (Step 2). Also confirm the function has the EFS access point configured:

aws lambda get-function-configuration \
  --function-name process-uploads \
  --query "FileSystemConfigs"

Step 5: Check Burst Credit Balance

aws cloudwatch get-metric-statistics \
  --namespace AWS/EFS \
  --metric-name BurstCreditBalance \
  --dimensions Name=FileSystemId,Value=fs-0abc123def \
  --start-time $(date -u -d '6 hours ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Minimum

A balance trending toward zero explains a throughput cliff. Switch to Elastic Throughput mode, which scales automatically with actual demand and removes the credit model entirely:

aws efs update-file-system \
  --file-system-id fs-0abc123def \
  --throughput-mode elastic

Step 6: Check Access Point POSIX Configuration Against Actual File Ownership

aws efs describe-access-points \
  --file-system-id fs-0abc123def \
  --query "AccessPoints[*].{Id:AccessPointId,PosixUser:PosixUser,RootDirectory:RootDirectory}"

Mount via the root file system (not the access point) temporarily to check actual file ownership if you suspect a mismatch:

stat /mnt/efs-root/uploads

Align the access point’s PosixUser/PosixGroup with the actual UID/GID that owns the files, or adjust file ownership to match the access point’s enforced identity.

Step 7: Confirm Storage Class Matches Mount Expectations

aws efs describe-file-systems \
  --file-system-id fs-0abc123def \
  --query "FileSystems[0].AvailabilityZoneName"

A non-empty value here means it’s a One Zone file system — mounts are only possible from that single AZ, by design. If multi-AZ access is required, this file system needs to be migrated to Standard storage class (via AWS DataSync or backup/restore), not reconfigured in place.

Is This Safe?

The describe and CloudWatch calls are read-only. Creating a missing mount target and adding a security group rule are additive and don’t disrupt existing mounts. Switching to Elastic Throughput mode is a live, non-disruptive change with no downtime, though it changes the billing model to pay-per-use for throughput — review cost implications for consistently high-throughput workloads where Provisioned Throughput might be cheaper. Migrating between storage classes (One Zone to Standard) is a data migration, not a setting change — plan it as a project with a cutover window.

Key Takeaway

EFS mount failures almost always trace back to a missing mount target in the client’s specific AZ or a security group blocking NFS port 2049 — check both before assuming anything more exotic. Performance complaints are usually burst credit exhaustion under General Purpose mode’s default throughput model; Elastic Throughput mode removes that whole class of problem for variable workloads. When in AZ-specific trouble, always cross-reference exactly which AZ the failing client is in against exactly which AZs have provisioned mount targets — that mismatch explains the overwhelming majority of “works for some, not for others” EFS tickets.

Have questions or ran into a different EFS issue? Connect with me on LinkedIn or X.