This chapter covers Amazon FSx for Windows File Server, a fully managed native Windows file system that provides shared storage for Windows-based workloads in AWS. For the SAA-C03 exam, understanding FSx for Windows File Server is critical because it is the only fully managed, SMB-based file storage service that integrates natively with Windows environments, Active Directory, and DFS. Approximately 5-10% of exam questions touch on AWS file storage services, with FSx for Windows File Server appearing in scenarios requiring shared Windows file storage, user home directories, or lift-and-shift migrations of on-premises Windows file servers.
Jump to a section
Imagine a large office building where every floor has its own shared filing cabinet. Employees from any floor can access any cabinet, but performance is slow because everyone competes for the same drawers, and the building's network is congested with file requests. Now, the company decides to install a dedicated filing cabinet for the executive floor. This cabinet has its own clerk, who only serves that floor. The clerk knows exactly where every file is, can prioritize requests, and works with a separate, faster elevator that only connects the executive floor to the cabinet. Other floors still use the shared cabinets, but the executives get blazing fast access. This is FSx for Windows File Server: a fully managed, dedicated file server for Windows workloads in AWS. It provides a private, high-performance file system with its own network interface, consistent low-latency access, and integration with Windows-native features like Active Directory and SMB protocol. Just as the dedicated clerk eliminates contention and provides specialized service, FSx eliminates the ‘noisy neighbor’ problem of shared storage and delivers consistent performance for Windows applications.
What is Amazon FSx for Windows File Server?
Amazon FSx for Windows File Server is a fully managed, native Windows file server service that provides shared file storage accessible via the Server Message Block (SMB) protocol. It is built on Windows Server, meaning it supports all Windows-native features such as Active Directory (AD) integration, Windows Access Control Lists (ACLs), Distributed File System (DFS) namespaces and replication, and Volume Shadow Copy Service (VSS) for snapshots. Unlike Amazon EFS, which uses NFS and is Linux-focused, or Amazon S3, which is object storage, FSx for Windows File Server is purpose-built for Windows workloads.
Why It Exists
Many enterprises run Windows-based applications—such as SQL Server, IIS web servers, or custom .NET applications—that require shared file storage with SMB protocol support, AD authentication, and Windows ACLs. Before FSx, customers had to run their own Windows file servers on EC2 instances, which meant managing patching, backups, high availability, and performance tuning. FSx eliminates this operational overhead by providing a managed service that automatically handles hardware provisioning, patching, and replication for high availability.
How It Works Internally
FSx for Windows File Server operates as a fully managed Windows Server environment. When you create a file system, AWS provisions one or more Windows Server instances (depending on deployment type) with attached EBS volumes for storage. The file system is presented to clients via an SMB share. The service supports two deployment types: Single-AZ and Multi-AZ.
Single-AZ: One file server in a single Availability Zone. Data is stored on EBS volumes with automatic replication within the AZ (like EBS).
Multi-AZ: Two file servers in two different AZs (primary and standby). Data is synchronously replicated between them. The primary handles all read/write requests; the standby takes over in case of failure. Failover is automatic and transparent to clients using SMB 3.0 with persistent handles.
Key Components, Values, Defaults, and Timers
Storage Capacity: 20 GiB minimum, up to 65,536 GiB (64 TB). You can increase storage online without downtime.
Throughput: You can choose a throughput capacity from 8 MB/s to 2 GB/s. Throughput is independent of storage size. You can increase throughput online.
IOPS: Baseline IOPS are 3 IOPS per GiB. Burst IOPS up to 3,000 for SSDs. For HDDs, baseline is 1 IOPS per TiB, burst up to 3,000.
Protocol: SMB 2.0, 2.1, 3.0, 3.1.1.
Supported Clients: Windows Server 2008+, Windows 8+, Linux with SMB client (e.g., cifs-utils).
Access: Via Active Directory (AWS Managed Microsoft AD or self-managed AD). Supports both on-premises AD and AWS AD.
Data Deduplication: Can be enabled to reduce storage footprint.
Shadow Copies (VSS): Enable to allow users to restore previous versions of files.
Backups: Automated daily backups with retention up to 35 days; manual backups (snapshots) retained indefinitely.
Encryption: At rest using AWS KMS; in transit using SMB encryption.
DFS Namespaces: FSx can be joined to a DFS namespace for unified access across multiple file systems.
DFS Replication: FSx supports DFS Replication (DFSR) for replicating data to other file servers (including on-premises).
Configuration and Verification Commands
To connect a Windows EC2 instance to an FSx file system, you can map a network drive:
net use Z: \\fs-1234567890abcdef0.region.amazonaws.com\shareOr use PowerShell:
New-PSDrive -Name Z -PSProvider FileSystem -Root \\fs-1234567890abcdef0.region.amazonaws.com\share -PersistFor Linux clients, mount using cifs-utils:
mount -t cifs //fs-1234567890abcdef0.region.amazonaws.com/share /mnt/fsx -o vers=3.0,username=user,password=pass,domain=example.comInteraction with Related Technologies
AWS Directory Service: FSx integrates with AWS Managed Microsoft AD to provide centralized authentication. You can also join an FSx file system to your on-premises AD via AD Connector or a two-way trust.
AWS Backup: FSx is integrated with AWS Backup for centralized backup management.
Amazon CloudWatch: Provides metrics like storage utilization, throughput, and IOPS.
AWS KMS: For encryption key management.
Amazon S3: FSx can be used as a cache for on-premises file servers via AWS Storage Gateway’s File Gateway, but that is a different service.
Amazon EFS: EFS is NFS-based, for Linux. FSx for Windows is SMB-based, for Windows.
Performance and Scaling
FSx for Windows File Server provides consistent performance because it uses dedicated file server instances. In Multi-AZ, writes are synchronously replicated, which adds latency but improves durability. Read performance benefits from caching on the file server. You can increase storage and throughput online without downtime, but you cannot decrease them. The service automatically scales the underlying infrastructure as needed, but you control the throughput capacity.
Monitoring and Logging
You can monitor FSx with CloudWatch metrics (e.g., FileServer.StorageCapacity, FileServer.UsedStorageBytes, DataReadBytes, DataWriteBytes). You can also enable Windows Event Log streaming to CloudWatch Logs for auditing file access and administrative actions.
Cost Model
You pay for the provisioned storage (per GB-month) and the provisioned throughput (per MB/s-month). Additionally, backups incur storage costs. Multi-AZ costs more due to synchronous replication and a standby instance.
Exam-Relevant Details
Multi-AZ failover: Uses SMB 3.0 persistent handles. Clients reconnect transparently within about 30 seconds.
Storage limits: 64 TB maximum. If you need more, you can create multiple file systems and use DFS Namespaces to present a single namespace.
Throughput: You cannot choose throughput less than 8 MB/s. For high-performance workloads, choose higher throughput.
Data deduplication: Reduces storage consumption by up to 60% for typical file server data. Can be enabled on the file system.
Shadow Copies: Enabled per share. Users can restore previous versions from Windows Explorer.
SMB encryption: Enforces encryption in transit. Can be required on the file system.
Integration with Amazon WorkSpaces: FSx can be used for user home directories in WorkSpaces.
Common Use Cases
Lift-and-shift migration: Replace on-premises Windows file servers with FSx.
User home directories: Use FSx with AD for roaming profiles and home drives.
Application storage: For applications that require SMB shares (e.g., SQL Server, IIS).
Media workflows: Transcoded files stored on FSx for Windows.
Limitations
Not NFS-native. To use NFS, consider EFS or FSx for Lustre.
Single-AZ file systems are not highly available; Multi-AZ required for production.
Maximum file system size 64 TB; for larger, use multiple file systems.
Throughput capacity cannot be decreased.
Architecture Considerations
For high availability, deploy Multi-AZ. Ensure clients use SMB 3.0+ for transparent failover. For security, restrict access using security groups, enable encryption in transit, and integrate with AD for authentication. For performance, monitor CloudWatch metrics and increase throughput if needed. Use data deduplication to save costs.
Summary of Exam Objectives
This section covers SAA-C03 objective 3.5: Determine high-performance and/or high-availability storage solutions. FSx for Windows File Server is a key service for Windows-based shared storage with high availability (Multi-AZ) and consistent performance.
Create an FSx File System
In the AWS Management Console, navigate to FSx and choose 'Create file system' then 'Amazon FSx for Windows File Server'. Provide a name, choose deployment type (Single-AZ or Multi-AZ), storage capacity (minimum 20 GiB), throughput capacity (8 MB/s to 2 GB/s), and storage type (SSD or HDD). Optionally, enable data deduplication and daily automatic backups. You must specify the VPC, subnet(s), and security groups. For Multi-AZ, you select a preferred subnet for the primary and a standby subnet in another AZ. The file system is provisioned with a DNS name like fs-1234567890abcdef0.region.amazonaws.com.
Integrate with Active Directory
During creation, you can join the file system to an AWS Managed Microsoft AD or a self-managed AD. If using self-managed AD, you must establish a two-way trust or use AD Connector. The file system will automatically join the domain and create a computer object. You can also specify a service account for the file server. Once joined, clients authenticated in the AD can access the file share using their domain credentials. Access is controlled via Windows ACLs.
Configure Security Groups
Create a security group for the FSx file system that allows inbound SMB traffic (TCP 445) from clients (e.g., EC2 instances, on-premises via VPN/Direct Connect). Also, if using AD, ensure the file system can communicate with your AD controllers (typically TCP 389, 636, 3268-3269). For Multi-AZ, ensure the security group allows traffic between the primary and standby file servers for replication (AWS-managed, but you need to allow VPC traffic).
Mount the File Share on Clients
On a Windows client, open File Explorer, right-click 'This PC' and choose 'Map network drive'. Enter the FSx file system's DNS name followed by the share name (e.g., \\fs-1234567890abcdef0.region.amazonaws.com\share). Use domain credentials. For multiple clients, you can use Group Policy to map drives automatically. On Linux, use mount with cifs-utils, specifying the domain and credentials. For EC2 instances, ensure the instance's security group allows outbound SMB to the FSx security group.
Enable and Manage Shadow Copies
Shadow Copies (VSS) allow users to restore previous versions of files. To enable, go to the FSx console, select the file system, and under 'Shares', enable Shadow Copies for the specific share. You can set a schedule (e.g., twice daily). Users can then right-click a file in Windows Explorer, select 'Properties', and go to the 'Previous Versions' tab to restore. Shadow Copies consume storage space; monitor usage.
Monitor Performance and Scale
Use CloudWatch to monitor metrics like FileServer.UsedStorageBytes, DataReadBytes, and DataWriteBytes. If throughput is insufficient, you can increase the throughput capacity online (no downtime). Similarly, you can increase storage capacity online. However, you cannot decrease either. For Multi-AZ, failover events are logged. Set CloudWatch alarms for high utilization. Also, enable Windows Event Log streaming to CloudWatch Logs for auditing.
Scenario 1: Lift-and-Shift Migration of On-Premises Windows File Servers
A large enterprise with 500 employees uses an on-premises Windows file server for user home directories and departmental shares. The server is running out of capacity and is due for hardware refresh. The company is migrating to AWS and wants to eliminate the file server management overhead. They deploy FSx for Windows File Server in a Multi-AZ configuration for high availability. They set up a VPN connection between their on-premises network and AWS VPC. Using AWS DataSync, they migrate 10 TB of data to FSx. They then join the FSx file system to their on-premises Active Directory via AD Connector. Users access their home drives using the same drive letter mapping via Group Policy. The result: no changes for users, improved performance, and automatic patching and backups. Common issues include: initial sync speed limited by VPN bandwidth; scheduling DataSync during off-peak hours solves this. Also, ensure SMB signing and encryption are configured to avoid performance overhead.
Scenario 2: High-Performance SQL Server Storage
A company runs SQL Server on EC2 instances for a critical OLTP application. They need shared storage for SQL Server databases with SMB protocol support for Always On Availability Groups. They deploy FSx for Windows File Server with SSD storage and high throughput (1 GB/s). They configure the file system in the same VPC and subnet as the SQL Server EC2 instances to minimize latency. They enable SMB encryption for security. The SQL Server instances use the FSx share as the data directory for the databases. The consistent low-latency performance of FSx meets their IOPS requirements. They use automated backups for point-in-time recovery. Pitfalls: not monitoring CloudWatch metrics for throughput; if throughput is maxed out, performance degrades. They had to increase throughput from 500 MB/s to 1 GB/s after initial deployment.
Scenario 3: Media and Entertainment Workflow
A media production company uses Windows-based editing workstations. Editors need to access shared video files stored on a central file server. They deploy FSx for Windows File Server with HDD storage for cost-effective performance, as video files are large and sequential. They enable data deduplication to save storage (though video files may not deduplicate well). They use Multi-AZ for availability. Editors mount the share on their workstations. They also enable Shadow Copies so editors can revert to previous versions of project files. Challenges: throughput was initially insufficient for multiple editors streaming 4K video; they increased throughput to 2 GB/s. Also, they had to ensure the network path had enough bandwidth (e.g., using Direct Connect). They learned that HDD storage has lower IOPS, but for sequential reads, it was acceptable.
Exactly What SAA-C03 Tests on This Topic
The exam objective 3.5 (Determine high-performance and/or high-availability storage solutions) includes FSx for Windows File Server. Questions typically require you to choose the correct storage service for a Windows-based workload. Key differentiators: SMB protocol, Active Directory integration, Windows ACLs, and Multi-AZ high availability. The exam may present scenarios with on-premises AD, requiring you to select FSx with AD integration. Also, questions about migration: if a company wants to move their Windows file server to AWS without re-architecting, FSx is the answer.
Common Wrong Answers and Why Candidates Choose Them
Choosing Amazon EFS: Candidates see 'shared file storage' and pick EFS. But EFS uses NFS and does not support SMB or Windows ACLs. FSx for Windows is the correct choice for Windows workloads.
Choosing Amazon S3: S3 is object storage, not a file system. Candidates may confuse FSx with S3. However, S3 does not natively support SMB or Windows ACLs (though you can use S3 File Gateway, but that adds complexity).
Choosing EC2 with self-managed file server: This is the legacy approach. The exam wants you to recognize that FSx eliminates management overhead. If the question asks for a fully managed solution, FSx is correct.
Choosing FSx for Lustre: Lustre is for high-performance computing (HPC), not Windows file sharing. Candidates may pick it because of the 'FSx' name.
Specific Numbers, Values, and Terms That Appear Verbatim
64 TB: Maximum storage capacity per file system.
20 GiB: Minimum storage.
8 MB/s to 2 GB/s: Throughput range.
SMB 3.0: Required for transparent failover in Multi-AZ.
Multi-AZ: High availability feature.
Shadow Copies: VSS-based.
Data deduplication: Reduces storage.
DFS Namespaces: For unified namespace across multiple file systems.
Edge Cases and Exceptions
Cross-region access: FSx does not support cross-region replication natively. You can use DFS Replication to replicate to another FSx in another region, but that is manual.
On-premises access: Requires VPN or Direct Connect. The file system must be joined to the on-premises AD via AD Connector or trust.
Linux clients: Supported via SMB client (cifs-utils). However, Windows ACLs may not be fully supported on Linux.
Data deduplication: Not available for HDD storage.
Automatic backups: Retention up to 35 days; manual backups (snapshots) can be retained indefinitely.
How to Eliminate Wrong Answers Using the Underlying Mechanism
Read the scenario carefully. If the workload is Windows-based and requires SMB, eliminate EFS (NFS) and S3 (object). If the requirement is fully managed, eliminate EC2. If high availability is needed, ensure Multi-AZ is selected. If the scenario mentions Active Directory, FSx with AD integration is key. If the scenario involves HPC or Linux, consider FSx for Lustre or EFS.
FSx for Windows File Server is the only fully managed SMB-based file storage in AWS, designed for Windows workloads.
Minimum storage: 20 GiB; maximum: 64 TB; throughput: 8 MB/s to 2 GB/s.
Multi-AZ deployment provides automatic failover using SMB 3.0 persistent handles.
Supports Active Directory integration (AWS Managed AD or on-premises via AD Connector/trust).
Features include data deduplication, Shadow Copies (VSS), encryption at rest and in transit, and automated backups.
Cannot decrease storage or throughput after creation; can only increase online.
Use DFS Namespaces to combine multiple FSx file systems into a single namespace.
Exam tip: If scenario involves Windows, SMB, AD, or lift-and-shift of Windows file server, choose FSx for Windows File Server.
These come up on the exam all the time. Here's how to tell them apart.
FSx for Windows File Server
SMB protocol (Windows-native)
Integrates with Active Directory
Supports Windows ACLs
Multi-AZ high availability option
Up to 64 TB capacity
Amazon EFS
NFS protocol (Linux-native)
Integrates with IAM and POSIX permissions
No Windows ACLs
Regional (Multi-AZ) by design
Unlimited storage (petabyte-scale)
Mistake
FSx for Windows File Server supports NFS protocol.
Correct
FSx for Windows File Server only supports SMB protocol (SMB 2.0-3.1.1). For NFS, use Amazon EFS or FSx for Lustre.
Mistake
You can decrease storage capacity after creation.
Correct
You cannot decrease storage capacity. You can only increase it online. Plan capacity carefully.
Mistake
Single-AZ deployment provides high availability.
Correct
Single-AZ does not provide high availability. If the AZ fails, the file system is unavailable. For HA, use Multi-AZ.
Mistake
FSx for Windows File Server requires a separate AD connector or trust for AWS Managed AD.
Correct
If using AWS Managed Microsoft AD, FSx can join directly without additional connectors. For on-premises AD, you need AD Connector or a two-way trust.
Mistake
You can mount an FSx file system using NFS on Linux.
Correct
Linux clients must use the SMB protocol (cifs-utils). NFS is not supported.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, Linux clients can mount FSx shares using the SMB protocol via cifs-utils. However, Windows ACLs may not be fully supported. Use mount command with vers=3.0 and appropriate credentials.
Multi-AZ uses a primary and standby file server in different AZs. Data is synchronously replicated. On failure, the standby takes over. Clients using SMB 3.0 with persistent handles reconnect transparently within about 30 seconds.
The maximum storage capacity is 64 TB per file system. If you need more, create multiple file systems and use DFS Namespaces to present a unified namespace.
Yes, you can join FSx to your on-premises AD using AD Connector or by establishing a two-way trust between AWS Managed Microsoft AD and your on-premises AD.
Yes, you can enable SMB encryption on the file system, which encrypts data in transit. This is recommended for security.
You can enable automated daily backups with retention up to 35 days. You can also create manual backups (snapshots) that are retained indefinitely. Backups are incremental and stored in S3.
Yes, FSx supports SMB 3.0, which is compatible with SQL Server. It can be used for data files, log files, and backup files. Ensure sufficient throughput and low latency.
You've just covered FSx for Windows File Server — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?