Cloud Parts

Amazon EFS

A managed NFS file system that grows on its own and mounts on many AWS machines at once.

What it is
File storage
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026
Website

What it is

EFS is a shared file system you mount over NFS version 4.0 or 4.1. You create a file system, put a mount target (a network endpoint) in a subnet of each Availability Zone you use, and Linux machines in the VPC mount it like any network drive. EC2 instances, ECS and EKS containers, Fargate tasks and Lambda functions can all mount the same files, up to 25,000 connections per file system. There is no size to provision: it grows and shrinks as you add and delete files, and you pay for what is stored.

A Regional file system keeps data in several zones, so it stays available if one zone fails. A One Zone file system is cheaper but can lose data if its zone is lost. Files in the Standard class read in about 1 ms and write in about 2.7 ms. Lifecycle rules move cold files to Infrequent Access or Archive, where the first byte takes tens of milliseconds. In the default Elastic throughput mode, throughput scales with demand and you pay per GB read and written.

Why teams pick it

  • Many machines and services share one POSIX file system with locking and strong consistency
  • No capacity planning: storage grows to petabytes and shrinks automatically
  • Regional file systems survive the loss of an Availability Zone
  • Mounts directly in Lambda, Fargate, ECS and EKS, which have no persistent local disk

Watch out for

  • Latency is in milliseconds, slower than a local or EBS disk for small random I/O
  • Linux only: Windows clients aren’t supported, and NFSv3, nconnect and NFS ACLs aren’t either
  • One client tops out at 1,500 MiB/s on Elastic throughput with the EFS client 2.0 or later, otherwise 500 MiB/s
  • Locks are advisory only, and a single file can be at most 47.9 TiB

How it fits with other technologies

Create a file system, add a mount target, mount it with TLS · bash

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

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

aws efs put-lifecycle-configuration --file-system-id fs-0abc123456789def0 \
  --lifecycle-policies TransitionToIA=AFTER_30_DAYS

# on each instance, with amazon-efs-utils installed
sudo mkdir -p /mnt/shared
sudo mount -t efs -o tls fs-0abc123456789def0:/ /mnt/shared

See it in a real stack

No architecture uses Amazon EFS yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2015–2026

By 2015 AWS offered storage for objects (S3), for disks attached to a single instance (EBS) and for archives (Glacier), but nothing that let many EC2 instances share the same files at once. Customers had been asking for one. Andy Jassy, announcing it, pointed at the pain of running file servers: capacity is hard to predict, and availability and performance are hard to manage.

AWS announced Elastic File System on 9 April 2015 at its San Francisco Summit. It spoke NFSv4, so Linux machines could mount it like any network drive; stored data redundantly across several Availability Zones; and grew and shrank as files came and went, with nothing to provision, at $0.30 per GB-month. After more than a year in preview, AWS declared it ready for production use on 28 June 2016, in three Regions.

Later changes followed where compute went. Lambda functions gained EFS mounts in 2020, giving serverless code a shared, persistent file system, and Elastic throughput (2022) removed the need to size performance. In April 2026 EFS became the engine under S3 Files, which mounts S3 buckets as file systems.

Why it’s built this way

Standard NFS instead of a new API
Existing Linux software and tools could use it unchanged, through the operating system’s own NFS client, rather than being rewritten for a storage API.
No size to provision
File servers had to be sized for growth in advance. EFS bills for what is stored and grows to petabytes on its own.
Data spread across Availability Zones
Unlike an EBS volume, which lives in one zone, an EFS file system has a mount target in each zone and stays available if one fails. The cost is latency in milliseconds, slower than a local disk.
Throughput tied to size at first, then elastic
At launch, throughput grew with the amount of data stored, so a small file system got little of it. Elastic throughput scales with demand and bills per GB read and written instead.

Timeline

  1. 2015

    Announced in preview on 9 April at the AWS Summit in San Francisco

  2. 2016

    Generally available for production use in three Regions (June)

  3. 2020

    Lambda functions can mount EFS file systems (June)

  4. 2022

    Elastic throughput: no performance to provision, pay per GB transferred (November)

  5. 2026

    S3 Files, built on EFS, mounts S3 buckets over NFS (April)

Sources8 · facts checked 5 October 2026

Improve this page on GitHub