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

Sharethis question

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.