Skip to content

Amazon Elastic File System (Amazon EFS)

What Is This Service?

Amazon Elastic File System (EFS) is a fully managed, elastic, serverless NFS file system that provides shared POSIX file storage across multiple compute instances.

Designed for:

  • Shared application storage
  • Containers
  • Web applications
  • Analytics
  • Home directories
  • Lift-and-shift workloads

Mental model:
EFS = managed elastic shared filesystem for many clients.

Unlike block storage:

EBS → One filesystem per volume
EFS → One filesystem shared across clients

Why It Matters for Security

Shared filesystems create security challenges:

  • Data exposure across workloads
  • Multi-client authorization
  • Encryption enforcement
  • Centralized access control

Security goals:

  • Centralize shared storage
  • Eliminate local copies
  • Enforce identity-aware access
  • Encrypt data at rest and in transit
  • Secure multi-AZ workloads

Security outcomes:

  • Reduced storage sprawl
  • Stronger access boundaries
  • Secure shared application architecture

Typical use cases:

  • Shared application content
  • Kubernetes persistent storage
  • Serverless shared state
  • User directories
  • CMS platforms

Architecture Example

flowchart LR

App1[EC2 App]

App2[EC2 App]

Lambda[Lambda]

EKS[EKS]

MT[Mount Targets]

EFS[Amazon EFS]

KMS[KMS]

SG[Security Groups]

App1 --> MT

App2 --> MT

Lambda --> MT

EKS --> MT

MT --> EFS

KMS --> EFS

SG --> MT

Core architecture:

Clients
 ↓
Mount Target
 ↓
EFS

Core Concepts

Elastic File System

Characteristics:

  • Shared filesystem
  • POSIX-compliant
  • NFS-based
  • Serverless
  • Multi-AZ

Provides:

Grow automatically

No capacity provisioning.

Mount Targets (MOST TESTED)

Mount targets are:

Network endpoints

Created inside subnets.

Clients connect through:

NFS
↓
Mount Target
↓
EFS

Exam trap:

Mount targets are AZ-specific.

Recommended:

One per AZ

File Systems

Single EFS filesystem can support:

  • Thousands of clients
  • Shared namespace

Storage Classes

Standard

Stores across multiple AZs.

Highest durability.

Standard-IA

Lower-cost infrequently accessed storage.

Lifecycle managed.

One Zone

Single AZ.

Lower cost.

Reduced resilience.

One Zone-IA

Combines:

  • Single AZ
  • Infrequent access

Lifecycle Management

Automatically transitions:

Standard
 ↓
IA

Reduces cost.

Elastic Throughput

Automatically scales throughput.

Modern default model.

Provisioned Throughput

Explicit throughput allocation.

Useful for predictable workloads.

Bursting Throughput

Performance tied to storage size.

Older model.

Important Integrations

Amazon EC2

Primary compute integration.

Shared access across instances.

Amazon ECS / EKS

Supports:

  • Persistent containers
  • Shared workloads

Common Kubernetes pattern.

AWS Lambda

Supports mounting EFS.

Use cases:

  • Shared assets
  • ML models
  • Stateful functions

Exam trap:

Lambda supports EFS.

AWS Backup

Supports:

  • Backup
  • Restore

AWS KMS

Supports:

  • Encryption at rest

IAM (VERY HIGH VALUE)

Controls:

  • Mount authorization
  • Filesystem access

Unlike traditional NFS.

Critical distinction.

AWS Transit Gateway

Supports cross-VPC access.

AWS Direct Connect / VPN

Supports hybrid access.

Security Features

Encryption at Rest

Supports:

AWS KMS

Protects:

  • Files
  • Metadata

Encryption in Transit

Supports:

TLS

Mount helper:

amazon-efs-utils

Exam trap:

Enable explicitly.

IAM Authorization (HIGH VALUE)

Supports:

elasticfilesystem:ClientMount
elasticfilesystem:ClientWrite
elasticfilesystem:ClientRootAccess

Identity-aware mounting.

Unlike traditional NFS.

Access Points (VERY HIGH VALUE)

Application-specific entry points.

Can enforce:

  • Root directory
  • UID
  • GID

Pattern:

Application
 ↓
Access Point
 ↓
Restricted View

Most tested EFS feature.

Security Groups

Control:

NFS Port 2049

Network enforcement.

POSIX Permissions

Supports:

UID
GID
RWX

Filesystem authorization.

Advanced Security and Operational Concepts

Access Points = Multi-Tenant Isolation (MOST TESTED)

Access Points provide:

  • Namespace isolation
  • Identity enforcement

Example:

AppA → /teamA
AppB → /teamB

Without application changes.

EFS Uses NFSv4.1

Protocol:

NFSv4.1

Exam trap:

Not SMB.

IAM + POSIX Combined Authorization

Access decision:

IAM
+
POSIX

IAM:

Can mount?

POSIX:

Can access?

Critical exam distinction.

Multi-AZ by Default

Standard storage:

Multi-AZ

Unlike:

EBS

EFS Is Not HPC Storage

Wrong workload:

Massive parallel compute

Correct service:

FSx for Lustre

Throughput Models

Elastic:

Automatic

Provisioned:

Predictable

Bursting:

Storage dependent

Lambda + EFS Pattern

Architecture:

Lambda
 ↓
Access Point
 ↓
EFS

Supports persistent state.

Cross-Account Access

Supported using:

  • Networking
  • IAM
  • Resource policies

Workflow(s)

Mount Workflow

sequenceDiagram

participant App
participant SG
participant MT
participant EFS

App->>SG: Allow 2049

SG->>MT: NFS connect

MT->>EFS: Mount

EFS-->>App: Filesystem access

Access Point Workflow

sequenceDiagram

participant App
participant AccessPoint
participant EFS

App->>AccessPoint: Connect

AccessPoint->>EFS: Enforce UID/GID

EFS-->>App: Restricted filesystem

Lambda Shared Storage

sequenceDiagram

participant Lambda
participant AP
participant EFS

Lambda->>AP: Mount

AP->>EFS: File access

EFS-->>Lambda: Shared state

Comparisons

Service Storage Shared POSIX Best Use
EFS Files Yes Yes Shared apps
EBS Block No No Single host
FSx Lustre Parallel Files Yes Yes HPC
FSx ONTAP Enterprise NAS Yes Yes Hybrid
S3 Objects No No Data Lake

Common Exam Traps

  1. EFS uses mount targets.

  2. Mount targets are AZ-specific.

  3. EFS supports IAM authorization.

  4. Access Points isolate applications.

  5. Encryption in transit must be enabled.

  6. Lambda supports EFS.

  7. Standard is Multi-AZ.

  8. POSIX still applies.

  9. NFS port = 2049.

  10. EFS ≠ HPC storage.

  11. Throughput modes differ.

  12. Access Point enforces identity.

5-Second Recall

  • EFS = elastic shared filesystem
  • Mount Target = network entry
  • Access Point = isolation
  • IAM + POSIX together
  • NFSv4.1
  • Lambda supported
  • Multi-AZ by default

Quick Revision Notes

  • Shared POSIX storage
  • Serverless scaling
  • Mount targets per AZ
  • IAM authorization supported
  • Access Points isolate apps
  • Encryption via KMS + TLS
  • Lifecycle → IA tiers
  • Lambda integration
  • Not for HPC
  • Strong fit for shared workloads