AWS EFS – One Shared Drive for Hundreds of Servers
How Amazon Elastic File System gives many compute instances the same live folder at once, growing and shrinking automatically, without anyone provisioning a single gigabyte in advance.
Imagine an office where every employee keeps their own personal filing cabinet, and whenever two people need to work on the same document, someone has to physically walk a copy from one cabinet to the other. That works fine for a small team, but it falls apart the moment fifty people need to edit the same shared spreadsheet at the same time. What that office really needs is a single shared cabinet, visible to every desk simultaneously, that grows a new drawer the instant it runs out of space. That is exactly the gap AWS Elastic File System exists to close for servers instead of desks.
1What Problem Is EFS Actually Solving?
Before looking at how EFS is built, it’s worth being precise about the gap it fills between two more familiar kinds of storage.
Block storage isn’t built to be shared
An EC2 instance normally stores its files on an EBS volume, which behaves like a hard drive bolted onto exactly one server at a time. That’s great for an operating system disk or a database’s data files, but it means the moment a second server also needs to read and write the same files, block storage runs into trouble — two machines writing to the same disk at once, without a shared file system layer coordinating them, will corrupt data.
Object storage isn’t built to behave like a folder
Amazon S3 solves a related but different problem: storing huge numbers of objects durably and cheaply, accessed through an API rather than mounted as a drive. Many applications, though, are written assuming they can open, read, write, rename, and lock ordinary files inside ordinary directories — the way software has worked for decades. Rewriting that software to speak S3’s API instead of standard file operations is often impractical.
Block storage is like a locker that only one person has the key to. Object storage is like a warehouse where you request items by barcode through a counter clerk. EFS is like a shared filing room with a copy of the key for every desk in the building — everyone opens the same drawers, sees the same files, and changes show up for everyone instantly.
EFS is a managed, elastic, shared file system reachable over the network using the standard NFS protocol — the same file operations that ordinary applications already expect, just accessible from many instances and containers at once.
2Architecture and Core Components
EFS is assembled from a small set of pieces that together make a single elastic file system reachable from many places in a VPC.
File System
The logical EFS resource itself — a single namespace of files and directories that automatically grows and shrinks as data is added or removed, with no capacity to pre-provision.
Mount Target
A network endpoint created in a specific subnet and Availability Zone, with its own IP address, through which instances in that AZ connect to the file system using NFS.
Access Point
An application-specific entry point into the file system that enforces a fixed directory path and POSIX user identity, so different applications can share one file system while each only ever sees its own slice of it.
Storage Classes
Standard storage for frequently accessed files, and Infrequent Access storage for files that are read or written rarely, priced lower per gigabyte but with a small retrieval cost.
One file system, many mount targets
A single EFS file system typically has one mount target per Availability Zone in a Region. Every instance, regardless of which AZ it runs in, connects to the mount target in its own AZ, but all of those mount targets lead to the exact same underlying file data. Write a file from an instance in one AZ, and it is immediately visible to an instance reading through the mount target in a different AZ.
graph TB
A[EC2 in AZ-a] -->|NFS| MT1[Mount Target AZ-a]
B[EC2 in AZ-b] -->|NFS| MT2[Mount Target AZ-b]
C[Lambda / ECS Task] -->|NFS via ENI| MT2
MT1 --> FS[(EFS File System)]
MT2 --> FS
FS --> Standard[Standard Storage Class]
FS --> IA[Infrequent Access Storage Class]
What can actually connect
EC2 instances, containers running on ECS or EKS, and even individual Lambda function invocations can all mount the same EFS file system concurrently, as long as they run inside the VPC — or a connected VPC — that has a mount target available to them. This is what makes EFS a natural fit for anything that needs a genuinely shared, POSIX-compliant view of files across many compute resources at once.
3Internal Working: What Happens Behind the Mount
From an application’s point of view, EFS just looks like a folder. Underneath, a fair amount of coordination makes that illusion possible.
When an instance mounts an EFS file system, it uses the Network File System protocol, version 4.1, to talk to the mount target’s IP address. From the application’s perspective, this looks exactly like any other mounted directory — normal file operations such as opening, reading, writing, and listing directories work without any code changes. Behind that mount target, though, the actual file data isn’t sitting on a single disk. It is spread across a distributed storage layer that AWS operates, which replicates data across multiple Availability Zones automatically for the Standard storage classes.
Because many clients can be reading and writing at once, EFS implements standard NFS file locking semantics, so applications that rely on file locks to coordinate access — the same way they would on a traditional shared file server — continue to work correctly even with dozens or hundreds of concurrent clients.
sequenceDiagram
participant App as Application on EC2
participant MT as Mount Target
participant Dist as Distributed Storage Layer
participant Other as Another EC2 in Different AZ
App->>MT: NFS write request
MT->>Dist: Persist data, replicate across AZs
Dist-->>MT: Write acknowledged
MT-->>App: Write complete
Other->>MT: NFS read request (same file)
MT->>Dist: Fetch latest data
Dist-->>Other: Return updated content
EFS is not a local disk with a network cable stretched to it. Every operation involves a network round trip to the mount target, so its latency characteristics are closer to a networked file server than to a locally attached SSD.
4Data Flow and Lifecycle
Files in EFS don’t just sit still — they can automatically move between storage classes as their access patterns change.
Consider a media-processing pipeline where dozens of worker instances write freshly transcoded video files to a shared EFS file system, and a separate fleet of instances reads those files to package and deliver them. Here is the typical lifecycle a single file goes through:
File is written
A worker instance writes a newly transcoded file to the shared file system through its local mount target, and the write lands in the Standard storage class.
File is actively read
Multiple downstream instances read the same file concurrently through their own mount targets, seeing identical, up-to-date content regardless of which AZ they’re in.
Access frequency drops
After the initial burst of activity, the file is accessed only occasionally, if at all, as newer files take its place in the active pipeline.
Lifecycle management moves it
A configured lifecycle policy notices the file hasn’t been accessed for a set number of days and automatically transitions it to the Infrequent Access storage class, lowering its storage cost.
Occasional retrieval
If the file is needed again later — say, for a re-encode request — it is read directly from Infrequent Access storage without any manual restore step, though at a slightly higher per-request cost than Standard.
The important idea here is that none of this requires the application to know or care which storage class a file currently lives in. The file system presents one continuous namespace; the lifecycle transitions happen transparently underneath it.
5Advantages, Disadvantages and Trade-offs
EFS is an excellent fit for some workloads and a poor fit for others — knowing which is which avoids expensive mistakes.
Advantages
- Genuinely shared, concurrent access from many EC2 instances, containers, and Lambda functions at once.
- Capacity grows and shrinks automatically — no volumes to resize or pre-provision.
- Standard POSIX file semantics, so most existing applications work without code changes.
- Built-in Multi-AZ durability and availability for the Standard storage classes.
- Automatic lifecycle management can significantly reduce storage cost for aging data.
Disadvantages / Trade-offs
- Higher per-operation latency than a locally attached EBS volume or instance store.
- Costs more per gigabyte than S3 for large volumes of infrequently touched data, unless lifecycle management is configured.
- Not ideal for workloads needing the very highest, most consistent single-client IOPS, such as some relational database engines.
- Throughput scaling depends on the chosen throughput mode, and the default mode can bottleneck bursty, high-volume workloads if misconfigured.
6Performance and Scalability
EFS separates two independent performance decisions — how requests are distributed internally, and how much throughput the file system can sustain.
Performance modes
General Purpose mode is the default and suits the overwhelming majority of workloads, offering the lowest per-operation latency. Max I/O mode trades a bit of latency for the ability to scale to a much higher number of parallel operations across many clients at once, which suits workloads like large-scale big-data analytics where thousands of clients hit the file system simultaneously but individual request latency matters less.
Throughput modes
Bursting Throughput
Throughput scales automatically with the amount of data stored, and the file system can burst above its baseline using accumulated burst credits — well suited to workloads whose size and activity grow together.
Provisioned Throughput
Throughput is specified independently of how much data is stored, useful when a small file system needs to sustain high throughput that its size alone wouldn’t earn under bursting mode.
Elastic Throughput
Throughput scales up and down automatically based on real-time workload demand, removing the need to choose or monitor a specific throughput level at all.
Elastic Throughput removes an entire category of capacity-planning mistakes for workloads with unpredictable or spiky demand, at the cost of paying for throughput actually consumed rather than a flat provisioned rate.
7High Availability and Reliability
EFS is designed so that a single Availability Zone outage does not mean lost or unreachable data.
Multi-AZ by default
For the Standard storage classes, EFS automatically stores file data and metadata redundantly across multiple Availability Zones within a Region. This happens without any extra configuration — it is simply how the Standard storage classes work, in contrast to a typical EBS volume, which lives in a single AZ unless explicitly copied elsewhere.
Mount target resilience
Because each Availability Zone gets its own mount target, an instance always connects to the mount target in its local zone. If that specific mount target or Availability Zone experiences a problem, instances in other zones continue reading and writing the same file system without interruption through their own mount targets — only instances local to the affected zone need to fail over to a mount target elsewhere.
One-Zone Storage Classes Exist Too
EFS also offers One Zone storage classes that store data in a single Availability Zone at a lower cost, intentionally trading the automatic Multi-AZ redundancy for savings — a deliberate choice appropriate for non-critical or easily reproducible data, not a default recommendation.
Backups Are Still Necessary
Multi-AZ durability protects against infrastructure failure, but it does not protect against a person or a script accidentally deleting or corrupting a file. AWS Backup integrates directly with EFS to provide point-in-time recovery for exactly that scenario.
8Security
EFS layers network controls, identity controls, and traditional file permissions on top of each other.
Security Groups
Mount targets are protected by security groups just like any other network interface, controlling which instances are even allowed to attempt an NFS connection.
IAM Authorization
EFS can require IAM authorization for client mount and file-system-level actions, layering AWS identity policy on top of network-level access.
POSIX Permissions
Ordinary Unix-style user, group, and permission bits still apply to every file and directory, exactly as they would on a traditional file server.
Access Points
An access point can enforce a specific POSIX user identity and root directory automatically for every connection made through it, making it easy to give different applications isolated, correctly scoped views of a shared file system.
Encryption
Data can be encrypted at rest using AWS Key Management Service keys, configured when the file system is created, and encryption in transit is available by enabling TLS on the NFS mount itself, protecting data as it travels between the client and the mount target.
A security group that only allows trusted instances to reach the mount target is important, but it doesn’t replace correctly scoped POSIX permissions and access points — without those, any instance that can mount the file system can potentially read or write every file on it.
9Monitoring, Logging and Metrics
Because EFS is shared infrastructure used by many clients at once, watching the right signals early prevents one workload from silently starving another.
Amazon CloudWatch collects metrics directly from EFS, including total storage used broken down by storage class, throughput utilization against the current throughput mode’s limits, and connection counts. Watching throughput utilization is particularly important under Bursting Throughput mode, since a file system that regularly exhausts its burst credits will see its performance drop until credits replenish.
Client-side visibility matters too
Because EFS is accessed over NFS, standard operating-system-level tools on the client instances — showing NFS call latency, retransmissions, and mount health — remain useful alongside CloudWatch’s file-system-level view. A file system can look perfectly healthy from AWS’s side while a specific client instance experiences a local networking issue, so both perspectives are needed for a complete picture.
Monitoring a shared file system is like watching both the water pressure at the main pump and the flow at each individual tap — a strong pump doesn’t guarantee every faucet in the building is working correctly.
10Deployment and Cloud Integration
EFS is designed to fit naturally into several different compute environments, not just plain EC2.
EC2 Instances
Instances mount the file system directly over NFS, typically as part of instance boot configuration so it’s ready as soon as the instance starts.
ECS and EKS
Containers can mount EFS file systems as persistent volumes, allowing state to survive container restarts and letting multiple container replicas share the exact same files.
AWS Lambda
Individual function invocations can mount an EFS file system through an access point, giving otherwise stateless functions access to a large, shared, persistent file area beyond Lambda’s normal temporary storage limits.
Hybrid and On-Premises
Using Direct Connect or a VPN connection into the VPC, on-premises servers can mount the same EFS file system as cloud-based instances, useful for gradual migrations or hybrid workloads.
Regional scope, VPC-bound access
An EFS file system lives within a specific Region and is accessed through mount targets placed in a specific VPC’s subnets. Cross-Region and cross-account access is possible through replication and appropriately configured networking, but by default a file system is reached from within its own VPC and any VPCs connected to it through peering or Transit Gateway.
11Design Patterns and Anti-patterns
A few recurring patterns explain most successful EFS deployments, and a couple of recurring mistakes explain most of the painful ones.
The shared-content pattern
Many web applications running across a fleet of EC2 instances or containers need every instance to serve identical uploaded files, themes, or configuration. Mounting one EFS file system across the entire fleet means a file uploaded through any single instance is instantly visible to every other instance, without any separate synchronization step.
The access-point-per-tenant pattern
Multi-tenant systems can use one access point per tenant, each scoped to a different root directory and POSIX identity within the same underlying file system. Each tenant’s application code mounts through its own access point and simply cannot see other tenants’ files, even though everything physically lives on one shared file system.
Problem
Using EFS as the primary data store for a high-throughput relational database that needs consistently low, predictable single-client latency.
Why It’s Harmful
Network file system latency, even though low, is still higher and less predictable per operation than a locally attached EBS volume, and most database engines are tuned and tested against local block storage, not network file systems.
Correct Approach
Keep transactional database storage on EBS or a managed database service, and reserve EFS for the shared files a database-adjacent application needs — configuration, logs, shared uploads — rather than the database’s core data files.
Problem
Leaving a small, rarely accessed file system on Bursting Throughput mode while running an occasional but large batch job against it.
Why It’s Harmful
A small file system earns only a small baseline throughput and limited burst credits, so a sudden large job can exhaust those credits quickly and slow to a crawl right when performance matters most.
Correct Approach
Use Provisioned or Elastic Throughput for file systems that see large, sudden workloads disproportionate to their stored data size.
12Best Practices and Common Mistakes
Most EFS issues in production trace back to a handful of avoidable configuration choices.
Use Access Points for Every App
Give each distinct application or tenant its own access point rather than letting everything mount the file system root directly with full permissions.
Enable Lifecycle Management
Turn on automatic transitions to Infrequent Access storage for data with a predictable cooldown in access frequency, rather than paying Standard rates indefinitely.
Match Throughput Mode to Workload Shape
Choose Bursting, Provisioned, or Elastic Throughput based on how spiky and how proportional to stored data size the workload’s demand actually is.
Back It Up Deliberately
Configure AWS Backup for point-in-time recovery, since Multi-AZ durability protects against infrastructure failure, not accidental deletion.
Treating EFS like a local disk for latency-sensitive, single-client workloads and being surprised when performance doesn’t match a locally attached volume — the two are built for different jobs.
13Real-World and Industry Examples
EFS shows up wherever many machines genuinely need to see the exact same files at the exact same time.
Content Management and Web Hosting
Content management platforms running across a fleet of web servers use EFS to store uploaded media and themes, so any server can serve any uploaded file immediately, without a separate synchronization or replication step between instances.
Big Data and Analytics
Analytics clusters that spin up large numbers of worker nodes for a job can point every worker at the same EFS file system for shared input data and intermediate results, using Max I/O performance mode to sustain high aggregate throughput across many parallel workers.
Container Platforms
Teams running stateful workloads on ECS or EKS use EFS-backed persistent volumes so that container replicas can be freely rescheduled across different underlying hosts without losing access to shared application state.
Machine Learning Training Pipelines
Training jobs that read the same large dataset from many GPU instances at once benefit from a single shared file system instead of copying the dataset onto every individual instance’s local storage.
Shared Development and Home Directories
Organizations migrating traditional shared network drives or developer home directories to the cloud use EFS to preserve the same familiar shared-folder experience their teams already relied on.
14Frequently Asked Questions
No. EFS automatically grows and shrinks as files are added or removed, and you are billed only for the storage actually used at any given time.
Yes. Each Availability Zone typically has its own mount target, and all of them lead to the same underlying, shared file system.
Generally no. Its network-based latency profile is better suited to shared file access patterns than to the consistently low, single-client latency most database engines are tuned for.
A mount target is a network entry point in a specific Availability Zone; an access point is an application-specific view into the file system that fixes a root directory and POSIX identity for every connection made through it.
Yes. A Lambda function can mount an EFS file system through an access point, giving it access to shared, persistent storage well beyond its normal temporary storage limits.
Not by itself. Multi-AZ durability protects against infrastructure failure, but recovering from accidental deletion requires configuring AWS Backup for point-in-time recovery.
15Summary and Key Takeaways
AWS Elastic File System fills a gap that neither block storage nor object storage can: a single, elastic, POSIX-compliant file system that many EC2 instances, containers, and Lambda functions can genuinely share and see updated in real time. Its value comes from removing the manual work of synchronizing files across a fleet, automatically scaling capacity, and automatically shifting cold data to cheaper storage — but it is not a universal replacement for locally attached storage, and it performs best when used for the workloads it was actually designed for: shared, concurrent, file-oriented access rather than single-client, ultra-low-latency transactional storage.
Key Takeaways
- EFS is genuinely shared storage — many clients across Availability Zones read and write the same files concurrently.
- Capacity is fully elastic — no volumes to size or resize in advance.
- Standard storage classes are Multi-AZ by default — durability doesn’t require extra configuration, though backups still do.
- Throughput and performance modes must match the workload — Bursting, Provisioned, and Elastic Throughput suit different demand shapes.
- Access points are the right tool for isolation — they scope different applications or tenants to their own view of a shared file system.
- It integrates broadly — EC2, ECS, EKS, Lambda, and even on-premises servers can all mount the same file system.
- It is not built for the same job as EBS — high-throughput, single-client transactional storage still belongs on block storage.