Amazon EFS (Shared File Storage)

Sometimes many servers need to read and write the same files at the same time: a fleet of web servers serving uploaded images, a cluster of containers sharing a content directory, or a build farm sharing artifacts. A single EBS volume cannot do this, because a block-storage disk attaches to only one instance at a time. Amazon EFS (Elastic File System) solves the problem. It is a fully managed file system that speaks NFS (Network File System, a standard protocol for sharing files over a network) and can be mounted by thousands of instances and containers at once, across multiple Availability Zones.

What EFS is and why it matters

EFS gives you a file system, not a raw block device. You do not format it or pick a size. You create a file system, mount it on Linux at a path like /mnt/efs, and start using it. It grows and shrinks automatically as you add or delete files, so you never provision capacity and never run out of space. You pay only for the gigabytes you actually store.

The big difference from EBS (Elastic Block Store, a disk that attaches to one instance) is shared access. EFS is reachable from every instance in your VPC (Virtual Private Cloud, your private network in AWS) through small network endpoints called mount targets, one per Availability Zone (an AZ, an isolated data center within a region). Every instance that mounts the file system sees the same files, and a write from one instance is immediately visible to the others.

When to use EFS: shared content for a web or app fleet, container persistent volumes that move between hosts, home directories, lift-and-shift apps that expect a POSIX file system, and big data or media pipelines where many workers touch the same files.

When NOT to use EFS: as the disk for a single instance that just needs fast local storage (use EBS), for a database (use EBS or a managed database service), or for plain object storage and static website hosting (use S3, the Simple Storage Service). EFS is Linux-only via NFS; Windows shares use Amazon FSx instead.

The performance gotcha. EFS is dramatically slower and more expensive per gigabyte than EBS for single-instance use. Every read and write travels over the network using the NFS protocol, which adds latency that a local disk never has. EFS shines when the value is sharing, not raw speed. If only one instance needs the data, an EBS gp3 volume will be faster and cheaper.

Storage tiers and cost

EFS keeps your data in storage classes and can move files between them automatically based on how often they are read.

Tier	Best for	Relative cost
Standard	Files accessed regularly, spread across multiple AZs	Highest per GB
Standard-IA	Infrequently accessed files (IA = Infrequent Access), still multi-AZ	~92% cheaper per GB, small per-access fee
One Zone	Data you can afford to keep in a single AZ	Cheaper than Standard
One Zone-IA	Rarely accessed, single-AZ data	Cheapest

Turn on lifecycle management so EFS automatically moves a file to the IA tier after, say, 30 days without access, and pulls it back to Standard the moment it is read again. In us-east-1, Standard storage is about $0.30 per GB-month, while Standard-IA is about $0.025 per GB-month. For comparison, EBS gp3 is about $0.08 per GB-month, so EFS Standard costs roughly 3.5x more per GB than a gp3 disk. The savings from lifecycle management on cold data are large.

Throughput modes — pick the right one

This is the second gotcha that bites people. EFS has throughput modes, and the default behavior can throttle you hard under sustained load.

Mode	How it works	When to use
Elastic	Throughput scales up and down automatically to meet demand; you pay for what you drive	The modern default for spiky or unpredictable workloads
Provisioned	You set a fixed MB/s regardless of file system size and pay for it	Steady, high throughput on a small file system
Bursting	Throughput scales with stored size and uses burst credits when idle	Predictable workloads where size tracks throughput needs

Older Bursting-mode file systems earn burst credits while idle and spend them during activity. A small, mostly empty file system earns credits slowly. Push sustained traffic at it and the credits drain, after which throughput collapses to a tiny baseline and your application crawls. For anything with steady or bursty load, choose Elastic throughput so the file system simply keeps up. Use Provisioned only when you need a guaranteed high rate on a small file system.

Creating and mounting EFS

Console steps

Open the EFS console and click Create file system.
Give it a Name (for example shared-app-data) and select your VPC (for example vpc-0a1b2c3d).
Click Customize to set Throughput mode to Elastic and turn on Automatic backups and lifecycle management (transition to IA after 30 days).
Under Network access, confirm a mount target in each AZ and attach a security group (a virtual firewall) that allows inbound NFS traffic on TCP port 2049.
Review and click Create.

CLI equivalent

Create the file system with Elastic throughput and encryption:

aws efs create-file-system \
  --encrypted \
  --throughput-mode elastic \
  --tags Key=Name,Value=shared-app-data

Output:

{
    "FileSystemId": "fs-0a1b2c3d4e5f67890",
    "ThroughputMode": "elastic",
    "Encrypted": true,
    "LifeCycleState": "creating",
    "NumberOfMountTargets": 0
}

Create a mount target in a subnet, with a security group that allows port 2049:

aws efs create-mount-target \
  --file-system-id fs-0a1b2c3d4e5f67890 \
  --subnet-id subnet-0a1b2c3d \
  --security-groups sg-0a1b2c3d

Output:

{
    "MountTargetId": "fsmt-0a1b2c3d4e5f67890",
    "FileSystemId": "fs-0a1b2c3d4e5f67890",
    "SubnetId": "subnet-0a1b2c3d",
    "IpAddress": "10.0.1.42",
    "LifeCycleState": "creating"
}

Mounting on an EC2 instance

Install the EFS mount helper and mount the file system. The helper handles TLS encryption in transit for you.

sudo yum install -y amazon-efs-utils
sudo mkdir /mnt/efs
sudo mount -t efs -o tls fs-0a1b2c3d4e5f67890:/ /mnt/efs

To mount it automatically on every reboot, add a line to /etc/fstab:

echo "fs-0a1b2c3d4e5f67890:/ /mnt/efs efs _netdev,tls 0 0" | sudo tee -a /etc/fstab

Any other instance in the VPC that runs the same mount command sees the exact same files.

Defining EFS in infrastructure as code

CloudFormation lets you create the file system, a mount target, and an access point together.

Resources:
  SharedFs:
    Type: AWS::EFS::FileSystem
    Properties:
      Encrypted: true
      ThroughputMode: elastic
      LifecyclePolicies:
        - TransitionToIA: AFTER_30_DAYS
      FileSystemTags:
        - Key: Name
          Value: shared-app-data

  MountTargetA:
    Type: AWS::EFS::MountTarget
    Properties:
      FileSystemId: !Ref SharedFs
      SubnetId: subnet-0a1b2c3d
      SecurityGroups:
        - sg-0a1b2c3d

Best practices

Use Elastic throughput mode by default so the file system keeps up under load instead of exhausting burst credits and throttling.
Reach for EFS only when you genuinely need shared, multi-instance access — for single-instance data, EBS gp3 is faster and cheaper.
Turn on lifecycle management to move cold files to the IA tier automatically and cut storage cost sharply.
Lock down the security group to allow NFS (TCP 2049) only from your application instances, never the whole internet.
Keep encryption at rest and in transit on; mount with the -o tls option using the amazon-efs-utils helper.
Use access points to give different applications their own root directory and POSIX permissions on one file system.
Enable automatic backups (via AWS Backup) for any file system holding data you cannot lose.