Access to EFS is controlled through multiple layers: IAM policies for API-level access, EFS Resource-based policies for file system access, POSIX user and group permissions for file-level access, Security Groups for network-level access, and EFS Access Points for application-specific entry points with enforced identities.
EFS uses a layered security model. Network access is controlled at the perimeter using VPC Security Groups. Identity-based access is controlled using IAM and EFS File System Policies. File and directory-level permissions are governed by POSIX (Linux) ownership and permission bits. EFS Access Points provide an additional layer that enforces a specific operating system identity and root directory for any client using that access point.
EFS creates Mount Targets in each Availability Zone — each Mount Target has an Elastic Network Interface (ENI) with its own Security Group
EC2 instances must have outbound access to the Mount Target's Security Group on port 2049 (NFS)
The Mount Target Security Group must allow inbound traffic on port 2049 (NFS) from the EC2 instance's Security Group
Best practice: create a dedicated 'EFS Security Group' that only allows inbound NFS (port 2049) from your application security group
IAM Identity Policies — attach to IAM users, roles, or groups to allow/deny EFS API actions like elasticfilesystem:CreateFileSystem, elasticfilesystem:ClientMount, elasticfilesystem:ClientWrite
EFS File System Policy — a resource-based policy attached directly to the EFS file system. Controls which IAM principals can mount the file system and what permissions they have
Default behavior — if no file system policy exists, all IAM principals in the account have full access
You can enforce TLS-only access and IAM authorization via the file system policy
EFS is POSIX-compliant — every file and directory has an owner (UID), group (GID), and permission bits (rwx)
When an EC2 instance mounts EFS, the Linux user running the application must have appropriate POSIX permissions on the directory
The root user (UID 0) on the EC2 instance has root squash by default — mapped to the anonymous user (UID 65534) to prevent unrestricted root access
You can disable root squash via EFS Access Points or mount options to allow root access
Access Points are application-specific entry points into an EFS file system
Each Access Point enforces a specific root directory — the client only sees files under that directory, not the entire EFS
Each Access Point enforces a POSIX user identity (UID/GID) — regardless of the OS user on the EC2 instance
Ideal for multi-tenant applications, containers, and serverless functions (Lambda) that need isolated directory access
Access Points are commonly used with IAM authorization to ensure only specific roles can use specific access points
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
