# Amazon EFS

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/amazon-efs

## Quick definition

Amazon EFS is a cloud-based file storage service from Amazon Web Services that grows and shrinks automatically as you add or remove files. It allows many virtual servers to access the same files at the same time, similar to a shared network drive in an office. You don’t need to plan storage capacity ahead of time, and you only pay for the space you actually use.

## Simple meaning

Think of Amazon EFS like a giant shared filing cabinet that lives in the cloud. In a typical office, several people might need to access the same client files, contracts, or project documents. Instead of each person keeping their own copy on their personal computer, they connect to a shared network drive that holds the master copies. Amazon EFS is exactly that, but for cloud applications. You launch virtual servers, called EC2 instances, and they all connect to the same EFS file system. Whenever a server saves a file, all other servers immediately see that file. This is incredibly useful when you are running websites, content management systems, analytics jobs, or containerized applications that need to share configuration files or user uploads.

What makes EFS special is that it automatically scales. You do not need to guess how much storage you will need next month. If your application suddenly becomes popular and users upload thousands of images, EFS expands its storage space without any manual intervention. When traffic slows down and files are deleted, EFS shrinks again. You are charged only for the storage you actually consume, measured in gigabytes per month. This is very different from traditional storage where you buy a fixed-size disk and either waste space or run out. EFS also keeps multiple copies of your data across different physical locations within an AWS region to protect against hardware failures. You can access EFS from many different virtual servers, even if those servers are in different parts of the country or world, as long as they are in the same AWS region. All of this is managed for you by AWS, so you do not have to worry about patching the storage system or replacing failed disks.

However, EFS is not the best choice for everything. It works well for file-level sharing, but not for very large databases that need block-level access. It can also be slower than local server disks for high-performance computing workloads that require extremely low latency. But for most shared file storage needs, especially those that grow and shrink unpredictably, EFS is a simple and cost-effective solution.

## Technical definition

Amazon Elastic File System (EFS) is a fully managed, cloud-native Network File System (NFS) that provides scalable, elastic shared file storage for use with AWS compute services, primarily Amazon EC2, but also AWS Lambda, ECS, EKS, and on-premises servers via AWS Direct Connect or VPN. It supports the NFSv4.1 and NFSv4.0 protocols, allowing standard Linux-based file operations with file locking, permissions, and access control lists (ACLs). EFS is designed to be highly durable and available by replicating data across multiple Availability Zones (AZs) within an AWS Region when using the Standard storage class. For cost-sensitive workloads, EFS offers a One Zone storage class, which stores data only within a single AZ, reducing costs but also durability.

EFS automatically scales its storage capacity from a few gigabytes to petabytes without requiring any pre-provisioning or manual intervention. The file system grows and shrinks as files are created and deleted, making it a truly elastic storage service. Performance can be configured in two modes: Bursting Throughput and Provisioned Throughput. Bursting Throughput is suitable for variable workloads where throughput scales with the amount of data stored, using a credit-based model similar to EBS gp2 volumes. Provisioned Throughput allows you to specify a fixed throughput level independent of storage size, useful for consistent, high-throughput applications. EFS supports two performance modes: General Purpose (default, low latency) and Max I/O (higher throughput and IOPS for parallel workloads).

From an implementation perspective, EFS file systems are created within a VPC using mount targets. Each mount target is associated with a subnet and has a private IP address within that subnet. EC2 instances must have the NFS client installed and mount the EFS file system using standard Linux mount commands, typically via the mount target DNS name. Security is managed through IAM policies for control plane operations and VPC security groups for network-level access. EFS also supports encryption at rest using AWS KMS and encryption in transit using TLS. For compliance and automation, EFS integrates with AWS Backup, Amazon CloudWatch (for monitoring metrics like burst credit balance and throughput), and AWS CloudTrail (for API auditing). IT professionals commonly use EFS in scenarios requiring shared access to content repositories, web serving assets, DevOps development environments, container storage, and big data analytics with tools like Apache Spark or Amazon EMR.

## Real-life example

Imagine you and three friends are working on a giant jigsaw puzzle together. You all sit around a large table. Instead of each person having their own small copy of the puzzle, you all work on the same big version. When one person places a piece, everyone else immediately sees the updated picture. If you run out of table space, the table magically grows larger so you can spread out more pieces. When you finish and clean up, the table shrinks back to its normal size. This is exactly how Amazon EFS works for applications.

In this analogy, the jigsaw puzzle pieces represent files. The table is the shared storage space. Your hands are the virtual servers (EC2 instances) that read and write files. As long as everyone is at the same table (in the same AWS region and VPC), every server can see exactly the same set of files. If a new server starts working, it can immediately access all the pieces already placed. The magic of the table growing and shrinking represents EFS automatically scaling its storage capacity. You never have to rush to buy a bigger table when the puzzle gets big, and you never waste empty space. This makes EFS very convenient for team projects where everyone needs to work from the same set of data.

Now consider a real-world IT scenario: a team of developers is building a website. They have a shared folder where they store images uploaded by users. Without EFS, each developer might have to manually copy new images to their own computer or a central server that might run out of disk space. With EFS, everyone’s code running on separate EC2 instances can read and write images to the same shared file system instantly. The website can scale up to millions of users without anyone worrying about storage limits, and the developers never need to manage disk partitions or resize file systems manually. That is the power of the EFS model.

## Why it matters

In practical IT infrastructure, shared storage is a common requirement. Many applications, especially those based on legacy architectures or content management systems, expect files to be available on a shared network drive. Amazon EFS fills this need in the cloud without the overhead of managing your own file server. For IT professionals, this means you can migrate existing on-premises applications that rely on NFS to the cloud with minimal changes. You do not have to rewrite the application to use object storage like S3, which has a different API and access pattern.

From a cost perspective, EFS’s pay-as-you-go model eliminates the need for upfront capacity planning. In traditional environments, you often over-provision storage to handle future growth, which wastes money. Or you under-provision and face emergency upgrades when disks fill up. EFS’s elasticity solves both problems. It also reduces operational overhead because AWS handles hardware failures, backups, and replication. This allows IT staff to focus on application development and user support rather than storage administration.

Another key reason EFS matters is its seamless integration with other AWS services. It works naturally with EC2, ECS (containers), EKS (Kubernetes), and Lambda. For example, a serverless application running on Lambda can access shared files in EFS, which was not previously possible without a file server. This opens up new use cases for data analytics, machine learning, and content management in serverless architectures. EFS is often used as a shared home directory for multiple users across a fleet of EC2 instances, providing a consistent environment for development and testing. In short, EFS provides the simplicity of a local file system with the scale, durability, and manageability of a cloud-native service, making it an essential tool for modern cloud architects and sysadmins.

## Why it matters in exams

Amazon EFS appears in multiple AWS certification exams, most notably the AWS Certified Solutions Architect Associate (SAA-C03), the AWS Certified Developer Associate (DVA-C02), and the AWS Certified SysOps Administrator Associate (SOA-C02). In these exams, EFS is tested as part of the “Design High-Performing and Scalable Storage” domain. Questions often require you to choose between EBS (block storage), S3 (object storage), and EFS (file storage) based on a scenario. EFS is the correct answer when you need shared, concurrent access to a file system from multiple EC2 instances, especially when the workload uses NFS and needs automatic scaling.

In Solutions Architect exams, you may encounter questions about migrating an on-premises application that uses NFS to AWS. The correct approach is often to use EFS to replicate the shared file storage without changing the application code. You may also see questions about performance optimization, such as choosing between Bursting and Provisioned Throughput, or between General Purpose and Max I/O performance modes. Another common exam topic is understanding the difference between EFS Standard (multi-AZ) and EFS One Zone. The Standard class is favored for production workloads requiring high availability, while One Zone is suitable for non-critical or development environments where cost is a primary concern.

In the Developer Associate exam, EFS is frequently tested in the context of containerized applications. You might be asked how to provide persistent shared storage for an ECS task or an EKS pod. The answer usually points to EFS as the storage back-end. Lambda functions with EFS are a relatively new feature that appears in exam questions. You may need to explain how to configure a Lambda function to mount an EFS file system so that multiple invocations can share state or access common data. In SysOps exams, you may encounter troubleshooting scenarios, such as why an EC2 instance cannot mount an EFS file system, which often relates to incorrect security group rules or missing mount targets in the appropriate subnets. Overall, EFS is a core AWS storage service that appears regularly across certification exams, so understanding its features, use cases, and limitations is essential for exam success.

## How it appears in exam questions

Exam questions about Amazon EFS typically fall into three categories: scenario-based architecture questions, configuration and troubleshooting questions, and comparison questions.

Scenario-based questions present a business requirement and ask which storage solution best fits. For example: “A company runs a web application on multiple EC2 instances behind an Application Load Balancer. Users upload profile pictures that must be accessible by all instances. Which storage solution should be used?” The correct answer is Amazon EFS because it provides shared file-level access. The distractor might be Amazon EBS (which cannot be mounted to multiple instances simultaneously) or S3 (which requires API calls and works differently than a file system). Another common scenario involves a legacy on-premises application that uses NFS and needs to be migrated to AWS with minimal changes. Here EFS is the natural choice.

Configuration questions test your understanding of how to set up EFS. For instance: “An administrator has created an EFS file system but an EC2 instance in the same VPC cannot mount it. What is the most likely cause?” The answer often involves missing mount targets in the instance’s subnet, or incorrect security group rules that block NFS traffic (port 2049). Another configuration question: “A user needs consistent high throughput for a video processing application regardless of the amount of data stored. Which throughput mode should be used?” The correct answer is Provisioned Throughput, and the explanation is that Bursting Throughput depends on the storage size.

Comparison questions ask you to differentiate EFS from similar services. For example: “Which of the following statements is true about Amazon EFS compared to Amazon EBS?” The correct statement would be that EFS can be mounted by multiple EC2 instances across different Availability Zones, while EBS can only be attached to a single instance in the same AZ. Also, EFS automatically scales storage, whereas EBS requires manual resizing. You might also see comparisons with Amazon S3, highlighting that EFS uses a standard file system interface (NFS), whereas S3 uses a REST API. Such questions require you to know the access patterns, performance characteristics, and use cases of each storage service.

## Example scenario

A small startup called “SnapShare” builds a photo-sharing website. They launch their application using three Amazon EC2 instances behind a load balancer. Users upload photos to the website, and those photos must be immediately viewable on any page, regardless of which EC2 instance handles the request. The developers initially tried storing photos on the local disk of each EC2 instance, but then a user’s photo would only be accessible if they were routed to that specific instance. This caused inconsistent behavior and frustrated users.

To solve this, the team decides to use Amazon EFS. They create an EFS file system in their VPC and configure mount targets in each public subnet where their EC2 instances run. They install the NFS client on all three instances and mount the EFS file system at /mnt/photos. They then modify their application code to save all uploaded photos directly to /mnt/photos. Now, when a user uploads a photo, it is stored in EFS, and any of the three instances can serve that photo. The load balancer can route a user to any instance, and the photo will always be found. The startup’s user base grows quickly, and they are relieved to find that EFS automatically expands its storage capacity without any manual resizing. They never receive a “disk full” error.

Later, the team wants to add a second EC2 instance in a different Availability Zone for disaster recovery. They simply mount the same EFS file system from the new instance. Because EFS replicates data across AZs (in Standard mode), even if one AZ goes down, the photos are safe and accessible from the other AZ. This scenario illustrates the core value of EFS: simple shared access with high availability and automatic scaling. It also shows how easy it is to add new servers without reconfiguring storage.

## Common mistakes

- **Mistake:** Assuming EFS can be accessed by multiple instances across different AWS regions by default.
  - Why it is wrong: EFS is a regional service. By default, an EFS file system is only accessible from within the same AWS region. Cross-region access requires additional setup like peering or VPN.
  - Fix: Always check that your EC2 instances are in the same region as the EFS file system, or configure VPC peering and routing for cross-region use.
- **Mistake:** Thinking EFS provides block-level storage like a local hard disk.
  - Why it is wrong: EFS is a file-level storage service using NFS. It does not present a raw block device. You cannot install an operating system on EFS or use it as a boot volume.
  - Fix: Use EBS for block storage, such as boot volumes or databases. Use EFS when multiple instances need to share files.
- **Mistake:** Believing EFS requires manual capacity planning or storage provisioning.
  - Why it is wrong: EFS is elastic and automatically grows and shrinks as you add or delete files. You do not need to specify a storage size or manage partitions.
  - Fix: Simply create the EFS file system and start using it. AWS handles capacity management automatically.
- **Mistake:** Confusing EFS with EBS in terms of Availability Zone constraints.
  - Why it is wrong: EBS volumes are tied to a single Availability Zone and can only be attached to instances in that same AZ. EFS, in Standard mode, can be mounted from instances across multiple AZs within the same region.
  - Fix: If you need shared storage across AZs, choose EFS. If you need a dedicated volume for one instance in one AZ, choose EBS.

## Exam trap

{"trap":"The exam might describe a scenario where a web application needs to store user uploaded images on a shared file system. One answer suggests using EBS with a specific snapshot schedule, another suggests using EFS, and a third suggests S3 with CloudFront.","why_learners_choose_it":"Learners may mistakenly select the EBS option because they are more familiar with block storage, or they think ‘shared’ means attaching the same EBS volume to multiple instances, which is not supported.","how_to_avoid_it":"Remember that EBS can only be attached to one EC2 instance at a time (except for certain multi-attach configurations that are very limited). For shared file access across multiple instances, EFS is the appropriate service. Also, S3 is object storage and works well for images but uses a different API and may require application changes. If the question emphasizes that the application expects a standard file system (NFS), EFS is the only correct choice."}

## Commonly confused with

- **Amazon EFS vs Amazon EBS:** Amazon EBS provides block-level storage volumes that can be attached to a single EC2 instance at a time. EBS volumes are tied to a specific Availability Zone. In contrast, EFS provides file-level storage that can be simultaneously accessed by multiple EC2 instances across different Availability Zones in the same region. EBS is better for databases and operating system disks, while EFS is best for shared file stores. (Example: You use EBS for your database server’s data drive (single instance access). You use EFS for a shared folder of documents that several web servers must read and write.)
- **Amazon EFS vs Amazon S3:** S3 is object storage accessed via a REST API over HTTP/HTTPS. It is not a file system and cannot be mounted as a standard drive without additional tools. EFS is a POSIX-compliant NFS file system that can be mounted directly by EC2 instances. S3 has unlimited storage and is optimized for large-scale data lakes, backups, and static web hosting. EFS is optimized for shared file access with low latency. (Example: You store millions of backup logs in S3 using an API. You store your team’s working documents in EFS so they can be edited by multiple servers using standard file commands.)
- **Amazon EFS vs Amazon FSx for Lustre:** FSx for Lustre is a high-performance file system designed for compute-intensive workloads like HPC, machine learning, and video rendering. It integrates with S3 and provides extremely high throughput and low latency, but it is more expensive and less elastic than EFS. EFS is meant for general-purpose shared file storage with automatic scaling, while FSx for Lustre is for specialized performance-critical tasks. (Example: You use FSx for Lustre for running a large-scale genomic analysis that requires massive parallel throughput. You use EFS for a shared development directory that a dozen developers access daily.)

## Step-by-step breakdown

1. **Step 1: Create an EFS File System** — In the AWS Management Console, you navigate to the EFS service and click ‘Create file system.’ You give it a name, choose the VPC where it will reside, and select the storage class (Standard for multi-AZ durability, One Zone for lower cost). You can also enable encryption at rest and choose a KMS key. This step defines the fundamental properties of your shared storage.
2. **Step 2: Configure Mount Targets** — For each subnet in your VPC where EC2 instances will need access, you create a mount target. A mount target is essentially a network interface with a private IP address in that subnet. Mount targets allow EC2 instances to connect to the EFS file system using the NFS protocol. Without mount targets in the correct subnets, instances cannot see the file system.
3. **Step 3: Set Up Security Groups** — You need to configure security groups for your EC2 instances and for the EFS mount targets. The EC2 security group must allow outbound NFS traffic (port 2049) to the mount target security group. The mount target security group must allow inbound NFS traffic from the EC2 security group. This ensures only authorized instances can access the file system.
4. **Step 4: Install NFS Client on EC2 Instances** — On each Linux EC2 instance, you install the NFS client software using the package manager (e.g., ‘sudo yum install nfs-utils’ on Amazon Linux). This software provides the tools needed to mount and interact with NFS file systems. For Windows instances, additional configuration is needed, but EFS is primarily designed for Linux workloads.
5. **Step 5: Mount the EFS File System** — Using the mount target DNS name (or IP address), you mount the EFS file system to a directory on the EC2 instance. For example: ‘sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-12345678.efs.us-east-1.amazonaws.com:/ /mnt/efs.’ This makes the shared storage available at /mnt/efs. You can also add an entry in /etc/fstab to mount automatically on reboot.
6. **Step 6: Set Permissions and Test Access** — Once mounted, you may need to set appropriate file permissions using chmod and chown so that the application user can read and write to the directory. Test by creating a file from one instance and verifying it appears on another instance. This confirms that the EFS file system is working correctly and that all instances share the same data.

## Practical mini-lesson

Amazon EFS is a powerful tool, but using it effectively in practice requires understanding some nuances. First, you need to choose the right performance mode when you create the file system. The General Purpose mode is best for most workloads because it provides low latency for file operations. The Max I/O mode is designed for highly parallel workloads like big data analytics, but it can have higher latency per operation. This choice is permanent once the file system is created, so it should be made carefully based on the expected workload.

Another practical consideration is throughput. EFS uses a credit-based system for Bursting Throughput. The more data you store, the more burst credits you accumulate, and the higher your baseline throughput becomes. For applications with spiky traffic, this works well. However, if you need a consistently high throughput regardless of storage size, you should use Provisioned Throughput. This incurs additional costs but guarantees performance. Monitoring burst credit balance in CloudWatch is crucial to avoid throttling.

Security is another area that requires attention. By default, EFS does not enforce IAM policies for file system access. You can use IAM to control which users or roles can create or delete EFS file systems, but file-level access is controlled by standard POSIX permissions and NFS export policies. For better security, you can enable IAM authentication for NFS clients, which requires the client to present an IAM credential. This is more advanced but adds a layer of access control. Always enable encryption at rest and use security groups to restrict network access to only the necessary subnets.

What can go wrong? The most common problem is mount failures. This typically happens when security groups are not configured correctly. If your EC2 instance cannot reach the mount target, the mount command will hang or fail. Another issue is hitting the throughput limit for the file system, causing slow performance. This is usually solved by switching to Provisioned Throughput. Also, be aware that EFS does not support hard links from Windows natively, and mixing NFSv4.1 with older NFS versions can cause compatibility issues. Always standardize your client configurations.

Finally, remember that EFS is a regional service. If you need to access the same file system from another region, you have to use AWS Global File System (which is still a newer feature) or use replication tools. For most use cases, keeping EFS within a single region is sufficient. Understanding these practical aspects will help you deploy EFS confidently in production and avoid common pitfalls that could lead to downtime or performance issues.

## Memory tip

EFS = Elastic File System. Remember the ‘E’ stands for ‘Elastic’ (auto-scales) and ‘F’ stands for ‘File’ (NFS shared file storage). Think ‘EFS for shared file storage across servers.’

## FAQ

**Can I use Amazon EFS with Windows EC2 instances?**

Yes, but it is not as straightforward as with Linux. Windows does not natively support NFSv4.1, but you can use third-party tools or enable Services for NFS in Windows Server. However, EFS is primarily designed for Linux-based workloads, and using it with Windows may require additional setup and may have performance limitations.

**How does Amazon EFS handle data durability?**

EFS Standard automatically replicates data across multiple Availability Zones within a region, providing 11 nines of durability (99.999999999%). EFS One Zone stores data only in a single AZ and offers lower durability. You can also enable backups using AWS Backup for additional protection.

**What is the difference between EFS Bursting and Provisioned Throughput?**

Bursting Throughput allows you to use burst credits to achieve high throughput for short periods, with a baseline throughput proportional to storage size. Provisioned Throughput lets you specify a fixed throughput independent of storage size, which is useful for workloads that need consistent performance. Provisioned Throughput incurs additional charges.

**Can I access an EFS file system from an on-premises data center?**

Yes, you can access EFS from on-premises servers by establishing a VPN connection or using AWS Direct Connect. The on-premises server must have the NFS client installed and be able to route to the EFS mount target IP addresses within the VPC over the VPN or Direct Connect link.

**Is there a limit on the number of EC2 instances that can mount the same EFS file system?**

There is no hard limit on the number of instances that can mount a single EFS file system. However, the aggregate throughput of the file system is shared among all connected clients. If you have many instances, you may need to use Provisioned Throughput or the Max I/O performance mode to avoid performance bottlenecks.

**Does EFS support S3 as a data source?**

EFS itself does not directly interface with S3. However, you can use AWS DataSync or a custom script to copy data between EFS and S3. FSx for Lustre can link to S3, but EFS is a standalone file system. If you need a file system that transparently tiers to S3, consider FSx for Lustre.

## Summary

Amazon EFS is a fully managed, elastic file storage service that provides shared file-level access to multiple EC2 instances using the NFS protocol. Its key strengths are automatic scaling, pay-as-you-go pricing, multi-AZ durability, and seamless integration with a wide range of AWS compute services. In the context of IT certifications, EFS is commonly tested in scenario-based questions that require selecting the right storage solution for shared file workloads, configuring mount targets and security groups, and understanding the differences between EFS, EBS, and S3.

From a practical standpoint, IT professionals should remember that EFS is ideal for applications that need a traditional shared network drive without the operational burden of managing a file server. It works best with Linux-based workloads and requires careful planning around performance modes and throughput settings to match application needs. Common mistakes include assuming EFS can be used across regions by default, confusing it with EBS for block storage, and neglecting security group configurations that lead to mount failures.

The exam takeaway is straightforward: when a question mentions multiple servers needing concurrent file access, especially with NFS, think EFS. Know the differences between Standard and One Zone storage classes, between Bursting and Provisioned Throughput, and between General Purpose and Max I/O performance modes. With this understanding, you will be well prepared to answer EFS questions accurately on AWS certification exams.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/amazon-efs