This chapter covers two of AWS’s managed file storage services: Amazon EFS (Elastic File System) and Amazon FSx (File Server for Windows and Lustre). Both provide shared file storage, but they are designed for very different use cases. In the SAA-C03 exam, you will encounter questions that ask you to choose between EFS and FSx based on performance requirements, protocol support, and cost. Approximately 5-8% of exam questions touch on file storage services, so understanding the nuances between EFS and FSx is critical for a high score.
Jump to a section
Think of EFS as a shared office filing cabinet that everyone in the company can access from their desks. You can add, remove, or read files at any time, and the cabinet automatically expands or shrinks as needed. Multiple people can read the same file simultaneously, and if two people try to edit at the same time, the last save wins. It’s perfect for general collaboration, but if you need to run heavy video editing or a database that demands lightning-fast access, the filing cabinet is too slow because it has to go through the network each time.
Now consider FSx as a high-performance workstation with a local SSD drive directly attached to a powerful computer. This workstation is optimized for specific tasks like rendering 3D animations or running a financial trading application. It provides extremely low latency and high throughput, but it’s more expensive and typically used by a smaller number of specialized users. You can also choose different types of workstations: one for Windows applications (FSx for Windows File Server) or one for high-performance computing (FSx for Lustre). The key difference is that the filing cabinet (EFS) is great for many users needing moderate performance, while the workstation (FSx) is for demanding workloads that need speed and consistency.
Overview of Amazon EFS
Amazon EFS is a fully managed, scalable, and elastic NFS file system for use with AWS Cloud services and on-premises resources. It is designed to provide shared file storage for thousands of EC2 instances concurrently, with automatic scaling of storage capacity and throughput based on demand. EFS supports the NFSv4.1 and NFSv4.0 protocols, making it a natural fit for Linux-based workloads.
How EFS Works
EFS creates a file system that can be mounted on multiple EC2 instances across different Availability Zones within the same AWS Region. The file system is accessed via a mount target, which is an NFS endpoint in each subnet. EFS automatically replicates data across multiple AZs within a region to provide high durability and availability (Standard storage class). For cost savings, you can use EFS One Zone, which stores data in a single AZ.
EFS scales storage capacity automatically as you add or remove files. There is no need to provision storage in advance. The file system can grow from a few gigabytes to petabytes without disruption. Performance scales with storage: General Purpose (GP) mode provides low latency for latency-sensitive applications, while Max I/O mode provides higher throughput for large-scale, throughput-intensive workloads.
Key Components and Defaults
Performance Modes: General Purpose (default) – sub-millisecond latency; Max I/O – higher throughput but higher latency.
Throughput Modes: Bursting (default) – throughput scales with storage size; Provisioned – specify throughput independent of storage.
Storage Classes: Standard (multi-AZ) and One Zone (single AZ). Lifecycle management can transition files between Standard and Infrequent Access (IA) storage classes to reduce costs.
Mount Targets: One per subnet, each with a DNS name. EC2 instances mount using NFSv4.x.
Security: Security groups control inbound NFS traffic, and IAM policies can restrict mount permissions.
Encryption: In-transit encryption via TLS (enabled with mount -o tls) and at-rest encryption using AWS KMS.
Default Limits: 1,000 file systems per region (soft limit), 125 mount targets per file system (hard limit).
How EFS Interacts with Other Services
EFS integrates with AWS Backup for automated backup, AWS DataSync for data transfer from on-premises, and AWS Transfer Family for SFTP access. It can be mounted on on-premises servers via AWS Direct Connect or VPN.
Overview of Amazon FSx
Amazon FSx is a fully managed service that offers three file system types: FSx for Windows File Server, FSx for Lustre, and FSx for NetApp ONTAP (and OpenZFS). The SAA-C03 exam focuses on the first two. FSx for Windows File Server provides native Windows file sharing using the SMB protocol, while FSx for Lustre is a high-performance parallel file system for compute-intensive workloads.
How FSx for Windows File Server Works
It provides fully managed Windows file servers with full support for the SMB protocol, Windows NTFS, Active Directory integration, and DFS namespaces. You can create a file system that is accessible from Windows EC2 instances, on-premises Windows servers, or any SMB client. It supports multi-AZ deployment for high availability and automatic failover.
How FSx for Lustre Works
FSx for Lustre is based on the Lustre file system, designed for high-performance computing (HPC), machine learning, and media processing. It provides sub-millisecond latencies, up to hundreds of gigabytes per second of throughput, and millions of IOPS. It can be linked to Amazon S3 for seamless data access: you can process data directly from S3 without moving it, and export results back to S3.
Key Components and Defaults for FSx
- FSx for Windows File Server: - Deployment Types: Single-AZ and Multi-AZ. - Storage Types: SSD (default) and HDD (for throughput-intensive workloads). - Throughput: Choose from a range (8 MB/s to 2 GB/s) based on file system size. - Protocol: SMB 2.0/3.0, NFS (via Windows NFS role). - Security: Active Directory authentication, encryption in transit and at rest. - FSx for Lustre: - Deployment Types: Persistent (for long-term storage) and Scratch (for temporary, high-burst workloads). - Storage Types: SSD (default) and HDD. - Throughput: 50 MB/s per TiB of storage for Persistent 50, 100 MB/s per TiB for Persistent 100, 200 MB/s per TiB for Persistent 200. - Data Repository Association: Link to S3 bucket for data import/export. - Protocol: POSIX-compliant, accessed via Lustre client.
How FSx Interacts with Other Services
FSx integrates with AWS Backup, AWS CloudTrail, and Amazon CloudWatch. FSx for Lustre can be integrated with Amazon S3, allowing data to be processed without copying. FSx for Windows File Server integrates with AWS Managed Microsoft AD.
Performance and Cost Considerations
EFS is priced per GB-month of storage used, with additional costs for provisioned throughput and IA access. FSx is priced based on storage capacity and provisioned throughput. For high-performance needs, FSx for Lustre can be significantly cheaper than EFS when considering the throughput required, but it is more expensive per GB for storage.
When to Use Which
EFS: When you need a simple, scalable NFS file system for Linux workloads with moderate performance requirements. Examples: web serving, content management, home directories.
FSx for Windows File Server: When you need native Windows file sharing with SMB, Active Directory integration, or Windows-based applications (e.g., SQL Server, IIS).
FSx for Lustre: When you need high-performance, low-latency file storage for HPC, ML, or media processing. Examples: genomics, financial modeling, video rendering.
Exam-Relevant Details
EFS is only for Linux (NFS). Windows instances cannot mount EFS natively.
FSx for Windows File Server supports both SMB and NFS (via Windows NFS role), but NFS performance is not as optimized.
FSx for Lustre uses a client that must be installed on EC2 instances; it is not a standard NFS mount.
EFS has two performance modes: General Purpose (default) and Max I/O. The exam expects you to know that Max I/O is for high throughput but has higher latency.
EFS has two throughput modes: Bursting and Provisioned. Bursting throughput scales with storage (e.g., 50 MB/s per TiB).
FSx for Lustre has two deployment types: Scratch (temporary, no replication) and Persistent (replicated within AZ).
FSx for Windows File Server supports Multi-AZ for high availability, with automatic failover to a standby in another AZ.
EFS Standard storage class is multi-AZ; One Zone is single AZ. FSx for Lustre Persistent is replicated within one AZ; Scratch is not replicated.
Both services support encryption at rest and in transit.
EFS lifecycle management can automatically move files to EFS IA after a configurable number of days (14, 30, 60, 90 days).
FSx for Lustre can be linked to S3 for data processing without copying.
Summary of Commands (for reference)
Mount EFS: mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <EFS-DNS>:/ /efs
Mount FSx for Windows File Server: Use standard SMB mount on Windows (net use or New-PSDrive).
Mount FSx for Lustre: mount -t lustre <FSx-DNS>@tcp:/<mountname> /mnt/lustre
Create EFS File System
In the AWS Management Console, navigate to EFS and click 'Create file system'. You must specify a VPC and optionally a performance mode (General Purpose or Max I/O) and throughput mode (Bursting or Provisioned). The file system will be created with a default security group that allows inbound NFS traffic (port 2049) from your EC2 instances. AWS automatically creates mount targets in each subnet of the VPC, but you can customize them later.
Configure Mount Targets
EFS creates a mount target in each subnet of the VPC you selected. Each mount target has a private IP address and a DNS name. You can associate a security group with each mount target to control inbound NFS traffic. For multi-AZ access, ensure mount targets exist in each AZ where your EC2 instances reside. The mount target must be in the same VPC as the EC2 instance, or you can use VPC peering or Transit Gateway for cross-VPC access.
Mount EFS on EC2 Linux Instance
SSH into your EC2 Linux instance. Install the NFS client if not present (e.g., `sudo yum install -y nfs-utils`). Create a mount point directory (e.g., `/mnt/efs`). Use the `mount` command with the EFS DNS name. For example: `sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-12345678.efs.us-east-1.amazonaws.com:/ /mnt/efs`. The options `hard` and `timeo=600` ensure NFS retries if the server is unreachable. To make the mount persistent, add an entry to `/etc/fstab`.
Create FSx for Windows File System
In the FSx console, select 'Create file system' and choose 'Windows File Server'. You must specify storage capacity (minimum 32 GB), throughput capacity (8 MB/s to 2 GB/s), and VPC/subnet. For high availability, select Multi-AZ, which creates a primary file server in one AZ and a standby in another. You must also choose an Active Directory (either AWS Managed Microsoft AD or self-managed) for authentication. The file system will be assigned a DNS name.
Mount FSx for Windows on Windows EC2
RDP into your Windows EC2 instance that is joined to the same Active Directory domain. Open File Explorer, right-click 'This PC', and select 'Map network drive'. Enter the FSx DNS name in the format `\\fs-12345678.region.amazonaws.com\share`. Alternatively, use the command line: `net use Z: \\fs-12345678.region.amazonaws.com\share /persistent:yes`. The instance must have network connectivity to the FSx file system (same VPC, security group allowing SMB port 445).
Create FSx for Lustre File System
In the FSx console, choose 'Lustre'. Specify storage capacity (minimum 1.2 TiB for SSD, 2.4 TiB for HDD), deployment type (Scratch or Persistent), and throughput tier (50, 100, or 200 MB/s per TiB for Persistent). Optionally, link an S3 bucket for data import. The file system will be created with a DNS name and mount name. Note that Scratch is not replicated and is for temporary data; Persistent replicates within one AZ.
Mount FSx for Lustre on EC2 Linux
SSH into your EC2 Linux instance. Install the Lustre client (`sudo yum install -y lustre-client`). Create a mount point (e.g., `/mnt/lustre`). Mount using the command: `sudo mount -t lustre <FSx-DNS>@tcp:/<mountname> /mnt/lustre`. The Lustre client must be installed on a supported Amazon Linux 2 or Red Hat Enterprise Linux (RHEL) 7/8 instance. After mounting, you can read/write files as a standard POSIX file system.
Enterprise Scenario 1: Media Rendering Studio
A media production company needs a shared storage solution for a render farm of 200 Linux-based EC2 instances. They render 4K video frames, each around 10-50 MB. The workload is highly parallel and requires high throughput (5 GB/s) and low latency (sub-millisecond). They considered EFS Max I/O but found that latency spikes caused frame drops. They chose FSx for Lustre Persistent 200 with SSD storage. The file system is linked to an S3 bucket for input footage and output renders. They configured the Lustre file system with 10 TiB of storage, providing 2 GB/s of throughput (200 MB/s per TiB). The render farm mounts the file system and reads/writes frames directly. The cost is higher than EFS, but the performance is predictable and meets the SLA. Misconfiguration: They initially used Scratch deployment, but a single AZ failure caused data loss. They switched to Persistent with automatic replication within the AZ.
Enterprise Scenario 2: Corporate File Shares
A large enterprise with 5,000 employees uses a mix of Windows and Linux servers. They need a central file share for home directories, project files, and shared documents. They require Active Directory integration for access control, SMB protocol for Windows clients, and the ability to mount on Linux via NFS. They chose FSx for Windows File Server Multi-AZ. They provisioned a 1 TB file system with 100 MB/s throughput. The file system is joined to AWS Managed Microsoft AD. Windows EC2 instances mount via SMB, and Linux instances mount via NFS (using the Windows NFS role). They use AWS Backup for daily snapshots. Misconfiguration: They initially used Single-AZ, but an AZ outage caused file server unavailability. They switched to Multi-AZ with automatic failover.
Enterprise Scenario 3: Web Application Shared Storage
A SaaS company runs a web application on 50 Linux EC2 instances behind an Application Load Balancer. They need a shared file system for user-uploaded content and configuration files. The workload is variable, with peaks during business hours. They chose EFS with General Purpose mode and Bursting throughput. They use lifecycle management to move older files to EFS IA after 30 days to reduce costs. The file system is mounted on all EC2 instances. They use security groups to restrict NFS access to only the EC2 instances. Misconfiguration: They initially used Max I/O mode, which caused higher latency for small file operations. They switched to General Purpose for better latency.
What SAA-C03 Tests
This topic falls under Objective 3.5: 'Select appropriate storage options based on performance requirements.' The exam will present scenarios requiring you to choose between EFS, FSx for Windows, and FSx for Lustre. Key differentiators: protocol (NFS vs SMB), performance (throughput and latency), integration (Active Directory, S3), and cost.
Common Wrong Answers
Choosing EFS for Windows workloads: Candidates see 'shared file system' and pick EFS, forgetting EFS only supports NFS (Linux). Correct: FSx for Windows File Server for SMB.
Choosing FSx for Lustre for general-purpose file sharing: Lustre is for HPC, not for typical file storage. It requires Lustre client and is not NFS-compatible. Correct: EFS for Linux, FSx for Windows for Windows.
Selecting EFS Max I/O for low latency: Max I/O offers higher throughput but higher latency than General Purpose. Candidates often choose Max I/O thinking it's better for all performance. Correct: General Purpose for low latency.
Confusing EFS One Zone with FSx for Lustre Scratch: Both are single-AZ, but EFS One Zone is for cost savings, while Scratch is for temporary HPC data. The exam may test that Scratch is not replicated.
Specific Numbers and Terms
EFS Bursting throughput: 50 MB/s per TiB of storage.
EFS Provisioned throughput: up to 1 GB/s per file system.
FSx for Lustre Persistent throughput: 50, 100, or 200 MB/s per TiB.
FSx for Windows File Server minimum storage: 32 GB.
FSx for Lustre minimum storage: 1.2 TiB (SSD) or 2.4 TiB (HDD).
EFS lifecycle transition days: 14, 30, 60, 90.
Edge Cases
Cross-region access: EFS and FSx are region-specific. To access from another region, use DataSync or replicate.
On-premises access: Both can be accessed via Direct Connect or VPN, but FSx for Windows requires Active Directory trust.
Encryption: Both support encryption at rest and in transit. EFS in-transit encryption requires TLS mount option.
Eliminating Wrong Answers
If the scenario mentions 'SMB' or 'Windows', eliminate EFS.
If the scenario mentions 'HPC', 'high throughput', 'Lustre', eliminate EFS and FSx for Windows.
If the scenario mentions 'Linux', 'NFS', 'shared file system', choose EFS unless performance demands are extreme.
If cost is a concern and performance is moderate, EFS with lifecycle management is cost-effective.
EFS is NFS-only for Linux; FSx for Windows File Server is SMB for Windows; FSx for Lustre is for HPC with Lustre protocol.
EFS General Purpose mode provides sub-millisecond latency; Max I/O provides higher throughput but higher latency.
EFS Bursting throughput scales at 50 MB/s per TiB of storage; Provisioned throughput can be set independently.
FSx for Lustre Persistent deployment replicates data within a single AZ; Scratch has no replication and is for temporary data.
FSx for Windows File Server Multi-AZ provides automatic failover to a standby in another AZ for high availability.
EFS lifecycle management can move files to Infrequent Access after 14, 30, 60, or 90 days.
FSx for Lustre can be linked to an S3 bucket for seamless data processing without copying.
EFS and FSx both support encryption at rest (KMS) and in transit (TLS for EFS, SMB encryption for FSx Windows).
On-premises access to both services requires Direct Connect or VPN; FSx for Windows requires AD trust.
Cost: EFS is pay-per-use (storage + data access); FSx is provisioned capacity (storage + throughput).
These come up on the exam all the time. Here's how to tell them apart.
Amazon EFS
Protocol: NFSv4.1/4.0 (Linux only).
Performance: General Purpose (sub-ms latency) or Max I/O (higher throughput, higher latency).
Throughput modes: Bursting (50 MB/s per TiB) or Provisioned.
Storage classes: Standard (multi-AZ) and One Zone (single AZ).
Pricing: Per GB-month of storage, plus data access costs for IA.
Amazon FSx for Windows File Server
Protocol: SMB 2.0/3.0 (Windows native), also NFS via Windows NFS role.
Performance: Provisioned throughput from 8 MB/s to 2 GB/s.
Deployment: Single-AZ or Multi-AZ with automatic failover.
Storage types: SSD (default) or HDD.
Pricing: Per GB-month of provisioned storage plus per MB/s of throughput.
Amazon EFS
Protocol: NFSv4.x (Linux).
Use case: General purpose file sharing, web serving, content management.
Performance: Up to 10 GB/s throughput, sub-ms latency (GP).
Replication: Standard (multi-AZ) or One Zone.
Integration: AWS Backup, DataSync, Transfer Family.
Amazon FSx for Lustre
Protocol: Lustre (POSIX-compliant, requires Lustre client).
Use case: HPC, ML, media processing, financial modeling.
Performance: Up to hundreds of GB/s throughput, sub-ms latency.
Replication: Persistent (replicated within AZ) or Scratch (no replication).
Integration: Linked to S3 for data import/export.
Mistake
EFS can be used with Windows EC2 instances.
Correct
EFS only supports NFSv4.x, which is not natively supported by Windows. Windows Server can mount NFS via the NFS role, but performance is poor and not recommended. For Windows workloads, use FSx for Windows File Server.
Mistake
FSx for Lustre is an NFS file system.
Correct
FSx for Lustre uses the Lustre protocol, which is POSIX-compliant but not NFS. It requires a Lustre client on the EC2 instance. It is not compatible with standard NFS mounts.
Mistake
EFS Max I/O mode provides the lowest latency.
Correct
Max I/O mode is designed for high throughput but introduces higher latency compared to General Purpose mode. General Purpose mode provides sub-millisecond latency for most workloads.
Mistake
FSx for Windows File Server supports only SMB protocol.
Correct
FSx for Windows File Server supports both SMB and NFS (via the Windows NFS role). However, NFS performance is not as optimized as SMB. The primary use case is SMB.
Mistake
EFS One Zone and FSx for Lustre Scratch are the same.
Correct
Both are single-AZ, but EFS One Zone provides the same durability as Standard (99.999999999%) within that AZ, while Lustre Scratch has no replication and data is lost if the file system fails. Scratch is for temporary, high-burst workloads.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Technically yes, if you install the NFS client on Windows Server, but it is not recommended due to poor performance and limited support. The SAA-C03 exam expects you to know that EFS is designed for Linux. For Windows, use FSx for Windows File Server.
General Purpose is the default mode and provides sub-millisecond latency for most operations, suitable for general workloads. Max I/O is designed for high throughput (up to 10 GB/s) but introduces higher latency. Use Max I/O when you have large-scale, parallel workloads that can tolerate higher latency.
No, FSx for Lustre uses the Lustre protocol, which is POSIX-compliant but not NFS. You must install the Lustre client on your EC2 instance to mount it. It is not compatible with standard NFS mounts.
The minimum storage capacity is 1.2 TiB for SSD-based file systems and 2.4 TiB for HDD-based. This is a hard limit. For EFS, there is no minimum; you pay only for what you use.
You can create lifecycle policies that automatically move files from EFS Standard to EFS Infrequent Access (IA) after a specified number of days (14, 30, 60, or 90). IA storage costs less per GB but has a per-GB data access charge. This helps reduce costs for infrequently accessed files.
Yes, both can be accessed from on-premises via AWS Direct Connect or a VPN connection. For EFS, you mount using NFS. For FSx for Windows, you need to join the on-premises Active Directory to the AWS AD (or set up trust). For FSx for Lustre, on-premises access is possible but requires Lustre client and low-latency connectivity.
Single-AZ deploys one file server in one Availability Zone. Multi-AZ deploys a primary file server in one AZ and a standby in another AZ. If the primary fails, the standby takes over automatically, providing higher availability. Multi-AZ is recommended for production workloads.
You've just covered EFS vs FSx for Storage — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?