Several applications must share one Amazon EFS file system without being able to read each other's directories or act as root. What does an EFS access point enforce, and how does IAM authorization fit alongside it?

## The problem with plain NFS multi-tenancy A raw EFS mount gives the client the whole file system tree, and file access is decided by the POSIX uid and gid the *client* presents. Any instance that can reach the mount target can mount `/`, and a process running as uid 0 on that instance is root on the share. For a single trusted application that is fine. For several applications, or several teams, sharing one file system, it means isolation depends entirely on every client host being configured correctly — which is not isolation at all. ## What an access point enforces An access point is a named entry point attached to the file system, with two enforced properties: **1. A root directory.** The access point specifies a path — say `/tenants/app-a` — and a client mounting through it sees that directory as `/`. It cannot address anything above it. The access point can also declare *creation info* (owner uid/gid and permissions) so the directory is created with the right ownership the first time it is used, rather than requiring a manual bootstrap step. **2. A POSIX identity.** The access point can specify a UID, a primary GID and optional secondary GIDs. When present, **every** file operation through that access point uses that identity, overriding whatever user the process runs as on the client. A container running as root writes files owned by the enforced uid, and reads are evaluated against it. Together these turn "trust the client's configuration" into "the file system enforces it", which is why access points are the standard way to hand one EFS file system to several applications — and why Lambda functions mount EFS *only* through an access point. ## Where IAM comes in Access points constrain what a mount can see; IAM constrains who may mount at all. A **file system policy** is a resource policy attached to the EFS file system, and the actions are: - `elasticfilesystem:ClientMount` — permission to mount, read-only unless write is also granted - `elasticfilesystem:ClientWrite` — permission to write - `elasticfilesystem:ClientRootAccess` — permission to act as root (uid 0) on the file system The key condition is `elasticfilesystem:AccessPointArn`, which ties a principal to a specific access point: ```json { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/app-a-task-role" }, "Action": ["elasticfilesystem:ClientMount", "elasticfilesystem:ClientWrite"], "Condition": { "StringEquals": { "elasticfilesystem:AccessPointArn": "arn:aws:elasticfilesystem:eu-west-1:123456789012:access-point/fsap-0123456789abcdef0" }, "Bool": { "aws:SecureTransport": "true" } } } ``` The `aws:SecureTransport` condition is worth including: it refuses mounts that are not encrypted in transit. Crucially, IAM authorization is **opt-in on the client side**. The mount must be made with the IAM option so that the instance's or task's role is presented: ```bash sudo mount -t efs -o tls,iam,accesspoint=fsap-0123456789abcdef0 \ fs-0123456789abcdef0:/ /mnt/app-a ``` Without `-o iam`, the mount is anonymous from IAM's point of view, and whether it succeeds depends on what the file system policy allows for unauthenticated clients. If no file system policy exists at all, the default behaviour is permissive: anything that can reach the mount target over the network may mount, and only POSIX permissions apply. That default is the thing candidates most often get wrong. ## The three layers, in order A good answer names all three and says which failure each one produces: 1. **Network** — the mount target's security group. Blocked here, the mount hangs. 2. **IAM** — the file system policy, evaluated for IAM-authenticated mounts. Denied here, the mount fails with a permission error. 3. **POSIX** — the access point's enforced root directory and identity, plus ordinary file mode bits. Denied here, individual operations fail with EACCES. Defence in depth matters because each layer covers the others' gaps: a security group cannot distinguish two applications on the same instance, IAM cannot express per-file permissions, and POSIX modes cannot stop an untrusted host from mounting in the first place. ## Practical design One file system per isolation boundary is still the strongest answer when tenants are genuinely untrusted — a shared file system means a shared blast radius for throughput, quota and backup. Access points are the right tool for *cooperating* applications inside one trust boundary: per-application directories, distinct enforced uids, an explicit file system policy pinning each role to its access point, `aws:SecureTransport` required, and `ClientRootAccess` granted to nobody unless a specific workload genuinely needs it.