SOA-C02Chapter 61 of 104Objective 3.3

FSx for Windows File Server

This chapter covers Amazon FSx for Windows File Server, a fully managed file storage service that provides native Windows file shares accessible via the SMB protocol. For the SOA-C02 exam, FSx for Windows File Server appears in roughly 5-8% of questions, primarily in the Deployment domain (Objective 3.3). You must understand its architecture, how it integrates with Active Directory, its performance modes, backup options, and how it differs from other storage services like EFS and S3. This chapter provides the depth needed to answer exam questions confidently.

25 min read
Intermediate
Updated May 31, 2026

FSx Like a Managed Windows File Server in AWS

Imagine a large enterprise with a dedicated Windows file server in its own data center. The server has its own storage (direct-attached or SAN), runs Active Directory for authentication, and uses SMB protocol to share files. Now, instead of buying, racking, and maintaining that server, you contract a managed service that gives you a fully functional Windows file server in the cloud. The service provider (AWS) handles the underlying hardware, storage provisioning, patching, and backups. You just specify the storage capacity, throughput, and security settings, and the server appears as a network drive to your users. FSx for Windows File Server is exactly that: a native, fully managed Windows file server that supports SMB protocol, integrates with your existing Active Directory, and provides features like shadow copies, quotas, and encryption. It's like having a high-end Windows file server without the operational overhead.

How It Actually Works

What is Amazon FSx for Windows File Server?

Amazon FSx for Windows File Server is a fully managed, native Microsoft Windows file server service that provides shared file storage accessible over the Server Message Block (SMB) protocol. It is designed for Windows-based applications that require enterprise-grade file shares, such as home directories, user profiles, departmental shares, and application data. The service eliminates the need to run your own Windows file server instances and manage underlying storage.

Why It Exists

Before FSx, customers who needed Windows file shares in AWS had to launch EC2 Windows instances, attach EBS volumes, configure Windows File Server roles, set up SMB shares, and manage patching, backups, and failover. This was complex and costly. FSx automates all of that, providing a highly available, scalable, and secure Windows file share as a managed service.

How It Works Internally

FSx for Windows File Server is built on top of a Windows Server instance managed by AWS. When you create a file system, AWS provisions a Windows Server instance (or a pair for Multi-AZ) with attached SSD or HDD storage. The file system is exposed via a DNS name. Clients mount the share using the SMB protocol (versions 2.0, 2.1, 3.0, and 3.1.1 are supported). Authentication is handled via Kerberos or NTLM, and the file system can join your existing AWS Managed Microsoft AD or self-managed AD.

Key Components and Defaults

Storage Capacity: Ranges from 32 GiB to 65,536 GiB (64 TiB). You choose SSD or HDD storage. SSD provides better I/O performance; HDD is for throughput-intensive workloads.

Throughput: You provision throughput in MB/s. SSD file systems support up to 2 GB/s per file system; HDD up to 1 GB/s. Throughput is shared across all clients.

Deployment Type: Single-AZ or Multi-AZ. Multi-AZ provides automatic failover to a standby in another Availability Zone, with a synchronous mirror. The DNS name remains the same after failover.

Data Deduplication: Optionally enabled, reduces storage usage by eliminating duplicate data blocks. Default is disabled.

Daily Automatic Backups: Enabled by default with a retention period of 0-35 days. You can also take manual snapshots.

Encryption: At rest using AWS KMS (default is aws/fsx key), in transit using SMB encryption or Kerberos.

Access Control: Via Windows ACLs (NTFS permissions) integrated with AD. You can also restrict access via security groups.

Shadow Copies: Volume Shadow Copy Service (VSS) snapshots for point-in-time restores by end users.

Performance Modes

FSx offers two performance modes for SSD file systems: - General Purpose: Balanced performance for most workloads. Baseline IOPS depends on storage and throughput. - Max I/O: Optimized for workloads with high IOPS, such as databases. Provides up to hundreds of thousands of IOPS.

For HDD storage, performance is throughput-oriented, with baseline IOPS of 1-3 per GiB.

Configuration and Verification

You can create a file system via the AWS Management Console, CLI, or SDK. Example CLI command to create a Single-AZ file system:

aws fsx create-file-system \
    --file-system-type WINDOWS \
    --storage-capacity 300 \
    --storage-type SSD \
    --subnet-ids subnet-12345678 \
    --windows-configuration ThroughputCapacity=200,DeploymentType=SINGLE_AZ_1,AutomaticBackupRetentionDays=7,CopyTagsToBackups=true

To verify the file system status:

aws fsx describe-file-systems --file-system-ids fs-0123456789abcdef0

Mount the share on a Windows client:

net use Z: \\fs-0123456789abcdef0.fsx.us-east-1.amazonaws.com\share

How It Interacts with Related Technologies

AWS Managed Microsoft AD: FSx can join your AD domain for user authentication. You specify the directory ID during creation.

AWS Directory Service: Works with Simple AD or AD Connector, but Managed AD is recommended for full functionality.

Amazon EFS: EFS is for Linux NFS workloads; FSx for Windows is for Windows SMB workloads. They are not interchangeable.

Amazon S3: S3 is object storage, not a file system. You can use AWS DataSync to transfer data between FSx and S3.

AWS Backup: Can manage backups for FSx, but FSx also has its own backup capability.

Amazon CloudWatch: Provides metrics like FileSystemCapacity, FileSystemUsage, DataReadBytes, DataWriteBytes, etc.

High Availability and Data Protection

Multi-AZ deployments provide automatic failover within minutes. The standby is synchronous. During failover, existing connections drop and must be re-established. Manual failover can be initiated for testing. Backups are incremental and stored in S3. Manual snapshots are retained indefinitely until deleted. Automatic backups are retained per the retention period.

Security

Network Security: File system is created within a VPC. Access is controlled via security groups and network ACLs.

Authentication: Kerberos-based authentication with AD. NTLM is also supported.

Encryption: At rest via KMS, in transit via SMB encryption. You can enforce SMB encryption on the share.

Auditing: Windows Event Logs can be sent to Amazon CloudWatch Logs for audit trails.

Limits and Quotas

Maximum file system size: 64 TiB.

Maximum single file size: 16 TiB.

Maximum number of concurrent connections: 8,000 per file system (can be increased by AWS support).

Maximum throughput per file system: 2 GB/s (SSD) or 1 GB/s (HDD).

Minimum storage: 32 GiB.

Exam-Relevant Defaults

Default automatic backup retention: 0 days (disabled) if not specified; but if enabled, default retention is 7 days.

Default storage type: SSD.

Default deployment type: Single-AZ.

Default throughput: 8 MB/s per GiB of storage (for SSD up to 2 GB/s).

Walk-Through

1

Create FSx File System

You specify the file system type (WINDOWS), storage capacity (32 GiB to 64 TiB), storage type (SSD or HDD), throughput (8 MB/s per GiB up to 2 GB/s for SSD), deployment type (Single-AZ or Multi-AZ), subnet(s), security group, and Active Directory configuration. The service provisions a Windows Server instance with the specified storage. For Multi-AZ, a standby is created in another AZ. This step typically takes 15-30 minutes.

2

Configure Active Directory Integration

You provide the directory ID of your AWS Managed Microsoft AD or self-managed AD. FSx joins the domain and creates a computer account. User authentication uses Kerberos. The file system's DNS name is registered in the AD's DNS zone. You can also specify a custom OU. If using self-managed AD, you must establish a trust or use AD Connector.

3

Set Up SMB Shares and Permissions

By default, FSx creates a share named 'share'. You can create additional shares via the Windows interface or PowerShell. Permissions are managed using NTFS ACLs, not IAM. You assign users/groups from AD. For exam, remember that IAM roles are not used for file-level access; they are for API-level actions like creating or deleting file systems.

4

Mount File Share on Client

Clients mount the share using the DNS name (e.g., fs-12345.fsx.us-east-1.amazonaws.com\share). The DNS name resolves to the file system's network interface IP. For Single-AZ, it's the IP of the single instance. For Multi-AZ, it's the IP of the primary instance; on failover, the DNS record updates to the standby's IP. Clients must be in the same VPC or have connectivity via VPC Peering, Transit Gateway, or VPN.

5

Monitor and Manage

Monitor using CloudWatch metrics (e.g., FileSystemCapacity, ThroughputUtilization). Set alarms for storage usage >80% or throughput nearing limits. You can increase storage and throughput dynamically without downtime. Storage can be increased up to 64 TiB; throughput can be increased up to the maximum. Backups are automated; you can also take manual snapshots. Use AWS Backup for centralized backup management.

What This Looks Like on the Job

Enterprise Scenario 1: Home Directories and User Profiles

A large enterprise migrates its on-premises file server to AWS. They need to provide home directories for 5,000 users. They create a Multi-AZ FSx file system with 2 TiB SSD storage and 200 MB/s throughput. The file system joins their AWS Managed Microsoft AD. Group Policy is used to map drives automatically. Shadow copies are enabled so users can restore previous versions of files. The main challenge is ensuring throughput is sufficient during peak logon times. They monitor ThroughputUtilization and adjust as needed. Misconfiguration: Setting too low throughput causes slow access; setting too high increases cost unnecessarily.

Enterprise Scenario 2: SQL Server Database Storage

A company runs SQL Server on EC2 and needs shared storage for tempdb or backup files. They use FSx for Windows File Server with Max I/O performance mode to handle high IOPS. The file system is in the same VPC as the SQL Server instance. They use SMB 3.0 with multi-channel for better throughput. They enable encryption in transit for security. The challenge is ensuring low latency; FSx adds some network latency compared to local EBS. They test and find it acceptable. Misconfiguration: Using HDD storage for high IOPS workloads causes poor performance.

Enterprise Scenario 3: Departmental File Shares with On-Premises Integration

A company wants to extend its on-premises file shares to AWS for hybrid workloads. They use FSx with Multi-AZ and connect via AWS Direct Connect. They replicate data using AWS DataSync. Users access shares from both on-premises and cloud. They use DFS Namespaces to provide a unified namespace. The challenge is authentication across domains; they establish a forest trust between on-premises AD and AWS Managed AD. Misconfiguration: Not setting proper DNS resolution causes clients unable to resolve the FSx DNS name.

How SOA-C02 Actually Tests This

What SOA-C02 Tests

Objective 3.3: Deploy and manage FSx for Windows File Server. Questions cover creation, configuration, backup, security, and performance.

Common topics: Deployment types (Single-AZ vs Multi-AZ), storage types (SSD vs HDD), throughput provisioning, AD integration, backup retention, and encryption.

Most Common Wrong Answers

1.

Choosing EFS over FSx for Windows workloads: Candidates see 'file system' and jump to EFS, but EFS is NFS (Linux). FSx for Windows is the correct answer for SMB/Windows.

2.

Using IAM for file-level permissions: IAM controls API access, not file-level NTFS permissions. AD is required for file access.

3.

Believing Multi-AZ is always better: Multi-AZ costs more and adds latency. For non-critical workloads, Single-AZ is sufficient.

4.

Confusing automatic backup retention default: The default is 0 days (disabled) if not specified, but when enabled, the default is 7 days. The exam may trick you with '7 days default'.

Specific Numbers and Terms

Minimum storage: 32 GiB (not 1 GiB).

Maximum storage: 64 TiB.

Throughput: 8 MB/s per GiB for SSD, up to 2 GB/s.

Backup retention: 0-35 days.

Supported SMB versions: 2.0, 2.1, 3.0, 3.1.1.

Max concurrent connections: 8,000 (can be increased).

Edge Cases

Cross-region access: FSx is regional; you cannot mount a share from another region without VPN or Direct Connect.

Self-managed AD: Requires network connectivity to the domain controllers and proper DNS resolution.

Data deduplication: Only available on Windows Server 2019 and later; it reduces storage but increases CPU usage.

How to Eliminate Wrong Answers

If the scenario mentions Windows, SMB, or Active Directory, eliminate EFS and S3.

If the question asks about file permissions, look for AD or NTFS, not IAM.

If the question mentions high IOPS, choose SSD with Max I/O.

If the question mentions automatic failover, choose Multi-AZ.

Key Takeaways

FSx for Windows File Server is a managed Windows file server using SMB protocol.

Minimum storage is 32 GiB; maximum is 64 TiB.

Throughput is provisioned separately; SSD baseline is 8 MB/s per GiB up to 2 GB/s.

File-level permissions are managed via NTFS ACLs integrated with Active Directory, not IAM.

Multi-AZ provides automatic failover with synchronous replication; Single-AZ is lower cost.

Automatic backup retention is 0-35 days; manual snapshots are retained indefinitely.

Supported SMB versions: 2.0, 2.1, 3.0, 3.1.1.

Max concurrent connections: 8,000 (default).

Encryption at rest uses AWS KMS; in transit uses SMB encryption.

Data deduplication is optional and available on Windows Server 2019+.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

FSx for Windows File Server

Supports SMB protocol (Windows)

Integrates with Active Directory for authentication

Provides SSD or HDD storage options

Offers Single-AZ or Multi-AZ deployment

Supports Windows-specific features like shadow copies and data deduplication

Amazon EFS

Supports NFS protocol (Linux)

Uses IAM and POSIX permissions for access

Only SSD storage (Infrequent Access tier available)

Regional (Multi-AZ by default)

Designed for Linux workloads; no shadow copies or deduplication

FSx for Windows File Server (Single-AZ)

Lower cost (no standby instance)

No automatic failover

Suitable for non-critical workloads

Lower write latency (no synchronous replication)

Backups are taken from primary instance

FSx for Windows File Server (Multi-AZ)

Higher cost (includes standby instance in another AZ)

Automatic failover within minutes

Suitable for critical production workloads

Higher write latency due to synchronous replication

Backups are taken from standby instance (to avoid impact)

Watch Out for These

Mistake

FSx for Windows File Server uses IAM for file access permissions.

Correct

FSx uses Windows NTFS ACLs integrated with Active Directory. IAM is only for API-level actions (create, delete, describe).

Mistake

You can mount an FSx file system from any region without special configuration.

Correct

FSx is regional. Cross-region access requires VPN, Direct Connect, or VPC Peering with inter-region peering.

Mistake

Multi-AZ deployment provides automatic failover with no connection interruption.

Correct

During failover, existing SMB connections drop and must be re-established. The DNS name updates to point to the standby.

Mistake

FSx for Windows File Server supports NFS protocol.

Correct

FSx for Windows only supports SMB. For NFS, use Amazon EFS or FSx for Lustre.

Mistake

You can increase storage beyond 64 TiB by contacting support.

Correct

The maximum storage is 64 TiB per file system. You cannot exceed this limit.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

Can I use FSx for Windows File Server with a self-managed Active Directory?

Yes. You can join FSx to a self-managed AD as long as the domain controllers are reachable from the VPC (via VPN or Direct Connect) and DNS resolution is configured. You must use AWS Directory Service's AD Connector to proxy authentication, or establish a trust between your on-premises AD and AWS Managed Microsoft AD.

What happens when a Multi-AZ FSx file system fails over?

During failover, the primary instance becomes unavailable and the standby takes over. Existing SMB connections are dropped and must be re-established. The DNS name automatically updates to point to the standby's IP. There is a brief interruption (typically 1-2 minutes). Automatic failover occurs if the primary instance fails or if the Availability Zone experiences an outage.

How do I back up an FSx for Windows File Server?

FSx supports automatic daily backups with a retention period of 0 to 35 days. You can also take manual snapshots at any time. Backups are incremental and stored in Amazon S3. You can restore a backup to a new file system. Additionally, you can use AWS Backup to manage backups centrally.

Can I increase the storage capacity of an existing FSx file system?

Yes, you can increase storage capacity up to 64 TiB without downtime. You cannot decrease storage. To increase, use the console or CLI. The file system remains available during the increase, though performance may be slightly impacted.

What is the difference between SSD and HDD storage on FSx?

SSD storage provides higher IOPS (baseline 3 IOPS/GiB, up to hundreds of thousands with Max I/O) and is suitable for latency-sensitive workloads like databases. HDD storage is throughput-oriented (baseline 1-3 IOPS/GiB) and is cheaper, suitable for large sequential workloads like media streaming or backups.

How does FSx for Windows File Server handle encryption?

Encryption at rest is enabled by default using an AWS KMS key (default aws/fsx or a custom key). Encryption in transit is optional and can be enforced using SMB encryption or Kerberos. Both are configurable during file system creation or later.

Can I mount an FSx file system from an on-premises server?

Yes, if you have network connectivity via AWS Direct Connect or a VPN. The on-premises server must be able to resolve the FSx DNS name and have SMB connectivity. You must also ensure that Active Directory authentication works across the connection.

Terms Worth Knowing

Ready to put this to the test?

You've just covered FSx for Windows File Server — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.

Done with this chapter?