Cargando...
Cargando...
Fully managed, serverless, elastic NFS file storage that scales automatically and mounts across thousands of EC2 instances simultaneously
Amazon Elastic File System (EFS) is a fully managed, serverless Network File System (NFS) that automatically grows and shrinks as you add and remove files — no capacity planning required. It supports the NFSv4 protocol and can be mounted concurrently by thousands of Amazon EC2 instances, ECS tasks, EKS pods, and Lambda functions across multiple Availability Zones. EFS is purpose-built for shared file workloads requiring POSIX-compliant, low-latency access from multiple compute resources simultaneously.
Provide a shared, POSIX-compliant, elastic NFS file system accessible simultaneously from multiple compute instances across multiple AZs — solving the 'shared file storage' problem that EBS (single-instance block storage) cannot address
Use When
Avoid When
Multi-AZ Mount Targets
Create mount targets in each AZ for high availability. All mount targets point to the same shared file system data.
Automatic Elasticity (No capacity provisioning)
Grows and shrinks automatically. Pay only for what you use. This is the #1 differentiator from EBS.
POSIX Permissions
Full POSIX-compliant file system semantics including file locking, permissions, and ownership.
Encryption at Rest
Uses AWS KMS. Can be enabled at file system creation. Cannot be added to an existing unencrypted file system without migration.
Encryption in Transit
TLS 1.2 via the EFS mount helper (amazon-efs-utils). Must use mount helper — not automatic with standard NFS mount command.
Performance Modes: General Purpose
Default mode. Ideal for latency-sensitive workloads like CMS, web serving, home directories. Recommended for most use cases.
Performance Modes: Max I/O
Higher aggregate throughput and IOPS but with slightly higher latency. For highly parallelized workloads (big data, media processing). Cannot be changed after creation.
Throughput Modes: Bursting
Default. Throughput scales with storage size. Uses burst credits (similar to EBS gp2 model).
Throughput Modes: Provisioned
Set throughput independently of storage size. Billed for provisioned amount above storage-based baseline.
Throughput Modes: Elastic
Newest mode. Automatically scales throughput up and down based on workload. Pay only for what you use. Best for spiky or unpredictable workloads.
Storage Classes: Standard
For frequently accessed files. Stored redundantly across multiple AZs.
Storage Classes: Standard-Infrequent Access (Standard-IA)
Lower storage cost but per-request retrieval fee. Multi-AZ redundancy maintained.
Storage Classes: One Zone
Stores data in a single AZ. Lower cost than Standard. Suitable for dev/test or non-critical workloads.
Storage Classes: One Zone-IA
Lowest cost EFS storage class. Single AZ + infrequent access pricing. Up to 95% lower cost than Standard.
Lifecycle Management
Automatically moves files to IA storage class after a configurable period of inactivity (7, 14, 30, 60, or 90 days). Similar concept to S3 lifecycle policies.
EFS Access Points
Application-specific entry points that enforce POSIX user identity and root directory. Ideal for multi-tenant applications, containers, and Lambda.
AWS Backup Integration
Native integration with AWS Backup for centralized, automated EFS backups with point-in-time recovery.
EFS Replication
Replicate EFS file systems to another AWS Region for disaster recovery. RPO in minutes. Destination is read-only.
VPC Peering / Transit Gateway Mount
Can mount EFS across VPCs using VPC peering or Transit Gateway. Enables cross-account and cross-VPC shared file systems.
AWS Direct Connect / VPN Mount (On-premises)
Mount EFS from on-premises servers via Direct Connect or VPN. Enables hybrid NFS workloads.
Lambda Integration via Access Points
Lambda functions can mount EFS file systems using access points. Enables sharing large ML models, libraries, or data between Lambda invocations.
Windows Client Support (Native)
EFS does NOT support SMB/CIFS. Windows clients cannot mount EFS. Use FSx for Windows File Server for Windows workloads.
S3 Event Triggers
EFS does not have native S3 event integration. Use DataSync or custom Lambda to move data between EFS and S3.
Shared Web Content / Stateful Application Storage
high freqMultiple EC2 instances in an Auto Scaling Group mount the same EFS file system via NFS. All instances share the same files (e.g., user uploads, session data, config files). Mount target is created in each AZ for HA. This is the most common EFS pattern and the most tested.
Lambda Shared File System via Access Points
high freqLambda functions mount EFS using EFS Access Points. Enables Lambda to access large ML models, shared libraries, or persistent data that exceeds Lambda's /tmp limit (512 MB - 10 GB). Lambda must be in a VPC to use EFS. Access Points enforce POSIX identity and root directory.
Container Persistent Shared Storage
high freqECS tasks (EC2 or Fargate launch type) mount EFS volumes for persistent, shared storage. Solves the stateful container problem — containers can be replaced while data persists in EFS. Defined in task definition as a volume with EFS volume configuration.
EFS Performance Monitoring
high freqCloudWatch provides EFS metrics including BurstCreditBalance, PercentIOLimit, TotalIOBytes, MeteredIOBytes, and ClientConnections. Monitor BurstCreditBalance to detect when Bursting mode file systems are depleted — a drop to zero means throttled throughput. Set CloudWatch Alarms on BurstCreditBalance.
Data Migration to/from EFS
high freqAWS DataSync migrates data between on-premises NFS/SMB shares, S3, and EFS. Used for initial data migration to EFS or ongoing synchronization. Much faster than manual rsync — DataSync can use multiple parallel threads. Also used to copy data between EFS file systems (e.g., cross-region).
Tiered Storage Architecture
high freqUse EFS for active, frequently accessed shared file data requiring POSIX semantics. Use S3 for archival, object storage, or data lake purposes. DataSync or custom Lambda moves data between tiers. EFS Lifecycle Management moves infrequently accessed files to EFS-IA automatically.
Hybrid On-Premises to EFS Access
high freqAWS Storage Gateway (File Gateway) allows on-premises applications to access EFS (via S3 File Gateway) or use NFS/SMB protocols to connect to cloud storage. For direct on-premises NFS to EFS, use Direct Connect + EFS mount helper instead of Storage Gateway.
Kubernetes Persistent Volumes (PV) with EFS CSI Driver
high freqEKS uses the EFS CSI Driver to provision EFS-backed Persistent Volumes for Kubernetes pods. Multiple pods across multiple nodes can mount the same EFS PV simultaneously (ReadWriteMany access mode). EBS only supports ReadWriteOnce — this is a key differentiator for Kubernetes workloads.
Security Vulnerability Assessment
low freqAmazon Inspector assesses EC2 instances that mount EFS for security vulnerabilities and unintended network accessibility. Inspector evaluates NFS mount configurations and security group rules to identify overly permissive EFS access.
EFS = Shared NFS (multi-instance, multi-AZ, Linux only). EBS = Block storage (single instance, single AZ by default, any OS). S3 = Object storage (HTTP/HTTPS, unlimited objects, any client). When an exam question mentions 'multiple EC2 instances sharing the same files simultaneously,' the answer is almost always EFS.
EFS does NOT support Windows (SMB/CIFS). If the question mentions Windows servers needing shared file storage, the answer is Amazon FSx for Windows File Server, NOT EFS. EFS only speaks NFS (Linux/Unix).
EFS is NOT suitable for database storage. Exam questions may present EFS as an option for storing RDS data files or running MySQL on EC2 with EFS storage — this is always wrong. Databases need block storage (EBS) for consistent low-latency I/O and ACID compliance.
Bursting Throughput mode ties throughput to storage size. A file system with only 1 GB stored gets very limited burst throughput. If a question describes a small file system needing high throughput, the solution is to switch to Provisioned Throughput or Elastic Throughput mode — NOT to add more files.
Performance Mode (General Purpose vs Max I/O) CANNOT be changed after file system creation. This is a design-time decision. General Purpose has lower latency; Max I/O supports higher aggregate throughput for massively parallel workloads but with higher latency per operation.
When a question asks for shared file storage accessible by multiple EC2 instances simultaneously → EFS (not EBS, not S3). EBS = one instance (block), S3 = objects (HTTP), EFS = shared files (NFS/Linux).
EFS NEVER for databases, NEVER for Windows (SMB). Databases need EBS block storage. Windows needs FSx for Windows File Server. These two rules eliminate EFS from ~30% of trick questions.
Bursting Throughput mode = throughput tied to storage size. Small file system + high throughput need = switch to Provisioned or Elastic Throughput mode. Monitor BurstCreditBalance in CloudWatch.
EFS Standard-IA and One Zone-IA storage classes charge a per-request fee when files are READ. Lifecycle Management automatically moves files to IA after inactivity. If a workload accesses files infrequently but pays high retrieval costs, consider whether IA is actually cost-effective — small files accessed occasionally may cost more in retrieval than they save in storage.
For Lambda to use EFS, three things must be true: (1) Lambda function must be configured to run inside a VPC, (2) An EFS Access Point must be configured, (3) Lambda execution role must have elasticfilesystem:ClientMount permission. This enables Lambda to share large files (ML models, etc.) across invocations.
EFS encryption at rest CANNOT be enabled on an existing unencrypted file system. You must create a new encrypted file system and migrate data (using DataSync or rsync). Encryption in transit requires the EFS mount helper (amazon-efs-utils) with the 'tls' mount option — standard NFS mount command does NOT encrypt in transit.
One Zone storage class stores data in a single AZ. If that AZ has an outage, your data is unavailable. Use Standard (multi-AZ) for production workloads. One Zone is appropriate for dev/test, backup, or easily reproducible data. One Zone-IA is the cheapest EFS option — up to 95% less than Standard.
EFS Replication creates a read-only replica in another region with an RPO measured in minutes. The destination file system cannot be written to until you fail over (which promotes it to a standalone writable file system). This is EFS's native DR solution — know this for SAA-C03 and SAP-C02 disaster recovery scenarios.
Monitor BurstCreditBalance in CloudWatch for EFS file systems using Bursting Throughput mode. When BurstCreditBalance approaches zero, the file system is throttled to its baseline throughput. The fix is either: add more data (increases baseline), switch to Provisioned Throughput, or switch to Elastic Throughput.
EFS Access Points are the recommended way to give containers and Lambda functions scoped access to specific directories within a shared EFS file system. Each Access Point enforces a specific POSIX user/group ID and a root directory — the client cannot navigate above the access point root. Critical for multi-tenant isolation.
Common Mistake
EFS is just like EBS but allows multiple instances to connect — they're both good for databases
Correct
EFS is a network file system (NFS) with higher latency than EBS block storage. EFS is fundamentally incompatible with most database engines because databases require block-level I/O, predictable low latency, and specific locking semantics that NFS cannot reliably provide. EBS (especially io2) is the correct choice for database storage on EC2.
This is the #1 EFS misconception on exams. Questions will offer EFS as a tempting option for 'shared database storage across multiple EC2 instances' — always reject this. The correct architecture is RDS (managed) or EBS with a single EC2 primary + standby, not EFS.
Common Mistake
EFS can be mounted by Windows EC2 instances just like Linux instances
Correct
EFS ONLY supports NFS protocol (v4.0 and v4.1). Windows Server requires SMB/CIFS protocol. Windows EC2 instances cannot natively mount EFS. For shared Windows file storage, use Amazon FSx for Windows File Server (SMB-based, Active Directory integrated).
Exam questions frequently present EFS alongside FSx for Windows as options for 'shared file storage for Windows workloads.' Knowing EFS = Linux/NFS only eliminates EFS immediately in Windows scenarios. Remember: EFS = Linux, FSx for Windows = Windows, FSx for Lustre = HPC/ML.
Common Mistake
EFS and S3 are both 'file storage' and can be used interchangeably
Correct
EFS is a POSIX-compliant network file system accessed via NFS mount — it behaves like a local drive with directories, permissions, and file locking. S3 is object storage accessed via HTTP/HTTPS API — there are no directories (only key prefixes), no file locking, and no POSIX semantics. They solve completely different problems.
The CLF-C02 and SAA-C03 exams test storage type knowledge heavily. EFS = file storage (NFS, POSIX, mounted). S3 = object storage (API, HTTP, unlimited scale). EBS = block storage (attached drive, single instance). Memorize this triangle — it appears in nearly every storage question.
Common Mistake
EFS automatically provides high throughput for any workload regardless of how much data is stored
Correct
In Bursting Throughput mode (the default), EFS throughput scales with the amount of data stored. A file system with only a few GB of data gets very limited baseline throughput and limited burst capacity. Small file systems can be severely throughput-constrained in Bursting mode. Use Provisioned or Elastic Throughput for workloads needing high throughput with small storage footprints.
This is a subtle but frequently tested trap. A question might describe an application with a small EFS file system experiencing slow performance — the correct diagnosis is insufficient burst credits/baseline throughput, and the fix is switching throughput modes, not adding more storage or changing instance types.
Common Mistake
EFS Infrequent Access (IA) storage class is always cheaper than Standard — you should always enable Lifecycle Management
Correct
EFS IA charges a per-GB retrieval fee every time a file is accessed. For files that are accessed even occasionally, the retrieval costs can exceed the storage savings. IA is cost-effective for files that are truly rarely accessed (e.g., logs, backups, compliance archives). If files are accessed more than a few times per month, Standard may be cheaper overall.
Exam questions on cost optimization may ask you to choose between EFS storage classes. Understand that IA has TWO cost components: lower storage price + per-request retrieval fee. The break-even point depends on access frequency. This mirrors the S3 IA vs S3 Standard cost model.
Common Mistake
AWS Storage Gateway is the best way to connect on-premises servers to EFS
Correct
Storage Gateway is a hybrid connector that primarily bridges on-premises applications to S3 (via File Gateway, Volume Gateway, or Tape Gateway). For on-premises servers needing direct NFS access to EFS, the correct solution is AWS Direct Connect (or VPN) combined with the EFS mount helper. Storage Gateway does not directly expose EFS to on-premises clients.
Exam questions may offer both Storage Gateway and Direct Connect+EFS as options for hybrid NFS scenarios. Storage Gateway connects to S3, not EFS. Direct Connect + EFS mount = direct on-premises NFS access to EFS. Know which service bridges to which backend.
EFS = 'Elastic File Sharing' — remember the S stands for Sharing (multiple clients), not Single (like EBS). When you see 'share files between multiple EC2 instances,' think EFS.
Storage Triangle: EBS = Block (Boot/Database), EFS = Files (Shared/NFS/Linux), S3 = Simple Storage (Objects/HTTP/Everything-else). B-F-O: Block-File-Object.
EFS Protocol Rule: 'E is for Everyone (Linux)' — EFS speaks NFS for Linux. 'W is for Windows' — FSx for Windows speaks SMB. Never mix them.
EFS Throughput Trap: 'Small data, small throughput' in Bursting mode. If the file system is small and throughput is low, switch to Provisioned or Elastic throughput — don't add dummy files.
Performance Mode memory: 'General Purpose = General public (most workloads, low latency).' 'Max I/O = Massive parallel (big data, media, HPC).' Once chosen, it's PERMANENT — choose wisely at creation.
CertAI Tutor · CLF-C02, SAA-C03, SAP-C02, DEA-C01, DOP-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons