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.

Layer 1 — Network Access (Security Groups)

1
EFS creates Mount Targets in each Availability Zone — each Mount Target has an Elastic Network Interface (ENI) with its own Security Group
2
EC2 instances must have outbound access to the Mount Target's Security Group on port 2049 (NFS)
3
The Mount Target Security Group must allow inbound traffic on port 2049 (NFS) from the EC2 instance's Security Group
4
Best practice: create a dedicated 'EFS Security Group' that only allows inbound NFS (port 2049) from your application security group

Layer 2 — IAM Identity Policies and EFS File System Policy

1
IAM Identity Policies — attach to IAM users, roles, or groups to allow/deny EFS API actions like elasticfilesystem:CreateFileSystem, elasticfilesystem:ClientMount, elasticfilesystem:ClientWrite
2
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
3
Default behavior — if no file system policy exists, all IAM principals in the account have full access
4
You can enforce TLS-only access and IAM authorization via the file system policy

Layer 3 — POSIX Permissions

1
EFS is POSIX-compliant — every file and directory has an owner (UID), group (GID), and permission bits (rwx)
2
When an EC2 instance mounts EFS, the Linux user running the application must have appropriate POSIX permissions on the directory
3
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
4
You can disable root squash via EFS Access Points or mount options to allow root access

Layer 4 — EFS Access Points

1
Access Points are application-specific entry points into an EFS file system
2
Each Access Point enforces a specific root directory — the client only sees files under that directory, not the entire EFS
3
Each Access Point enforces a POSIX user identity (UID/GID) — regardless of the OS user on the EC2 instance
4
Ideal for multi-tenant applications, containers, and serverless functions (Lambda) that need isolated directory access
5
Access Points are commonly used with IAM authorization to ensure only specific roles can use specific access points

Creating an EFS File System Policy (IAM) via AWS CLI