This chapter covers Amazon Elastic File System (EFS), a scalable, fully managed NFS file system for use with AWS cloud services and on-premises resources. Understanding EFS is critical for the CLF-C02 exam as it appears in Domain 3: Cloud Technology Services, Objective 3.2 (Identify storage services and their use cases). This objective carries approximately 15% of the exam weight, and EFS is one of the three primary storage services (alongside S3 and EBS) that you must be able to differentiate. By the end of this chapter, you will understand EFS's architecture, use cases, performance modes, storage classes, and how to choose between EFS and other storage options.
Jump to a section
Imagine your company has a large central filing cabinet in the office. Multiple employees need to access the same set of documents simultaneously. Each employee can pull out a folder, read it, update it, or add new pages. The filing cabinet automatically handles who is reading or writing, so two people can work on the same folder at the same time without losing changes—the cabinet ensures consistency. Now, this cabinet is not tied to any one desk; it sits in a common area accessible from any floor. You can add more shelves (increase capacity) without anyone noticing, and you only pay for the actual paper used and the electricity to light the cabinet. If you need more space, the cabinet expands instantly. This is exactly how Amazon EFS works: it's a shared, scalable file system that multiple EC2 instances can mount and access concurrently, with automatic scaling and pay-per-use pricing. The key mechanism is that EFS uses a standard NFSv4 protocol, so it behaves like a local drive but is actually a distributed, highly durable storage system spread across multiple Availability Zones. Just as the filing cabinet's drawers are logically organized but physically distributed, EFS stores files across multiple servers, yet presents a single coherent namespace.
What is Amazon EFS and What Problem Does It Solve?
Amazon Elastic File System (EFS) is a fully managed, scalable, and elastic NFS (Network File System) file system for use with AWS EC2 instances, on-premises servers via AWS Direct Connect or VPN, and AWS Lambda functions. It provides a simple, serverless, set-and-forget file storage that automatically grows and shrinks as you add and remove files, with no need for provisioning or managing storage capacity.
The problem EFS solves is the need for a shared file system that multiple compute instances can access simultaneously with low latency, high throughput, and strong consistency. Traditional on-premises file servers require manual capacity planning, hardware provisioning, and ongoing maintenance. In the cloud, you could attach an EBS volume to one instance, but sharing that volume across multiple instances is complex and not supported natively. EFS fills this gap by providing a POSIX-compliant file system that can be mounted concurrently by hundreds or thousands of EC2 instances across multiple Availability Zones, enabling workloads like content management systems, web serving, big data analytics, and development tools.
How EFS Works – The Mechanism
EFS is built on a distributed architecture. When you create an EFS file system, AWS provisions storage across multiple servers in multiple Availability Zones within a region (by default). The file system is accessed via the NFSv4.1 protocol, which is a standard network protocol for accessing files over a network. EC2 instances mount the EFS file system using a mount target—an NFS endpoint that exists in each Availability Zone where you want to mount the file system. Each mount target has its own IP address and is highly available within its zone.
Key components: - File system: The logical container for your data. It has a unique ID (e.g., fs-12345678). - Mount targets: NFS endpoints in each subnet of a VPC. You create one mount target per Availability Zone. The mount target is an elastic network interface (ENI) with a private IP address. - Security groups: Control inbound and outbound traffic to mount targets. Typically, you allow NFS traffic (port 2049) from EC2 instances. - Access points: Application-specific entry points into the EFS file system that enforce a specific POSIX identity and directory path.
When an EC2 instance mounts the file system, it connects to the mount target in its Availability Zone. All read and write requests are handled by the distributed file system backend, which replicates data across multiple servers and Availability Zones for durability. EFS is designed for 99.999999999% (11 nines) durability and 99.99% availability for Standard storage class.
Performance Modes and Storage Classes
EFS offers two performance modes: - General Purpose: For latency-sensitive use cases like web serving, content management, and development environments. It provides the lowest latency for file operations. - Max I/O: For high-throughput, highly parallel workloads like big data analytics, media processing, and genomics. It scales to higher levels of throughput and IOPS but with slightly higher latency.
EFS also has two throughput modes: - Bursting Throughput: Default mode. Throughput scales with the amount of data stored. You get a baseline throughput rate (50 MiB/s per TiB of storage) and can burst up to 100 MiB/s per TiB for a limited time using burst credits. - Provisioned Throughput: For workloads that require consistent, high throughput regardless of data size. You specify the throughput rate in MiB/s, and you pay for it regardless of usage.
Storage classes: - Standard: For frequently accessed data. Data is redundantly stored across multiple Availability Zones. - Infrequent Access (IA): For data accessed less than once a quarter. Costs less per GB-month but has a per-GB retrieval fee. You can set lifecycle policies to automatically move files to IA after a certain number of days. - Archive: For data accessed less than once a year. Lowest storage cost but highest retrieval cost. Data must be stored for at least 90 days.
You can also choose between Regional (data replicated across AZs) and One Zone (data stored in a single AZ) for cost savings, but One Zone has lower durability and availability.
Comparison to On-Premises and Competing AWS Services
On-premises file servers require significant capital expenditure, manual capacity planning, and ongoing administration. EFS eliminates these by being fully managed, elastic, and pay-per-use. Compared to other AWS storage services: - EBS: Block-level storage attached to a single EC2 instance. Cannot be shared across instances. EFS is file-level and can be shared. - S3: Object storage with a flat namespace. Accessed via HTTP/HTTPS, not NFS. S3 is ideal for large-scale data lakes, backups, and static website hosting. EFS is for traditional file system workloads that require POSIX permissions, locking, and concurrent access. - FSx for Windows File Server: A fully managed Windows file server that supports SMB protocol. Use when you need Windows-native features like Active Directory integration or SMB.
When to Use EFS vs Alternatives
Use EFS when:
You need a shared file system accessible from multiple EC2 instances (e.g., web server cluster sharing content).
Your application requires POSIX-compliant file operations (e.g., Linux-based workloads).
You want automatic scaling without provisioning.
You need high durability and availability (Standard class).
Do not use EFS when:
You need block-level storage for a single instance (use EBS).
You need object storage for massive data lakes (use S3).
You need Windows file sharing with SMB (use FSx for Windows).
Your workload requires very high IOPS per file (use EBS io2 volumes).
EFS is a key service for the CLF-C02 exam. Understand its features, performance modes, and storage classes, and be able to compare it with EBS and S3.
Create an EFS File System
Navigate to the Amazon EFS console and click 'Create file system'. You'll need to specify a name (optional), choose a VPC, and select the availability and durability settings. For most cases, choose Regional (replicated across AZs) for high availability. You can also choose One Zone for cost savings but lower resilience. The file system is created with an ID like 'fs-12345678'. No storage capacity is provisioned—EFS is elastic. Behind the scenes, AWS sets up the distributed infrastructure, including the mount targets you'll create next. Note that you cannot change the performance mode (General Purpose or Max I/O) after creation, so choose wisely based on your workload.
Create Mount Targets in Subnets
For each Availability Zone where you want EC2 instances to mount the file system, create a mount target in a subnet. The mount target is an NFS endpoint represented by an elastic network interface (ENI) with a private IP address. You must associate a security group that allows inbound NFS traffic (port 2049) from your EC2 instances. You can create mount targets in multiple AZs for high availability. Each mount target is specific to a subnet. If you have a VPC with three AZs, you might create a mount target in each AZ's subnet. The file system can be mounted from any instance in the same VPC (or connected network) by using the mount target's IP or DNS name.
Mount the File System on an EC2 Instance
SSH into your EC2 instance (Linux) and install the NFS client if not already present. Use the 'mount' command with the EFS mount helper or standard NFS options. The command looks like: `sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport [mount-target-IP]:/ /mnt/efs`. Alternatively, use the EFS mount helper: `sudo mount -t efs -o tls fs-12345678:/ /mnt/efs`. The TLS option encrypts data in transit. After mounting, the file system appears as a local directory. You can verify by writing a test file. The instance can now read and write files that are immediately visible to other instances mounting the same EFS file system.
Set Up Lifecycle Management
To optimize costs, configure lifecycle policies to automatically move files to Infrequent Access (IA) or Archive storage classes after a specified number of days. For example, you can create a policy that moves files not accessed for 30 days to EFS IA, and files not accessed for 90 days to EFS Archive. This is done in the EFS console under the 'Lifecycle management' tab. You can also set policies for both IA and Archive. Note that files moved to IA incur a retrieval fee when accessed. Lifecycle management is automatic and transparent to applications—they still see a unified namespace. This feature is important for exam questions about cost optimization.
Monitor and Scale
EFS automatically scales storage capacity as you add or remove files. No manual intervention is needed. However, you can monitor performance using Amazon CloudWatch metrics like 'BurstCreditBalance', 'PercentIOLimit', 'Throughput', and 'MeteredIOBytes'. If your workload requires consistent high throughput, consider switching to Provisioned Throughput mode. You can also enable encryption at rest (enabled by default for new file systems) and enforce encryption in transit using the 'tls' mount option. For security, use IAM policies to control access to the file system, and use access points to enforce specific user IDs and directory paths per application.
Real-World Scenarios
1. Web Server Content Management A media company runs a cluster of EC2 instances behind an Application Load Balancer serving a PHP-based website. All instances need to access the same set of images, videos, and HTML templates. They mount an EFS file system at /var/www/html. When a content editor uploads a new image via the admin panel, it is written to EFS and instantly available to all web servers. EFS's automatic scaling handles growth from 10 GB to 2 TB over time without any downtime. The company uses the Standard storage class for frequently accessed files and a lifecycle policy to move older, rarely accessed content to IA after 90 days, reducing storage costs by 40%. Misconfiguration: Initially, they forgot to enable encryption in transit, exposing data to potential interception. They fixed it by remounting with the 'tls' option.
2. Big Data Analytics with Spark A financial services firm runs Apache Spark clusters on EC2 for risk analysis. They need a shared file system for input data, intermediate results, and output. They use EFS in Max I/O performance mode to achieve high throughput for parallel reads and writes. The file system is mounted on all cluster nodes. EFS's elasticity eliminates the need to pre-provision storage, and the bursting throughput model works well for their bursty workloads. They set up lifecycle policies to move historical data to Archive after 180 days. Cost consideration: They initially used Provisioned Throughput but switched to Bursting after analyzing usage patterns, saving 30% on throughput costs. Common mistake: Not creating mount targets in all AZs, causing cross-AZ data transfer charges and increased latency.
3. Home Directories for Developers A SaaS startup provides Linux-based development environments using EC2 instances. They use EFS to host home directories for each developer. When a developer logs into any instance, their home directory is automatically mounted via a script, providing a consistent environment. EFS access points enforce that each developer can only access their own directory. The system scales as the team grows from 10 to 200 developers. They use the One Zone storage class to save costs, accepting the lower availability. What went wrong: One developer accidentally deleted critical project files. EFS has no built-in versioning or recycle bin (unlike S3). They now use EFS backups with AWS Backup to restore files. This scenario highlights the need for backup strategies with EFS.
Exam Focus for CLF-C02
1. What CLF-C02 Tests on This Objective Domain 3: Cloud Technology Services, Objective 3.2: 'Identify storage services and their use cases.' For EFS, you must know:
EFS is a scalable, elastic NFS file system for Linux-based workloads (EC2, on-premises, Lambda).
It supports NFSv4.1 protocol.
It is designed for shared access across multiple instances concurrently.
It automatically scales storage capacity—no provisioning needed.
Key use cases: web serving, content management, big data analytics, media processing, home directories.
Performance modes: General Purpose (low latency) and Max I/O (high throughput, parallel).
Storage classes: Standard, Infrequent Access (IA), Archive, and One Zone.
Lifecycle policies to move data between classes.
Bursting and Provisioned Throughput models.
2. Common Wrong Answers and Why Candidates Choose Them - *Wrong*: 'EFS can be used for Windows EC2 instances.' Reality: EFS supports NFS, which is native to Linux. Windows instances typically use SMB via FSx for Windows File Server. Candidates confuse EFS with FSx. - *Wrong*: 'EFS provides block-level storage.' Reality: EFS is file-level (NFS). Block-level is EBS. Candidates mix up storage types. - *Wrong*: 'EFS requires you to provision storage capacity in advance.' Reality: EFS is elastic and scales automatically. Candidates think of EBS. - *Wrong*: 'EFS can be mounted on only one EC2 instance at a time.' Reality: EFS is designed for concurrent access from many instances. Candidates confuse with EBS (single-attach).
3. Specific Terms and Values - NFSv4.1 protocol - Mount target - Bursting throughput: baseline 50 MiB/s per TiB, burst up to 100 MiB/s per TiB - 11 nines durability (99.999999999%) - 99.99% availability for Standard class - Lifecycle policy: move to IA after 30 days (default recommendation) - One Zone storage class: 99.999999999% durability but only in one AZ
4. Tricky Distinctions - EBS vs EFS: EBS is block storage attached to a single instance; EFS is file storage shared across instances. - S3 vs EFS: S3 is object storage with HTTP access; EFS is file storage with NFS access. - EFS vs FSx: EFS is for Linux/NFS; FSx for Windows is for Windows/SMB; FSx for Lustre is for high-performance computing.
5. Decision Rule for Multiple Choice If the question mentions 'shared file system', 'concurrent access', 'multiple EC2 instances', 'NFS', or 'Linux', the answer is likely EFS. If 'block storage', 'single instance', 'boot volume', choose EBS. If 'object storage', 'HTTP', 'unlimited storage', choose S3. If 'Windows file sharing', 'SMB', choose FSx for Windows.
Amazon EFS is a fully managed, scalable NFS file system for Linux workloads, accessed via NFSv4.1 protocol.
EFS automatically scales storage capacity; you only pay for what you use (per GB-month).
Two performance modes: General Purpose (low latency) and Max I/O (high throughput, parallel).
Storage classes: Standard (multi-AZ), Infrequent Access (IA), Archive (lowest cost), One Zone (single AZ).
Lifecycle policies automatically move data between storage classes to optimize costs.
Throughput modes: Bursting (default, scales with storage) and Provisioned (fixed throughput).
EFS is designed for shared access from multiple EC2 instances concurrently across AZs.
EFS does not support SMB protocol; use FSx for Windows for Windows-based file sharing.
EFS cannot be used as a boot volume; use EBS for that.
EFS is durable (11 nines) and available (99.99% for Standard class).
These come up on the exam all the time. Here's how to tell them apart.
Amazon EFS
File-level storage (NFS)
Shared across multiple EC2 instances
Automatically scales capacity
POSIX-compliant
Use cases: web serving, content management, big data
Amazon EBS
Block-level storage
Attached to a single EC2 instance (multi-attach available for some types)
Must provision capacity in advance (GB increments)
Can be used as boot volume
Use cases: databases, boot volumes, transactional workloads
Mistake
EFS can be used as a boot volume for EC2 instances.
Correct
EFS is a file system, not a block device. EC2 instances boot from EBS volumes (root device). EFS cannot be used as a boot volume.
Mistake
EFS requires you to choose a storage capacity when creating the file system.
Correct
EFS is elastic and automatically scales. You do not provision storage capacity. You only pay for the data you store.
Mistake
EFS only works within a single Availability Zone.
Correct
By default, EFS is Regional (data replicated across multiple AZs). You can choose One Zone for single-AZ deployment, but the default is multi-AZ.
Mistake
EFS supports both NFS and SMB protocols.
Correct
EFS only supports NFSv4.1 (and earlier NFS versions). For SMB, use Amazon FSx for Windows File Server.
Mistake
EFS data is automatically versioned like S3.
Correct
EFS does not support versioning. You must use AWS Backup or other tools for backups and versioning.
Yes, that is the primary use case for EFS. Multiple EC2 instances can mount the same EFS file system concurrently, and they can read and write files simultaneously. EFS provides strong consistency, so after a write is complete, subsequent reads from any instance will reflect that write. This is ideal for web server clusters, content management systems, and big data analytics. Ensure you create mount targets in each Availability Zone where your instances reside to avoid cross-AZ data transfer charges.
EFS Standard stores data redundantly across multiple Availability Zones (AZs) within a region, providing 99.999999999% durability and 99.99% availability. EFS One Zone stores data in a single AZ, offering the same durability but lower availability (99.999999999% durability within that AZ, but if the AZ fails, data is lost). One Zone costs about 47% less than Standard. Use One Zone for non-critical, reproducible data where lower availability is acceptable.
You pay for the amount of data stored per GB-month, plus any data transfer costs. There are different rates for Standard, IA, Archive, and One Zone. You also pay for throughput if you choose Provisioned Throughput mode (per MB/s per month). There is no charge for mounting or unmounting. Lifecycle policies are free. Data retrieval from IA or Archive incurs a per-GB fee. There is a minimum storage duration charge for IA (30 days) and Archive (90 days).
The maximum file size in EFS is 52,673,613,135,872 bytes (approximately 52.6 TB). This is the same as the maximum file size supported by the NFSv4.1 protocol. The total file system size can grow to petabytes, as it is elastic.
Yes, you can mount EFS file systems on on-premises servers using AWS Direct Connect or AWS Site-to-Site VPN. The on-premises server must have an NFS client and network connectivity to the EFS mount target. This allows hybrid cloud workloads where on-premises applications need access to cloud storage.
Bursting Throughput is the default mode. Throughput scales with the amount of data stored: baseline of 50 MiB/s per TiB, with ability to burst up to 100 MiB/s per TiB using burst credits. Provisioned Throughput allows you to specify a fixed throughput rate (e.g., 200 MiB/s) regardless of storage size, which is useful for workloads that need consistent high throughput. You pay for the provisioned throughput even if you don't use it.
Yes, EFS supports encryption at rest (using AWS KMS) and encryption in transit (using TLS). Encryption at rest is enabled by default when you create a new file system. Encryption in transit is optional but recommended; you enable it by using the 'tls' option when mounting (e.g., 'mount -t efs -o tls').
You've just covered Amazon EFS — Elastic File System — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?