Visual overview
Multiple compute clients can mount the same EFS file system through a VPC.
Technical reference
EFS is shared network file storage; protocol, network path, and throughput mode are key levers.
Linux-compatible clients mount EFS using NFSv4 semantics.
Security groups must allow the designed NFS path between clients and mount targets.
Modes trade automatic adaptation, configured throughput, and burst-credit behavior.
Regional EFS stores data redundantly across multiple AZs; One Zone is a separate trade-off.
Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.
Mount targets connect the file system to a VPC
To access EFS from a VPC, you create mount targets. A mount target provides a network endpoint in a subnet and is associated with security groups that control network access. For EFS file systems using Regional storage classes, mount targets can be created in multiple Availability Zones so clients can use an endpoint in their own AZ and avoid making one network endpoint the architecture's single-AZ dependency.
The NFS interface means ordinary network and file-system concerns still matter: clients need network reachability, DNS or endpoint resolution, security-group rules and appropriate file permissions. EFS Access Points can provide application-specific entry points and identity behavior, but they do not replace mount targets; mount targets provide the network path while access points shape how applications enter and use the file system.
Regional and One Zone are deliberate resilience choices
EFS Regional storage is designed to store file-system data across multiple Availability Zones in an AWS Region. EFS One Zone stores data within a single Availability Zone and supports only a mount target in that same AZ. The One Zone option can be appropriate for data that does not require multi-AZ storage resilience or can be recreated, while Regional is the natural choice when the shared file system itself must survive an AZ-level failure.
This is the same architectural habit seen elsewhere in AWS: do not infer resilience from the word 'managed.' A managed service can still offer products with intentionally different failure boundaries. Choose the storage class from the application's recovery requirement and ensure compute placement, mount targets and backup strategy align with that decision.
When EFS is a good fit
EFS is useful for Linux-oriented applications that need shared file access, content repositories, web-serving fleets, development environments, home directories and container workloads that expect a common NFS file system. It can reduce the work of building and operating a scalable NFS server fleet yourself because AWS manages the underlying file-service infrastructure.
Do not choose EFS when the workload really wants an object API or a block device. S3 is generally the better fit for object-native data lakes, assets and backups; EBS is designed for server-attached block storage; FSx should be considered when a workload depends on Windows SMB, Lustre, ONTAP or OpenZFS-specific behavior.
Key takeaways
- 01
EFS provides managed elastic NFS file storage that compatible compute resources can share.
- 02
Mount targets provide VPC network endpoints; access points provide application-oriented file-system entry behavior.
- 03
Regional EFS uses a multi-AZ storage model, while EFS One Zone intentionally uses a single Availability Zone.
- 04
Choose EFS for shared file semantics, not merely because multiple servers need access to some data.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.