Amazon EFS: Shared File Storage That Multiple EC2 Instances Can Mount Simultaneously

EBS solves the problem of giving a single EC2 instance a fast, persistent disk. EFS solves a different problem: what happens when ten EC2 instances all need to read and write the same files at the same time? That is the question Amazon Elastic File System answers.

EFS is a fully managed NFS (Network File System) file system. You create it, mount it on as many Linux instances as you need, and it appears as a regular POSIX filesystem. No capacity planning required — EFS grows and shrinks as you add or delete files, and you pay only for what you store.

How EFS Differs From EBS

EBS volumes are attached to one EC2 instance at a time (with limited exceptions for io2 multi-attach). They live in a single AZ. EFS is a different category of storage:

Multi-instance: hundreds of EC2 instances can mount the same EFS simultaneously
Multi-AZ: EFS data replicates across all AZs in a region by default
Elastic: capacity is not provisioned; it expands and contracts automatically
NFS protocol: applications access it exactly like a standard filesystem

  EFS vs EBS Mount Model
  ======================

  EBS (block, single-attach):            EFS (file, multi-attach):

  EC2-A ─── EBS Volume                   EC2-A ─┐
  (EBS can't also attach to EC2-B)        EC2-B ─┼─── EFS File System
                                           EC2-C ─┘     (all AZs in region)
                                           Lambda─┘
                                           ECS   ─┘

  Use EBS when: one instance needs        Use EFS when: multiple compute
  fast local-ish disk                     resources share the same files

Architecture: Mount Targets

EFS does not attach to instances directly. Instead, you create mount targets — one per Availability Zone. Each mount target has an IP address within a subnet. Instances in that subnet mount the file system via NFS to the mount target’s IP.

For high availability, create a mount target in every AZ where you have EC2 instances. Traffic from an instance in us-east-1a goes to the us-east-1a mount target, staying within the AZ for low latency.

  EFS Mount Target Architecture
  ==============================

          EFS File System (us-east-1)
               │
    ┌──────────┼──────────┐
    │          │          │
  MT-1a      MT-1b      MT-1c
  (AZ-1a)   (AZ-1b)   (AZ-1c)
    │          │          │
  EC2-1     EC2-2      EC2-3

  Each mount target = NFS endpoint in one AZ
  Instances connect to the MT in their own AZ
  Data is shared across all AZs automatically

Performance Modes

EFS offers two performance modes chosen at file system creation:

General Purpose (default): optimized for latency-sensitive workloads. Metadata operations (listing directories, stating files) are fast. The right choice for web servers, content management, development environments, and most applications.

Max I/O: scales to higher aggregate throughput and IOPS at the cost of slightly higher latency per operation. Use this when thousands of instances or containers are accessing the file system simultaneously and aggregate throughput matters more than individual operation latency. Examples: large-scale media processing, big data analytics pipelines.

Throughput Modes

Separate from performance mode, throughput mode controls how much data bandwidth the file system gets:

Bursting throughput: baseline throughput is proportional to the amount of data stored, with burst credits that allow temporary spikes. This works well for workloads with variable access patterns. Small file systems may burst above their baseline for short periods.

Provisioned throughput: you specify the throughput you need in MB/s, independent of storage size. Use this when your file system is small but your application needs consistent high throughput — for example, a 10 GB EFS used by a video editing pipeline that needs 500 MB/s.

Elastic throughput (newer option): EFS automatically scales throughput up and down based on actual workload. This is the simplest choice for most new deployments — you pay for what you use without managing burst credits or provisioning.

Storage Classes and Lifecycle Management

EFS has two storage classes:

EFS Standard: for frequently accessed files, data replicated across AZs
EFS Infrequent Access (IA): for files not accessed regularly, lower storage cost with a retrieval fee

EFS Lifecycle Management works like S3 lifecycle: files not accessed for a configurable period (7, 14, 30, 60, or 90 days) automatically move to the IA class. When accessed again, they move back. This can reduce storage costs by up to 92% for workloads with large amounts of cold data mixed with active data.

Access Points

Access points are application-specific entry points to an EFS file system. Each access point enforces a specific POSIX user, group, and root directory. This lets multiple applications or teams share a single EFS without seeing each other’s data.

For example, a Jenkins build server and a monitoring agent can both mount the same EFS, but through different access points with different root directories and permissions. The Jenkins process sees /builds/ as its root; the monitoring process sees /metrics/ as its root.

Real-World Use Case: Shared Web Content for Auto Scaling Groups

A content management platform runs WordPress on EC2. Uploaded images and themes must be available on every instance in the Auto Scaling group — including instances that launch after the content was uploaded. EFS solves this:

WordPress upload directory (/var/www/html/wp-content/uploads) is mounted from EFS
Any instance that scales in mounts the same EFS via its AZ’s mount target
A file uploaded through instance A is immediately available on instances B and C
Instance count scales from 2 to 50 during a traffic spike without any storage configuration

The alternative — syncing uploads to S3 and serving from there — requires significant application changes. EFS requires only a mount command.

Mounting EFS on Linux

# Install NFS client
sudo yum install -y amazon-efs-utils

# Create mount point
sudo mkdir /mnt/shared

# Mount using EFS mount helper (handles TLS and IAM)
sudo mount -t efs -o tls fs-0abc123def456789:/ /mnt/shared

# Add to /etc/fstab for persistence
fs-0abc123def456789:/ /mnt/shared efs _netdev,tls 0 0

Key Interview Points

EFS only supports Linux — Windows EC2 instances cannot mount EFS. For Windows shared storage, use FSx for Windows File Server or FSx for NetApp ONTAP
EFS is more expensive per GB than EBS — the trade-off is multi-instance access and automatic scaling
Performance mode cannot be changed after file system creation; throughput mode can be changed
EFS replicates across AZs by default in Standard class — One Zone storage class keeps data in a single AZ at lower cost, useful for development environments
Latency in EFS is typically in the low milliseconds range, higher than EBS SSD latency — this is fine for most applications but may not suit extremely latency-sensitive databases
EFS and Lambda: Lambda functions can mount EFS, enabling serverless functions to access large shared datasets without bundling them in the deployment package
Data in transit is encrypted by default when using the EFS mount helper with TLS; encryption at rest is a configuration option set at file system creation