What Is Amazon FSx for Windows File Server? Managed SMB File Shares with Active Directory — and How It Compares to EFS

Amazon FSx for Windows File Server is AWS's managed Windows file server — a fully native Windows file system, speaking the SMB protocol, joined to your Active Directory, that you never have to patch, reboot, or hardware-troubleshoot yourself. It gives you Windows file shares that behave exactly like the ones your on-premises Windows administrators already know, because they are the same thing: same SMB protocol, same NTFS permissions, same Windows ACLs, same group policy integration. And here's the part that makes the comparison with EFS simple: EFS does not support Windows — FSx for Windows File Server is the answer to that gap. If your servers run Windows and need shared file storage, this is the service; if they run Linux, EFS is usually the cheaper call. FSx for Windows File Server scales to tens of petabytes, delivers sub-millisecond latencies on SSD storage, and requires an Active Directory domain — no AD, no FSx for Windows.

Jake's shop had gone Windows a while back — the inventory system ran on Windows Server, the repair bench machine was Windows, and the reason was boring and practical: the software he used for phone diagnostics only ran on Windows. So when Ethan had explained EFS to him for the Linux side of the world, Jake's first question was the one you're already thinking:

"Great — where's mine?"

"FSx for Windows File Server," Ethan said. "Same idea as EFS — managed, shared, grows with you — but it's a real Windows file server under the hood instead of an NFS appliance. It joins your Active Directory, it uses the SMB protocol Windows speaks natively, and your Windows ACLs and group policies just work. Your admin doesn't learn anything new to manage it."

What FSx for Windows File Server Actually Is

Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers, backed by a fully native Windows file system. It has the features, performance, and compatibility to easily lift and shift enterprise applications to the AWS Cloud. It supports a broad set of enterprise Windows workloads with fully managed file storage built on Microsoft Windows Server, with native support for Windows file system features and the industry-standard SMB protocol.

What "fully native Windows file system" means in practice: your existing tools keep working. The code, applications, and administrative tools that Windows developers and administrators use today can continue to work unchanged — the same Windows ACLs, the same PowerShell management, the same Shared Folders GUI, the same DFS Namespaces if you use them. FSx isn't an SMB emulation layer or a translation shim; it's a Windows file server you're renting by the hour instead of rack-mounting.

The SMB protocol — Server Message Block — is Windows' native language for shared file access over a network. It's been the Windows standard since the early 1990s, and every Windows machine from Windows 7 and Windows Server 2008 onward speaks it. FSx supports SMB versions 2.0 through 3.1.1, which means every modern Windows client connects without any driver, plugin, or configuration change — they just map a drive letter to a UNC path and go.

Performance-wise, FSx delivers consistent sub-millisecond latencies, and supports up to tens of petabytes of data and tens of GB/s of throughput per file system. It's designed for the enterprise workloads where EFS's NFS approach can't go: native Windows applications that assume SMB semantics.

How FSx for Windows File Server Works: The Architecture

FSx for Windows File Server is organized around three resources: the file system (the actual storage and file servers), file shares (folders within the file system exposed over SMB), and backups (point-in-time copies managed by AWS).

When you create a file system, you specify three capacity numbers that you can change later as needs evolve: storage capacity in GiB, SSD IOPS, and throughput capacity in MBps. These are provisioned independently — you can have lots of storage with modest throughput (for archival-style workloads) or modest storage with high throughput (for active databases), and you pay for exactly the mix you choose.

A file system comes with a default Windows file share called \share, and you can create and manage as many other shares as you want using the Shared Folders GUI tool — the same tool a Windows admin uses on any file server. Shares are accessed via the file system's DNS name or via DNS aliases you associate with it.

For management, FSx gives you a custom remote PowerShell endpoint — you connect to a PowerShell session on the file server and run the same commands you'd run on any Windows file server. This is where you configure shares, quotas, file screening, deduplication, and shadow copies. The full PowerShell command set is covered in its own section below.

The Active Directory Requirement: The Question Every Architecture Review Starts With

The good news is AWS gives you two paths for the AD itself. The first is AWS Managed Microsoft AD — a fully managed Active Directory domain that AWS runs for you, which your FSx file system joins directly, and which your EC2 instances and other resources join like any domain. The second is a self-managed Active Directory — your existing on-premises AD or an AD you run on EC2, connected to FSx over a VPN, Direct Connect, or within AWS.

For self-managed AD, you delegate privileges to the Amazon FSx service account so it can join the file system to your domain — this is a documented, specific set of OU and group permissions, not an open-ended grant. One documented detail worth knowing: for Single-AZ 2 and all Multi-AZ file systems, the Active Directory domain name cannot exceed 47 characters, and Amazon FSx requires a direct connection to your DNS IP address — connection via an internet gateway is not supported. Use VPN, VPC peering, Direct Connect, or Transit Gateway instead.

"So the identity check is the same one my shop already does," Jake said. "Same users, same groups, same permissions — I'm not building a new user database in the cloud."

"That's the design goal," Ethan said. "Windows shops move to FSx precisely because they don't want a parallel identity system. The domain is the domain, wherever the file server lives."

The FSx Family: Four Services, One Name (and Why the Confusion Is Justified)

"What is AWS FSx?" is a genuinely confusing search because FSx is not one service — it's a brand covering four fundamentally different file systems, chosen by protocol and workload. Here's the family, in one table:

The one-line differentiator: FSx for Windows is the Windows-native one. The others each solve a different problem — ONTAP for multi-protocol NetApp shops, OpenZFS for ZFS-native Linux work, Lustre for high-performance computing. If you arrived here from "what is FSx," the honest first question back is "which one?" — and for Windows shared storage, the answer is FSx for Windows File Server.

Two adjacent comparisons people also search: FSx vs Storage Gateway / File Gateway — FSx File Gateway (a Storage Gateway type) is an on-premises appliance that caches FSx for Windows shares locally, giving on-premises servers low-latency access to cloud-hosted FSx data. It's for hybrid: your data lives in FSx in AWS, your on-prem users get local-speed access through the gateway's cache. FSx itself is the file system; the gateway is the bridge to on-premises. And FSx vs Azure Files — Azure Files is the closest Azure equivalent for SMB shares, with a premium tier targeting the same workloads; FSx for Windows is the AWS-native answer when your workloads and domain live in AWS.

FSx vs EFS: The Head-to-Head That Decides Your Architecture

"aws fsx vs efs" is the single most-asked FSx question because it's the actual architecture decision — and the answer is cleaner than most comparisons, because the differentiator is blunt:

The blunt rule: if your workload is Windows and needs AD-authenticated shared storage, FSx; if it's Linux and POSIX-native, EFS. Linux machines can mount FSx for Windows shares (the docs cover the mount procedure), and Windows machines cannot mount EFS — so when both OS families are in play, FSx is the common ground, at the cost of running the AD infrastructure EFS doesn't need.

One subtlety worth naming: "aws fsx mount linux" is a real search cluster, and the answer is yes — an EC2 Linux instance can mount an FSx for Windows share over SMB, using Kerberos for authentication if the instance is domain-joined. The mount command differs from NFS (it's a CIFS mount with sec=krb5), and the docs walk the full procedure for both domain-joined and non-domain-joined Linux instances.

Getting Started: Creating Your First FSx for Windows File System, Step by Step

The full getting-started path, from zero to a mounted share, condensed from the official walkthrough:

1. Set up an Active Directory. If you don't have one, create an AWS Managed Microsoft AD directory through the Directory Service console. If you have an existing corporate AD, create a trust relationship between your AWS Managed AD and the corporate domain — a one-way forest trust where the AWS managed forest trusts the corporate domain forest is sufficient for Windows authentication in FSx.
2. Launch a Windows EC2 instance in the same VPC as your directory. Windows Server 2016 Base or later is the requirement, and the getting-started guide uses a t2.micro for the exercise.
3. Join the instance to the directory using the Directory Service admin credentials, so the instance can authenticate against the same domain the file system will join.
4. Create the FSx file system in the FSx console — choose Windows File Server as the file system type, select Single-AZ or Multi-AZ deployment, provision storage capacity, SSD IOPS, and throughput capacity, choose your VPC and subnets, and join the file system to your Active Directory (either the AWS Managed one or your self-managed one, providing the DNS server IPs and domain credentials).
5. Map the file share to your EC2 instance. From the joined Windows instance, open File Explorer and map a drive to \\amznfsxabcd1234.your-domain.com\share — the DNS name comes from the file system details page in the console, and \share is the default share that exists on every file system.
6. Write data and verify. Create a file on the mapped drive from one instance; from a second instance (or after remounting from the first), confirm the file appears. That's the shared-storage test.
7. Take a backup — either let the automatic daily backup run, or take a manual backup from the console. Verify it appears in the Backups tab.
8. Clean up (if this was a test) — delete the file system and the directory, in that order. Remember: FSx has no free tier, so a forgotten test file system keeps billing.

The single biggest failure point in this sequence is step 4 — the AD configuration. If the domain controllers aren't reachable from the subnets you chose, or the service account permissions aren't delegated correctly, the file system creation fails or lands in a MISCONFIGURED state. Run AWS's AD validation before you start, and the rest of the sequence is mechanical.

Managing FSx with PowerShell: The Commands You'll Actually Use

FSx for Windows File Server gives you a remote PowerShell endpoint on the file server itself — you start a long-lived PowerShell session against the file system and run commands using the Amazon FSx CLI for Remote Management on PowerShell. This is the same management surface a Windows admin uses on any Windows file server, with FSx-specific cmdlets added. The commands that do the most day-to-day work:

Beyond the FSx-specific cmdlets, the remote PowerShell session gives you access to standard Windows file server management: FSRM (File Server Resource Manager) for quotas, file screening, file classification, and storage reports; deduplication management; shadow copy configuration; and user session and open-file management. The docs walk through each of these as separate administration topics, all reachable through the same remote PowerShell door.

DFS Namespaces and Storage Quotas: The Windows Features That Justify FSx

Two Windows-native features are the reason many shops choose FSx over rolling their own file server on EC2 — and both are things EFS simply cannot do.

DFS Namespaces (Distributed File System Namespaces) lets you group file shares on multiple FSx file systems into a single namespace — so users see \\company\shares\finance without knowing (or caring) which underlying file system hosts it. This matters for two reasons: you can present one consistent namespace across multiple file systems for scale, and you can shard data across file systems for scale-out performance while users still see one tree. If your on-prem Windows environment already uses DFS Namespaces, FSx supports it — one documented limitation: DFS-Replication (DFS-R) is not supported on Multi-AZ or Single-AZ 2 file systems; use DFS Namespaces (supported) rather than DFS-R.

Storage quotas through FSRM (File Server Resource Manager) let you set hard or soft limits on how much data a user, group, or folder can consume. On a shared file system without quotas, one user's 2 TB of video files can fill the volume for everyone — quotas prevent that, and they're managed through the same remote PowerShell interface, with PowerShell functions for creating, modifying, and reporting on them. This is the kind of Windows-native management that keeps a Windows admin in tools they already know.

Single-AZ vs Multi-AZ: The Availability Decision

FSx for Windows File Server offers two deployment types, and the choice is a durability-versus-cost decision:

Single-AZ file systems ensure high availability within a single Availability Zone by automatically detecting and addressing component failures. Data is replicated within the AZ, and AWS replaces failed infrastructure automatically. Two generations exist — Single-AZ 1 and Single-AZ 2, with Single-AZ 2 being the current one supporting both SSD and HDD storage types. Cheaper than Multi-AZ, but an AZ-level event takes the file system (and potentially the data) with it.

Multi-AZ file systems provide high availability and failover support across multiple Availability Zones by provisioning and maintaining a standby file server in a separate AZ within the Region. When the primary file server or its AZ becomes unavailable, FSx automatically fails over to the standby — no action from you. This is the recommended deployment for production workloads, and the cross-AZ replication traffic is included in the throughput capacity price rather than billed separately. Multi-AZ file systems have a primary and a standby file server, each in its own AZ and subnet, and you choose both during creation.

The rule of thumb most shops land on: Multi-AZ for anything a business depends on, Single-AZ for dev, test, and data you can afford to lose. The cost gap is real, and for a dev environment running a file system nobody touches on weekends, Single-AZ is the honest right answer.

Performance: SSD vs HDD, and the Three Capacity Knobs

FSx for Windows gives you price and performance flexibility by offering both SSD and HDD storage types, with three capacity settings you provision independently:

Storage capacity — how many GiB of storage. HDD is designed for a broad spectrum of workloads including home directories, user and departmental shares, and content management systems. SSD is designed for the highest-performance and most latency-sensitive workloads including databases, media processing, and data analytics.

SSD IOPS — by default, 3 IOPS are included for every GB of SSD storage, and you can optionally provision a higher level. FSx automatically maintains 3 SSD IOPS per GiB of storage capacity, up to a documented maximum per file system, and you pay for the average IOPS provisioned above your included rate.

Throughput capacity — how fast data moves, in MBps, provisioned per your workload's need. Higher throughput levels also come with higher levels of IOPS and a larger amount of cache memory on the file server. You can modify storage, SSD IOPS, and throughput capacities after creation, so you pay only for what you need as needs change. One note from the getting-started docs: if you plan to enable file access auditing, you must choose a throughput capacity of 32 MBps or greater.

On raw numbers: FSx for Windows delivers consistent sub-millisecond latencies, scales to petabytes of storage, and file systems can deliver up to 2 GB/s and up to 80,000 IOPS for data accessed from persistent disk storage, with higher throughput available from in-memory cache depending on access patterns.

Pricing: What FSx Actually Costs, With Verified Rates

With Amazon FSx, there are no upfront hardware or software costs. You pay for only the resources used, with no minimum commitments, setup costs, or additional fees. Usage is prorated by the hour, billed monthly. There are five categories: storage capacity (per GB-month, varying by Single-AZ/Multi-AZ and SSD/HDD), SSD IOPS (3 included per GB of SSD; extra provisioned IOPS billed per IOPS-month), throughput capacity (per MBps-month, roughly double on Multi-AZ), backups (per GB-month, incremental so only changes after the most recent backup are stored), and data transfer (cross-AZ at $0.01/GB in each direction for Single-AZ and older Multi-AZ systems; inter-Region at rates that vary by destination). Here are the actual rates, verified against the live pricing page for US East (Ohio) — other Regions vary:

AWS's own worked example, from the pricing page: storing 10 TB of general-purpose file share data using HDD storage, with typical deduplication savings of 50–60%, provisioned as a 5 TB multi-AZ file system with 16 MBps of throughput capacity and an average of 5 TB of backup storage during the month:

Three things to read off that example. First, backup storage can cost more than the primary storage — 5 TB of backup at $256 exceeded the 5 TB of primary HDD at $128 — so factor backups into any budget estimate. Second, deduplication is a real cost lever: the example assumed 10 TB of data on a 5 TB file system because of dedup savings, and typical savings run 30–50% for office documents, 70–80% for software binaries, 50–60% for mixed general-purpose content. Third, the three independent capacity knobs mean two shops with identical data volumes can have wildly different bills depending on throughput and IOPS choices — use the calculator.

One data-transfer detail from the pricing page worth knowing: there are no charges accessing the file system from its preferred AZ. For Multi-AZ file systems created on or after February 23, 2022, there are no cross-AZ charges at all when accessing from another AZ. For Single-AZ file systems (and older Multi-AZ), cross-AZ access bills $0.01/GB in each direction. And for all Multi-AZ file systems, the replication traffic between AZs is already included in the throughput capacity price — you're not billed twice for the standby's data.

Data deduplication, the honest cost saver

FSx can deduplicate and compress your data, and the savings are not marginal. AWS's published typical savings: 30–50% for office documents, photos, music, and videos; 70–80% for software binaries, build files, and program symbols; 50–60% for general-purpose file share contents. For a shop with a large build-artifact or software-deployment share, dedup alone can justify the migration.

With dedup factored in, the pricing page shows the effective rates directly: $0.065 per GB-month for Single-AZ SSD, $0.0065 for Single-AZ HDD, $0.115 for Multi-AZ SSD, and $0.0125 for Multi-AZ HDD, assuming the typical 50% savings — which makes FSx for Windows the lowest-cost managed file storage AWS offers for Windows workloads. It's managed through the remote PowerShell endpoint, the same way you'd manage it on a Windows file server on-premises.

Does FSx have a free tier?

No. FSx — in all four variants — does not offer an AWS Free Tier allowance. There is no free 5 GB or trial month; billing starts from the first provisioned GB-Month and MBps-month. If you're evaluating FSx on a personal account, assume the meter runs from minute one, and tear down test file systems when you're done.

What FSx for Windows Is Actually Used For

Windows applications and workloads ideal for FSx include business applications, home directories, web serving, content management, data analytics, software build setups, and media processing workloads. The four that show up most in real deployments:

Home directories and user shares. Every user's files live on FSx, mounted by whatever Windows desktop or WorkSpace they log into. The AD integration means permissions follow the user, not the machine, and DFS Namespaces let you present shares under a single consistent namespace across multiple file systems.

SQL Server. FSx supports Microsoft SQL Server deployments on EC2 — the docs cover using FSx with SQL Server for the data and log files, with multi-AZ providing the high-availability story. This is one of the workloads where SSD storage and provisioned IOPS matter most, and where FSx's Windows-native consistency (VSS snapshots, NTFS semantics) is the reason it works where a Linux file system wouldn't.

FSLogix profile containers for virtual desktops. WorkSpaces and AppStream 2.0 deployments commonly use FSLogix — a technology that containers users' Windows profiles into virtual disks — with FSx for Windows as the backing store. The profile loads fast, the user's experience is consistent across sessions, and FSx's SMB support is exactly what FSLogix expects. This is one of the highest-volume real-world FSx use cases.

Lift-and-shift of Windows applications. The broadest category: any business application that today uses a Windows file server on-premises — an ERP's shared folder, a media asset store, a build server's artifact share — moves to FSx with minimal rework because the file system behaves identically. The application doesn't know it's in the cloud; it just knows SMB and AD.

Mounting FSx: From Windows, Linux, macOS, and On-Premises

FSx is accessible from compute instances with the SMB protocol. You can map your file shares on Amazon EC2 instances, on WorkSpaces instances, AppStream 2.0 instances, and VMware Cloud on AWS VMs, and you can access from on-premises instances using AWS Direct Connect or Site-to-Site VPN. You can also access shares across VPCs, accounts, and Regions using VPC peering or transit gateways.

From Windows, mapping a share is the standard operation any Windows admin already knows — map a drive to the UNC path, using the file system's DNS name or a DNS alias. On the command line:

net use Z: \\amznfsxabcd1234.your-domain.com\share

From Linux, the mount is a CIFS mount with Kerberos authentication — the docs give the full procedure for both domain-joined and non-domain-joined Linux instances. The shape of the command:

sudo mount -t cifs //file-system-dns-name/share /mnt/fsx \
  -o vers=3.1.1,sec=krb5,cruid=ad_user,ip=preferred-file-server-ip

The options that matter: vers sets the SMB version (2.0 through 3.1.1 supported), sec=krb5 enables Kerberos authentication, and ip points at the file system's preferred file server — findable in the console or via describe-file-systems. From macOS, the docs describe mounting via the GUI (Connect to Server in Finder with the SMB URL) for both domain-joined and non-joined Mac instances.

One DNS detail worth knowing before it bites: the DNS name format differs by deployment. For a Single-AZ file system joined to AWS Managed Microsoft AD, the DNS name is the file system ID (fs-0123456789abcdef0.ad-domain.com); for a Single-AZ file system joined to a self-managed AD, and for any Multi-AZ file system, the DNS name is an amznfsx... alias. The console and DescribeFileSystems always give the right value — copy it from there rather than constructing it by hand.

For on-premises access, two paths exist: Direct Connect or Site-to-Site VPN directly to the file system's VPC, or Amazon FSx File Gateway — a Storage Gateway type that maintains a local cache of your frequently accessed FSx data on-premises, giving on-prem servers and users low-latency access to cloud-hosted file shares without a constant VPN round-trip. The gateway approach matters when on-prem users need local-speed reads of data that lives in FSx.

Backups, Shadow Copies, and Replication: The Data Protection Stack

FSx for Windows has three layers of data protection, and they serve different jobs:

Backups are file-system-consistent, highly durable, and incremental. To ensure file system consistency, FSx uses the Volume Shadow Copy Service (VSS) — so backups are true point-in-time copies even under active writes. Automatic daily backups are turned on by default when you create a file system, and you can take additional manual backups at any time. Backups are incremental — only changes after the most recent backup are stored — and you can copy backups across Regions for a DR copy, or restore individual files from a backup to a new file system.

Shadow copies are the Windows-native end-user time machine: point-in-time snapshots users can browse themselves via "Previous Versions" in Windows Explorer, without an admin in the loop. FSx lets you configure shadow copy schedules, storage limits, and manual snapshots through the remote PowerShell endpoint — the same management surface as any Windows file server. One documented operational caution: avoid scheduling a shadow copy job to run while an FSx automatic backup is in progress, since both use VSS internally and can contend.

Replication for ongoing copies is handled by AWS DataSync, which can schedule periodic replication of an FSx for Windows file system to a second file system — for both in-Region and cross-Region deployments. There is no native FSx cross-Region replication feature distinct from DataSync and backup-copy; the replication story is "DataSync for continuous, backup copies for DR."

Security: Encryption, ACLs, and the Port Map

FSx provides multiple levels of security and compliance. Data at rest is automatically encrypted — for both file systems and backups — using keys you manage in AWS KMS. Data in transit is automatically encrypted using SMB Kerberos session keys. There's no "encryption off" toggle; it's on by design. FSx has been assessed to comply with ISO, PCI-DSS, and SOC certifications, and is HIPAA eligible.

Access control stacks in three layers: file and folder level with Windows ACLs (the NTFS permissions your admins already manage); file system level with VPC security groups (network-level control over which instances can reach the file system at all); and API level with IAM policies (control over who can create, delete, and modify FSx resources in your AWS account).

The security group port requirements, from the getting-started documentation — add these inbound and outbound rules to allow the following ports, from and to the IP addresses or security group IDs associated with your client compute instances:

Two specifics worth knowing: add outbound rules to allow all traffic to the Active Directory you're joining (either the security group ID of your AWS Managed AD, or the IP addresses of your self-managed domain controllers). And end-user access auditing is available — you can set file and folder auditing controls and manage file access auditing, with the audit trail going where Windows admins expect it. FSx integrates with CloudTrail for API-level logging. One prerequisite for auditing: the file system's throughput capacity must be 32 MBps or greater.

Maintenance Windows and Quotas: The Operational Details

Every FSx for Windows file system has a weekly maintenance window — a scheduled time when AWS applies software updates and performs infrastructure maintenance. You can change the maintenance window through the console or the remote PowerShell interface, and for Multi-AZ file systems, maintenance on the standby file server happens first, then failover occurs, then maintenance on the primary — so there's no downtime window in the maintenance period for Multi-AZ deployments. For Single-AZ, the file system may be briefly unavailable during its maintenance window.

On quotas — service limits, not FSRM user quotas: FSx has documented quotas for things like the number of file systems per account and per Region, storage capacity minimums and maximums, and throughput capacity ranges per deployment type. The quotas page in the docs has the current numbers with their limit names — use the "service quotas" reference rather than blog-post numbers, because limits get raised over time and a copied table goes stale.

Troubleshooting: The Failures That Actually Happen

FSx failures cluster into a small set of causes, and the docs have a dedicated troubleshooting section for each. The ones that consume the most debugging hours:

Two habits prevent most of this table: validate the AD configuration before creating the file system (AWS ships a validation tool for exactly this), and get the security group port set right the first time from the table above rather than discovering which port is missing one at a time.

The FSx Interview Questions You'll Actually Get

If you're preparing for an AWS interview, these are the FSx questions that come up, with the answers in the shape interviewers want:

"What is FSx and how does it differ from EFS?" FSx is a family of managed file systems; FSx for Windows File Server is the Windows-native one, speaking SMB and requiring Active Directory. EFS is the NFS-based elastic file system for Linux. The differentiator to name: protocol and OS support — FSx for Windows for Windows workloads, EFS for Linux.

"What are the four FSx types?" FSx for Windows File Server (SMB, AD-integrated), FSx for NetApp ONTAP (multi-protocol: SMB, NFS, iSCSI), FSx for OpenZFS (NFS, ZFS features), and FSx for Lustre (HPC, massive parallel throughput). Each solves a different workload; the protocol and the workload decide which.

"How does FSx achieve high availability?" Single-AZ replicates data within a single AZ with automatic infrastructure replacement. Multi-AZ provisions a standby file server in a separate AZ with automatic failover. Multi-AZ is the recommended production deployment.

"What security does FSx provide?" Encryption at rest with KMS keys (default on), encryption in transit with SMB Kerberos session keys (default on), Windows ACLs at file/folder level, VPC security groups at the network level, and IAM at the API level. Compliance: ISO, PCI-DSS, SOC, HIPAA eligible.

"How is FSx billed?" Five components: storage capacity per GB-month (SSD $0.13 Single-AZ / $0.23 Multi-AZ; HDD $0.013 / $0.025 at US East rates), SSD IOPS above the included 3 per GB ($0.012 / $0.024 per IOPS-month), throughput capacity per MBps-month ($2.20 / $4.50), backup storage per GB-month ($0.05, incremental), and data transfer for cross-AZ and cross-Region access. No minimum fee or setup charge.

"How do you manage FSx?" Through the AWS console and CLI for the file-system lifecycle (create, modify, delete, backup), and through a remote PowerShell endpoint for Windows-native administration — shares, quotas, deduplication, shadow copies, DFS Namespaces, FSRM. The PowerShell endpoint gives you the same cmdlet surface as a native Windows file server.

FAQ

What does AWS FSx stand for?

FSx doesn't officially stand for anything — it's AWS's brand for its family of fully managed file systems. The "x" is styling, not an acronym. There are four: FSx for Windows File Server, FSx for NetApp ONTAP, FSx for OpenZFS, and FSx for Lustre.

Does AWS FSx support SMB?

FSx for Windows File Server does — SMB is its native protocol, supporting versions 2.0 through 3.1.1. FSx for NetApp ONTAP also supports SMB (alongside NFS and iSCSI). FSx for OpenZFS and FSx for Lustre do not; they're NFS- and Lustre-based respectively.

Does AWS FSx require Active Directory?

FSx for Windows File Server: yes — it must be joined to a Microsoft Active Directory domain, either AWS Managed Microsoft AD or your self-managed AD. The other FSx variants (ONTAP, OpenZFS, Lustre) do not require AD.

What is the difference between FSx and EFS?

FSx for Windows speaks SMB and is built on a native Windows file system, requiring Active Directory. EFS speaks NFS and supports Linux and macOS — not Windows. FSx is provisioned (you pick storage, IOPS, throughput); EFS is elastic and grows automatically. Windows workloads: FSx. Linux workloads: EFS.

Can Linux mount FSx for Windows File Server?

Yes. EC2 Linux instances can mount FSx for Windows shares over SMB, using Kerberos authentication (sec=krb5) when domain-joined. The docs cover the full procedure for both domain-joined and non-domain-joined Linux instances. Windows-native clients remain the primary use case, but Linux mounting is supported.

How much does AWS FSx cost?

You pay for five things: storage capacity (SSD $0.13 Single-AZ / $0.23 Multi-AZ per GB-month; HDD $0.013 / $0.025), SSD IOPS above the included 3 per GB ($0.012 / $0.024 per IOPS-month), throughput capacity ($2.20 / $4.50 per MBps-month), backups ($0.05 per GB-month, incremental), and data transfer. AWS's worked example: 10 TB of data on a 5 TB multi-AZ HDD system with 16 MBps throughput totals $456/month in US East.

Does FSx have a free tier?

No. FSx does not offer an AWS Free Tier allowance in any variant. Billing starts from the first provisioned GB-Month and MBps-month — there is no free tier, trial, or included allowance.

What is FSx for NetApp ONTAP?

A different FSx variant — a fully managed NetApp ONTAP file system supporting SMB, NFS, and iSCSI simultaneously, with ONTAP's data-management features (SnapMirror, FlexClone, tiering policies) built in. Choose it for multi-protocol environments or NetApp shops; choose FSx for Windows for pure Windows workloads.

What is FSx for Lustre?

The high-performance-computing FSx variant — a managed Lustre file system built for massive parallel throughput from hundreds or thousands of compute clients, with integration to S3 for data sets that live there. ML training and HPC are the canonical use cases; it has nothing to do with Windows.

Is AWS FSx serverless?

No — and yes, depending on which part you mean. You don't manage servers: AWS provisions, patches, and monitors the file server infrastructure, so it's "fully managed" in AWS's terminology. But it's not serverless in the per-request billed, no-capacity sense of Lambda — you provision specific storage, IOPS, and throughput capacities and pay for them whether fully used or not.

What ports does AWS FSx use?

UDP 53, 88, 123, 389, 464 and TCP 53, 88, 135, 389, 445, 464, 636, 3268, 3269, 5985, 9389, 49152-65535 — covering DNS, Kerberos, SMB, LDAP/LDAPS, Global Catalog, WinRM, AD Web Services, and RPC dynamic ports. The full table with what each port does is in the security section above.

Is AWS FSx encrypted?

Yes, by default. Data at rest is automatically encrypted using keys you manage in AWS KMS, for both file systems and backups. Data in transit is automatically encrypted using SMB Kerberos session keys. There is no encryption-off option.

Can you restore individual files from an FSx backup?

Yes. You can restore individual files from a backup to a new file system — the restore procedure supports file-level granularity, not just whole-file-system restores. Combined with shadow copies (user-facing Previous Versions), this gives both admin-level and user-level recovery paths.

Does FSx support shadow copies?

Yes — FSx supports Windows shadow copies (VSS), configurable through the remote PowerShell endpoint, with users able to browse and restore previous versions themselves via Windows Explorer. One caution: don't schedule shadow copies to run while an automatic backup is in progress, since both use VSS.

Does FSx support DFS Namespaces?

Yes — you can group file shares on multiple FSx file systems into a single namespace using DFS Namespaces, and shard data across file systems for scale-out performance. DFS-Replication (DFS-R), however, is not supported on Multi-AZ or Single-AZ 2 file systems.

What is the Terraform resource for FSx for Windows?

aws_fsx_windows_file_system. For the ONTAP variant, the resources include the storage virtual machine and volume resources. The Windows resource takes the deployment type, storage capacity, throughput capacity, and the Active Directory configuration as inputs.

Can you use FSx with Kubernetes?

FSx for Windows File Server doesn't have its own dedicated CSI driver the way FSx for Lustre does. Kubernetes workloads that need Windows file shares can mount FSx via the generic SMB CSI driver (csi-driver-smb), pointing at the file system's DNS name — but this is a generic SMB mount, not an FSx-specific integration. For a purpose-built CSI experience on EKS, FSx for Lustre and FSx for ONTAP are the variants with dedicated drivers.

Revision note. Written September 2026. Rates vary by Region — check the live pricing page for yours before committing to a number. If you've been squinting at four services all called FSx trying to figure out which one is the Windows one — it's this one, and now you know why it needs your domain controller before it will say a word.