EFS File System Mount

Prerequisites (AWS Console — Before SSH)

Allow NFS Traffic (Security Group)

1. Go to EC2 → Security Groups
2. Select the security group attached to your EFS mount targets
3. Add Inbound Rule:
   • Type: NFS
   • Protocol: TCP
   • Port: 2049
   • Source: EC2 security group (or VPC CIDR e.g. 172.31.0.0/16)

Create & Attach IAM Role to EC2

1. Go to IAM → Roles → Create Role
2. Trusted entity: AWS Service → Use case: EC2 → Next
3. Search and attach policy: AmazonElasticFileSystemClientReadWriteAccess
4. Name the role (e.g., EC2-EFS-Access-Role) → Create Role
5. Go to EC2 → Instances → Select your instance
6. Actions → Security → Modify IAM Role
7. Select EC2-EFS-Access-Role → Update IAM Role

---

On the EC2 Instance (SSH Commands)

Step 1 — Install EFS Mount Helper

# Amazon Linux 2 / Amazon Linux 2023
sudo yum install -y amazon-efs-utils

# Ubuntu / Debian
sudo apt-get install -y amazon-efs-utils

Step 2 — Create Mount Point

sudo mkdir /efs

Step 3 — Mount the EFS File System

_netdev — waits for network before mounting (critical for EFS).
tls — encrypts data in transit.
iam — uses EC2 IAM role for authentication.

# Basic mount
sudo mount -t efs fs-0b68cf10e5589645a:/ /efs 

# Recommended — with TLS encryption in transit
sudo mount -t efs -o tls fs-0abc1234:/ /efs

# With IAM role authentication + TLS (most secure)
sudo mount -t efs -o iam,tls fs-0b68cf10e5589645a:/ /efs

Step 4 — Verify Mount

df -h /efs
lsblk
mount | grep efs

Step 5 — Persist Mount (Survive Reboots)

sudo nano /etc/fstab

Add this line:

fs-0b68cf10e5589645a:/  /efs  efs  defaults,_netdev,tls,iam  0  0

Step 6 — Set Ownership

sudo chown ec2-user:ec2-user /efs

Step 7 — Write & Read Test

# Write a file
echo "Hello from $(hostname)" > /efs/test.txt

# Read it back
cat /efs/test.txt

Step 8 — Test Shared Access (on a Second EC2 Instance)

# Repeat Steps 1–6 on Instance 2, then:
cat /efs/test.txt
# You should see: Hello from <Instance-1-hostname>

IAM Policies — Quick Reference

Policy	Use Case
AmazonElasticFileSystemClientReadWriteAccess	✅ Mount + read + write (most common)
AmazonElasticFileSystemClientFullAccess	Mount + read + write + root access
AmazonElasticFileSystemReadOnlyAccess	Read-only access
AmazonElasticFileSystemFullAccess	Admin — create/delete EFS (not just mount)

Custom Least-Privilege Policy (Production)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:ACCOUNT_ID:file-system/fs-0abc1234"
      # arn:aws:elasticfilesystem:us-east-1:795731011370:file-system/fs-0b0aee4f8ac244b26
    }
  ]
}

Permission	What it Allows
ClientMount	Mount the file system
ClientWrite	Write files (remove for read-only)
ClientRootAccess	Access as root (remove if not needed)

EFS Access Points

Amazon EFS Access Points are application-specific entry points into an EFS (Elastic File System) file system that make it easier to manage application access to shared datasets.

The Problem They Solve

Without access points, all applications mounting the same EFS share the same root (/) and file permissions — making multi-tenant or multi-app setups messy and insecure.

Key Features

1. Custom Root Directory

Each access point can enforce a specific directory as the root. Apps see only that subtree, not the full filesystem.

EFS Root /
├── /app1-data   ← Access Point A sees this as "/"
├── /app2-data   ← Access Point B sees this as "/"
└── /shared

2. POSIX Identity Enforcement

You can enforce a specific UID/GID for all file operations through that access point — regardless of what the client sends. This prevents privilege escalation.

"PosixUser": { "Uid": 1001, "Gid": 1001 },
"RootDirectory": {
  "Path": "/app1-data",
  "CreationInfo": { "OwnerUid": 1001, "OwnerGid": 1001, "Permissions": "755" }
}

3. Automatic Directory Creation

If the root directory doesn’t exist, EFS creates it automatically with the ownership/permissions you define.

Common Use Cases

Use Case	How Access Points Help
EKS / Kubernetes	Each pod/namespace gets its own isolated directory
Multi-tenant SaaS	One EFS, isolated paths per tenant
Lambda functions	Simplified mounting with enforced identity
CI/CD pipelines	Each job gets a scoped working directory