Right, so you’ve got your EFS file system mounted. It’s a big, beautiful, shared POSIX file system sitting in your VPC. Wonderful. Now, how do you actually use it? If you let every application and user just run wild on the root of the file system, you’re going to have a bad time. It’s the digital equivalent of a shared house with no room doors—chaos, missing milk, and someone’s weird stuff everywhere.

This is where EFS Access Points come in to save your sanity. Think of an Access Point not as a physical thing, but as a very specific, application-specific bouncer for your file system. It sits on the door and says, “Alright, you’re Application X. When you come in, I’m going to force you to use this specific directory, and oh, by the way, I’m going to change your POSIX identity to this specific UID/GID so you stop messing with Application Y’s files.”

Why You’d Use This Beautiful Contraption

The classic problem with a shared file system is multi-tenancy. App A runs as user app-a (uid 1000) and App B runs as app-b (uid 1001). If both need to write to the same EFS, their permissions can clash. You could try to meticulously set up the directory structure and permissions on the EFS itself, but then you’re one rm -rf away from a catastrophe. An Access Point enforces this at the mount level. It makes the file system look different to different applications, isolating them from each other even though they’re using the same underlying storage. It’s the cleanest way to achieve application isolation without needing a PhD in chmod and chown.

The Guts of an Access Point: POSIX Identity Enforcement

When you create an Access Point, you define four key pieces of POSIX identity that it will enforce for any client that connects through it:

  1. POSIX User: The User ID (UID) that all file operations will be forced to use.
  2. POSIX Group: The primary Group ID (GID).
  3. Secondary GIDs: A list of supplementary groups. This is crucial for apps that need access beyond their primary group.
  4. Root Directory: The directory that will act as the effective root ("/") for any client using this access point. If it doesn’t exist, EFS will create it with the ownership specified by the UID/GID you set. This is brilliantly opinionated and saves you a setup script.

Here’s how you create one of these enforcers using the AWS CLI. Let’s say we have a WordPress installation that we want to lock down.

# Create an Access Point for a WordPress app
# It will force all operations to use uid/gid 1000/1000
# and its root will be the '/wp-content' directory on the actual EFS
aws efs create-access-point \
    --file-system-id fs-12345678 \
    --posix-user Uid=1000, Gid=1000 \
    --root-directory "Path=/wp-content,CreationInfo={OwnerUid=1000,OwnerGid=1000,Permissions=0755}" \
    --tags Key=Name,Value=wordpress-app

The magic is in the --root-directory. When your WordPress container mounts the file system using this Access Point’s ID (fsap-12345abcd), it won’t see the root of the EFS. It will only see what’s inside /wp-content. It can’t cd .. and see other apps’ directories. It’s jailed, happily and securely.

Mounting with an Access Point: This is the Cool Part

You don’t mount the file system ID (fs-12345678) directly anymore. You mount the Access Point ID (fsap-12345abcd). The mounting command, whether in an EC2 userdata script or a task definition, looks almost identical. The system takes care of the rest.

# Mounting the EFS using the Access Point instead of the generic filesystem
sudo mount -t efs -o tls,accesspoint=fsap-12345abcd fs-12345678:/ /mnt/efs-wordpress

In ECS or EKS, this is where it truly shines. Your task definition specifies the Access Point ARN, and that’s it. The container gets the exact view of the file system you designed for it, with no possibility of it trampling over other data.

The Crucial Fine Print and “Gotchas”

  • Permission Conflicts are Real: The most common face-palm moment is when the POSIX user in your Access Point doesn’t have the correct permissions on the files within the directory structure. If your WordPress container (uid 1000) is trying to write to a directory owned by uid 1001, it will get permission denied. The Access Point forces the identity; it doesn’t magically grant permissions. You still have to get your ownership and chmod right within the directory tree it can see.
  • It’s Not a Security Forcefield: Access Points control the POSIX identity. They do not, by themselves, override IAM. You still need the elasticfilesystem:ClientMount and elasticfilesystem:ClientWrite IAM permissions on the EFS resource itself for the principal (e.g., an EC2 instance role or ECS task role) that’s performing the mount. The Access Point just defines how they access it after IAM lets them in the door.
  • NFS Clients Still Matter: The underlying protocol is still NFSv4.1, with all its quirks and behaviors. The Access Point is a brilliant layer of abstraction on top of it, but it doesn’t rewrite the laws of NFS physics.

The bottom line? Use Access Points by default for every new application you connect to EFS. They are the single best way to bring order, security, and sanity to your shared file storage. They turn a wild-west POSIX volume into a well-managed, multi-tenant apartment building.