Amazon FSx for Windows File Server vs. FSx for Lustre
Published on · Updated on
Replaced outdated claims with a practical, documentation-based service comparison.
Amazon FSx for Windows File Server and Amazon FSx for Lustre are managed file systems, but they serve different clients and workloads. Choose Windows File Server when applications need SMB shares, Windows file semantics, or Active Directory authentication. Choose Lustre when Linux compute jobs need parallel access to a large shared dataset and high aggregate throughput, often with Amazon S3 as the durable data repository.
Start with the protocol and application requirements. These services are not drop-in alternatives: changing file protocols, permissions, or data workflows can require application and operational changes.
Quick comparison
| Decision area | FSx for Windows File Server | FSx for Lustre |
|---|---|---|
| File protocol and clients | SMB 2.0–3.1.1; supported Windows, Linux, and macOS SMB clients. | Lustre protocol; install a compatible Lustre client on supported Linux systems. |
| Identity and permissions | Join a Microsoft Active Directory domain; use domain identities and Windows ACLs. | Use Linux UID/GID and POSIX permissions, with network controls and optional root squash; it does not use Windows ACLs or AD for file access. |
| Typical workload | Windows applications, SMB shares, user and department folders, and shared content repositories. | Linux-based HPC, machine learning, and data-processing jobs that need concurrent parallel file access. |
| Availability choices | Choose Single-AZ or Multi-AZ. Multi-AZ maintains a standby file server in another Availability Zone. | Choose scratch or persistent deployment and a compatible storage class. Durability and availability vary by option. |
| Storage and performance | Choose SSD or HDD, then configure storage capacity, throughput, and—where supported—SSD IOPS for the workload. | Choose among SSD, HDD, and Intelligent-Tiering options where supported. Throughput scales with provisioned storage for SSD/HDD classes; Intelligent-Tiering has separately provisioned throughput. |
| S3 relationship | No native linked-S3 file-system workflow. Use a separate transfer or application path when S3 is involved. | Eligible file systems can link S3 data repositories for import, export, and staged processing. Intelligent-Tiering does not support linked S3 data repositories. |
| Backups | Automatic daily backups are enabled by default; user-initiated backups and AWS Backup are also available. | Backups are supported for standalone persistent file systems, not scratch file systems or file systems linked to S3. |
| Cost model | Storage, throughput, optional additional SSD IOPS, backups, and applicable data transfer charges. | Provisioned SSD/HDD storage, with throughput tied to capacity; or consumed data and provisioned throughput for Intelligent-Tiering. Additional metadata IOPS, Intelligent-Tiering read cache and data requests, eligible backups, and transfer may also be billed. |
These are different storage patterns: Windows File Server is a shared SMB file server for enterprise applications, while Lustre is a parallel file system for compute jobs. Confirm client compatibility and recovery needs before comparing prices.
FSx for Windows File Server explained
Protocol, identity, and file sharing
FSx for Windows File Server exposes file shares over SMB and supports SMB versions 2.0 through 3.1.1. Windows clients are the common choice, and AWS also documents supported Linux and macOS SMB clients. Clients can access file systems from on premises over VPN or Direct Connect when network and directory connectivity are configured. Check AWS's supported-client guidance for the operating systems and configurations you plan to use.
A file system must join a supported Microsoft Active Directory domain. Options include AWS Managed Microsoft AD, self-managed Microsoft AD, and Microsoft Azure Active Directory Domain Services in documented configurations. Users authenticate with their domain accounts, and standard Windows ACLs control access to shares, files, and folders. This is a good fit when an application expects SMB paths, Windows ACLs, or existing domain identities. It is not an IAM-authenticated file share: IAM controls AWS API and resource management, while clients use SMB and domain authentication. See the AWS guide to using Active Directory with FSx for Windows.
Availability, storage, performance, and cost
Windows File Server offers Single-AZ and Multi-AZ deployment types. Single-AZ automatically recovers from many component failures within one Availability Zone. Multi-AZ maintains a primary and standby file server in separate Availability Zones and is designed for higher availability and automatic failover. The extra redundancy has a cost, so choose based on the application's availability and recovery requirements rather than treating Multi-AZ as a generic performance setting. AWS describes the differences in its availability and durability guide.
Both SSD and HDD storage are available. SSD is intended for latency-sensitive or I/O-intensive workloads; HDD can suit file shares with less demanding performance needs. Storage capacity, throughput capacity, and SSD IOPS influence different aspects of performance. The workload's active data set, client network, and I/O pattern matter too, so “high IOPS” or “low latency” is not a guarantee independent of configuration. Review the Windows File Server performance guidance and benchmark with representative files and clients.
Windows File Server also supports optional Microsoft Data Deduplication, which can reduce storage use for datasets with repeated content. Savings depend on the data, and deduplication jobs consume file-server resources; allow for them when setting throughput. Deduplication complements backups but does not replace them. See AWS's storage and data deduplication guidance.
These settings also shape the bill: account for storage, throughput, any SSD IOPS provisioned above the included level, and applicable data transfer. Rates depend on Region and deployment type; the pricing section below points to the current estimate tools.
Backups and recovery
Automatic daily file-system backups are enabled by default, and you can also create backups on demand or manage plans through AWS Backup. Backups are incremental and file-system consistent. Restoring a backup creates a new file system from that recovery point; it does not roll the existing file system backward in place. Backups complement the file system's availability design, and storage is billed separately. See protecting Windows File Server data with backups.
Understanding FSx for Lustre
Linux parallel file access and storage choices
FSx for Lustre is designed for Linux compute workloads that process data in parallel, including HPC simulations, machine-learning jobs, and large-scale analytics. Clients use the Lustre protocol and need a supported Linux distribution and compatible kernel/client combination; it is not a native SMB share for Windows applications. AWS supports mounting from on-premises compute over Direct Connect or Site-to-Site VPN when networking is configured. Check the current Lustre client and kernel compatibility matrix and access guidance before selecting compute images. For a broader workload-planning resource, see our HPC workload profiling guide.
Storage options have different performance and data-protection behavior:
- Scratch file systems are for temporary, shorter-term processing. Data is not replicated, and files on a failed server do not persist. Use scratch only when the workload can tolerate loss and regenerate or reload its working data.
- Persistent SSD or HDD file systems keep data replicated within the file system's Availability Zone. SSD suits low-latency, high-throughput work; HDD can suit larger datasets with less demanding throughput needs. The available combinations depend on the persistent generation and Region.
- Persistent Intelligent-Tiering stores data in access tiers and grows elastically; it is designed for workloads whose full dataset does not need consistent all-flash latency. Frequently accessed data can use an optional SSD read cache. This option replicates data across multiple Availability Zones.
Performance depends on the selected class, capacity, throughput, metadata load, file sizes, access pattern, and client configuration. SSD/HDD throughput is related to provisioned capacity, while Intelligent-Tiering throughput is provisioned separately. Review AWS's current deployment and storage-class options and performance guidance; service availability and supported combinations vary by Region.
S3 integration and data protection
For compatible Lustre file systems, a data repository association links the file system to an S3 bucket. This can make S3 datasets available through a file-system interface and send processed files back to S3. You can import or export changes with data repository tasks and configure automatic import/export policies. These are asynchronous workflows, not a transactional shared namespace: updates can lag, and if the same file changes on both sides, either copy can overwrite the other. Choose a clear writer and coordinate updates. See AWS's documentation for using S3 data repositories, data repository tasks, automatic import, and automatic export.
A linked S3 bucket can serve as the durable data repository for a processing file system, but it does not make every file-system option eligible for FSx backups. AWS supports backups only for standalone persistent Lustre file systems; scratch file systems and file systems linked to an S3 data repository are not backed up by FSx. Plan the source-of-truth, reload, and recovery process accordingly. See FSx for Lustre backup eligibility.
Use cases: Windows File Server vs. Lustre
| Workload requirement | Better starting point | Why |
|---|---|---|
| Windows software expects an SMB share, Windows ACLs, or domain users. | FSx for Windows File Server | It integrates with Microsoft Active Directory and provides SMB file shares with Windows access controls. |
| Shared home directories, departmental folders, or Windows file content systems. | FSx for Windows File Server | These are conventional shared-file workloads; choose HDD or SSD and Single-AZ or Multi-AZ based on access and recovery needs. |
| Linux jobs need many compute clients to read and write a large dataset concurrently. | FSx for Lustre | Lustre is designed for parallel file access and scale-out throughput. |
| A job stages data from S3, processes it through a Linux file-system interface, and returns results to S3. | FSx for Lustre, if the chosen deployment supports the required data-repository features | Linked S3 data repositories and import/export tasks support this workflow, subject to synchronization and recovery constraints. |
| Temporary HPC scratch space whose contents can be regenerated. | FSx for Lustre Scratch | Scratch favors short-lived processing, but data is not replicated and does not survive a file-server failure. |
If the workload needs both Windows shares and high-throughput Linux processing, one service may not meet both needs. Keep each workload on the interface its applications expect, and transfer or stage data between systems deliberately.
Operational trade-offs
Windows File Server fits applications built around SMB, Windows ACLs, and domain users, but it depends on a working Active Directory and the selected file-system deployment. Lustre fits Linux compute that needs parallel access, but clients must use a supported Lustre version and compatible kernel. When a workload spans both environments, plan data movement and ownership explicitly; separate file systems do not provide a shared live view of files.
Choosing the right Amazon FSx solution
1. Start with the client's protocol and operating system
- If an application requires SMB paths, Windows ACLs, or Active Directory identities, start with FSx for Windows File Server.
- If the application runs on supported Linux clients and benefits from parallel file access, evaluate FSx for Lustre.
- If an application requires a protocol or semantics neither service provides, do not select one based only on a throughput or price comparison.
2. Decide how much availability and recovery the data needs
For Windows File Server, select Single-AZ or Multi-AZ based on the application's tolerance for disruption and recovery objectives. For Lustre, decide whether scratch data can be lost, whether persistent storage is needed, whether Intelligent-Tiering fits the access pattern, and whether an S3 repository or FSx backup is the intended recovery path. A linked S3 repository and FSx backups are mutually exclusive for Lustre, so validate the recovery workflow before deployment.
3. Size and price the actual workload
For Windows File Server, estimate storage, throughput, SSD IOPS if needed, deployment type, backup storage, and data transfer. For Lustre, account for SSD/HDD provisioned storage (the throughput tier is tied to capacity), or Intelligent-Tiering data consumption and throughput capacity; include additional metadata IOPS, Intelligent-Tiering cache and request charges, eligible backup storage, and data transfer. Add the cost of surrounding resources such as client compute, the S3 repository, and any directory service. These costs change by Region and configuration; use the current Windows File Server pricing, Lustre pricing, and AWS Pricing Calculator for an estimate instead of carrying over a generic per-GB price.
Benchmark with representative file sizes, concurrency, read/write mix, and recovery procedures. Compare end-to-end job time and data movement, not just a single peak-throughput figure.
4. Check compatibility and operations before migration
- Validate directory connectivity, SMB client support, and Windows ACL behavior for Windows File Server.
- Validate supported Lustre client versions, Linux kernels, VPC network paths, and POSIX UID/GID behavior for Lustre.
- For S3-linked Lustre, define which side owns writes, how changes are synchronized, and how a job recovers after a file-system or client failure.
- Confirm backups, retention, and restore steps with a recovery test before storing data that cannot be regenerated.
FAQs
Can Windows clients mount FSx for Lustre?
FSx for Lustre uses the Lustre protocol and AWS documents its clients for supported Linux systems. It is not a Windows SMB share. For Windows applications, use an SMB-compatible file service such as FSx for Windows File Server.
Does FSx for Lustre automatically synchronize with S3?
You can configure automatic import and export policies on eligible S3 data repository associations. Updates flow asynchronously, and simultaneous edits to the same path in S3 and Lustre can overwrite one another. Choose a clear writer and monitor the synchronization workflow.
Which service costs less?
There is no general winner. Cost depends on Region, deployment, storage class, provisioned capacity and throughput, optional IOPS or cache, backups, data transfer, and how long resources are used. Estimate the complete workload with current AWS pricing.
Can both services be backed up?
Windows File Server supports automatic daily and user-initiated backups. FSx for Lustre backups apply only to standalone persistent file systems; scratch and S3-linked Lustre file systems are ineligible. In both cases, confirm retention, cost, and restore behavior for your workload.