HAQM FSx for Windows File Server FAQs

HAQM FSx for Windows File Server provides consistent sub-millisecond latencies with SSD storage, and single-digit millisecond latencies with HDD storage for file operations. For all file systems, including those with HDD storage, HAQM FSx provides a fast (in-memory) cache on the file server, so you can get high performance and sub-millisecond latencies for actively accessed data irrespective of storage type.

File systems can deliver up to 12 GB/s and up to 350,000 IOPS for data accessed from persistent disk storage. Depending on your workload’s access patterns, you may observe even higher levels of throughput for frequently-accessed cached data by benefiting from in-memory caching on the Windows file server.

Every HAQM FSx file system has a throughput capacity that you configure when the file system is created and that you can change at any time. This throughput capacity determines the baseline and burst network speeds at which the Windows File Server hosting your file system can serve file data. When creating a file system in the HAQM FSx console, it automatically recommends a throughput capacity for you, or you can select from the available throughput capacity levels.

Each gigabyte of SSD storage includes 3 disk IOPS, and you can provision additional IOPS as-needed. For more information, please read the documentation guide.

You can run up to thousands of HAQM FSx for Windows File Server file systems in your account, with each file system having up to 64 TB of data. To unify your data from multiple file systems into one common folder structure, HAQM FSx supports the use of Microsoft’s Distributed File System (DFS) to organize shares into a single folder structure up to hundreds of PB in size.

Yes, you can increase the storage capacity, and increase or decrease the throughput capacity of your file system – while continuing to use it – at any time by clicking “Update storage" or "Update throughput” in the HAQM FSx Console, or by calling “update-file-system” in the AWS CLI/API and specifying the desired level.

HAQM FSx grows the storage capacity of your existing file system without any downtime impact to your applications and users by adding larger disks, transparently migrating your data in the background from the original disks to the new ones, and then removing the original disks from your file system – the standard process for growing storage on a Windows File Server.

When you request an update of your file system’s storage capacity, the larger, desired storage capacity becomes available within a few minutes. Afterwards, the transparent data migration process running in the background can take between a few hours and a few days depending on the amount of storage being migrated. The background migration process has minimal noticeable impact on your workload performance. You can track the progress of the data migration at any time using the HAQM FSx Console or AWS CLI/API. See the Managing Storage Capacity documentation for more information.

A: HAQM FSx updates the throughput capacity of your file system by switching out the file servers powering your file system to meet the new throughput capacity configuration. This update process typically takes a few minutes to complete. Multi-AZ file systems will experience an automatic failover and failback during this process, and single-AZ file systems will be offline for a brief period of time.

HAQM FSx supports the use of Microsoft’s Distributed File System (DFS) Namespaces to scale out performance across multiple file systems in the same namespace up to tens of GBps and millions of IOPs.

HAQM FSx works with Microsoft Active Directory (AD) to integrate with your existing Windows environments. When creating a file system with HAQM FSx, you join it to your Microsoft AD -- either an AWS Managed Microsoft AD or your self-managed Microsoft AD. Your users can then use their existing AD-based user identities to authenticate themselves and access the HAQM FSx file system, and to control access to individual files and folders.

HAQM FSx provides standard Windows permissions (full support for Windows Access Controls ACLS) for files and folders.

You specify the HAQM Virtual Private Cloud (VPC) in which your file system is made accessible, and you control which resources within the VPC have access to your file system using VPC Security Groups.

You control who can administer your file system and backup resources (create, delete, etc.) using AWS IAM.

Yes. HAQM FSx for Windows File Server always encrypts your file system data and your backups at-rest using keys you manage through AWS Key Management Service (KMS). HAQM FSx encrypts data-in-transit using SMB Kerberos session keys, when you access your file system from clients that support SMB 3.0 (and higher). You can also choose to enforce in-transit encryption on all connections to your file system by limiting access to only those clients that support SMB 3.0 and higher to help meet compliance needs.

A: When creating a file system from the AWS Management Console, file access auditing is turned on by default. If you're migrating existing file data that already has audit controls (SACLs) set up, there's nothing more for you to do to take advantage of file access auditing.

You can turn on files access auditing at any time (during or after creation of a file system) via the AWS Management Console or the HAQM FSx CLI or API, and also change the destination for publishing user access events: logging to CloudWatch Logs or streaming to Kinesis Data Firehose.

You can also set up or change audit controls (i.e., which access types by which users or groups to publish audit events for) at any time for individual files and folders using Windows audit controls via Windows File Explorer or PowerShell. 

Once the events are available in the destination, you have the option to view and search the logs on the CloudWatch Console, query the logs using CloudWatch Logs Insights, archive log data, trigger Lambda functions to take reactive actions (e.g., notify security teams of unauthorized access attempts), or perform post-processing on partner solutions such as Splunk and Datadog.

AWS has the longest-running compliance program in the cloud and is committed to helping customers navigate their requirements. HAQM FSx has been assessed to meet global and industry security standards. It complies with PCI DSS, ISO 9001, 27001, 27017, and 27018), and SOC 1, 2, and 3, in addition to being HIPAA eligible. That makes it easier for you to verify our security and meet your own obligations. For more information and resources, visit our compliance pages. You can also go to the Services in Scope by Compliance Program page to see a full list of services and certifications.

To ensure high availability and durability, HAQM FSx automatically replicates your data within an Availability Zone (AZ) to protect it from component failure, continuously monitors for hardware failures, and automatically replaces infrastructure components in the event of a failure. You can also create a Multi-AZ file system, which provides redundancy across multiple AZs. HAQM FSx also takes highly durable backups (stored in S3) of your file system daily using Windows’s Volume Shadow Copy Service, and allows you to take additional backups at any point.

Single-AZ file systems are composed of a single Windows file server instance and a set of storage volumes within a single Availability Zone (AZ). With Single-AZ file systems, data is automatically replicated to protect it from the failure of a single component in most cases. HAQM FSx continuously monitors for hardware failures, and automatically recovers from failure events by replacing the failed infrastructure component.

Multi-AZ file systems are composed of a high-availability cluster of Windows file servers spread across two AZs (a preferred AZ and a standby AZ), leveraging Windows Server Failover Clustering (WSFC) technology and a set of storage volumes on each of the two AZs. Data is replicated synchronously within each individual AZ and between the two AZs. Relative to Single-AZ deployment, Multi-AZ deployments provide enhanced durability by further replicating data across AZs, and enhanced availability during planned system maintenance and unplanned service disruption by failing over automatically to the standby AZ. This allows you to continue accessing your data, and helps to protect your data against instance failure and AZ disruption.

HAQM FSx automatically performs a failover in the event of a loss of availability to the active file server. This can be caused by a failure in the active Availability Zone, or by a failure of the active file server itself. HAQM FSx will also temporarily fail over to the standby file server during planned maintenance or if throughput scaling has been initiated on the file system.

A: HAQM FSx detects and automatically recovers from failures so that you can resume file system operations as quickly as possible without administrative intervention. When failing over from one file server to another, the new active file server will automatically begin serving all file system reads and write requests. Failovers, as defined by the interval between the detection of the failure on the active and promotion of the other file server to active, typically complete within 30 seconds. Failback will occur once the file server in the preferred subnet is fully recovered (typically under 20 minutes), and also completes within 30 seconds.

Windows clients accessing Multi-AZ file systems automatically fail over and fail back with the file system, meaning that users or applications running on Windows clients automatically benefit from the enhanced availability of Multi-AZ file systems. Linux clients don’t automatically connect to the standby file server upon a failover, and will automatically resume file system operations once failback to the preferred file server is complete.

HAQM FSx performs routine software updates for the Windows Server software it manages. The maintenance window is your opportunity to control what day and time of the week this software patching occurs. Patching occurs infrequently, typically once every several weeks, and should require only a fraction of your 30-minute maintenance window.

Beyond automatically replicating your file system's data to ensure high durability, HAQM FSx provides you with two options to further protect the data stored on your file systems: Windows shadow copies to enable your end-users to easily undo file changes and compare file versions by restoring files to previous versions, and backups to support your backup retention and compliance needs.

HAQM FSx supports file- or folder-level restores to previous versions by supporting Windows shadow copies, which are snapshots of your file system at a point in time. With shadow copies enabled, your end-users can view and restore individual files or folders from a prior snapshot with the click of a button in Windows File Explorer. Storage administrators using HAQM FSx can easily schedule shadow copies to be taken periodically using Windows PowerShell commands.

Creating regular backups for your file system is a best practice that complements the replication that HAQM FSx performs for your file system. Working with HAQM FSx backups is easy, whether it's creating backups, restoring a file system from a backup, or deleting a backup.

HAQM FSx takes daily automatic backups of your file systems, and allows you to take additional backups at any point. HAQM FSx backups are incremental, which means that only the changes after your most recent backup are saved, thus saving on backup storage costs by not duplicating data.

With HAQM FSx, backups are file-system-consistent and highly durable. To ensure file-system-consistency, HAQM FSx uses Windows’s Volume Shadow Copy Service, allowing you to restore to a point in time snapshot of your file system. To ensure high durability, HAQM FSx stores backups in HAQM S3.

The daily backup window is a 30-minute window that you specify when creating a file system. HAQM FSx takes the daily automatic backup of your file system during this window. At some point during the daily backup window, storage I/O might be suspended briefly while the backup process initializes (typically under a few seconds).

The daily backup retention period specified for your file system (7 days by default) determines the number of days your daily automatic backups are kept.

When you delete your file system, all automatic daily backups associated with the file system are deleted. Any user-initiated backups you created will remain.

You first enable HAQM FSx as a protected service in AWS Backup. You can then configure backups of your HAQM FSx resources via the AWS Backup console, API or CLI. You can create both scheduled and on-demand backups of HAQM FSx resources via AWS Backup and restore these backups as new HAQM FSx file systems. HAQM FSx file systems can be added to backup plans in the same way as other AWS resources, either by specifying the ARN or by tagging the HAQM FSx file system for protection in the backup plan. To learn more, visit the AWS Backup documentation.

You can configure your backup plans on AWS Backup to periodically create and copy backups of your HAQM FSx file systems to other AWS Regions, other AWS accounts, or both, with your desired frequency and retention policy. For cross-account backup copies, you use your AWS Organizations management account to designate source and destination accounts.

You can use AWS DataSync to schedule the periodic replication of your HAQM FSx for Windows File Server file system to a second file system. This capability is available for both same-region and cross-region replications. To learn more, see Data Transfer between AWS Storage services.

HAQM FSx provides two types of storage – Hard Disk Drives (HDD) and Solid State Drives (SSD) – to allow you to optimize cost/performance to meet your workload needs. HDD storage is designed for a broad spectrum of workloads, including home directories, user and departmental shares, and content management systems. SSD storage is designed for the highest-performance and most latency-sensitive workloads, including databases, media processing workloads, and data analytics applications.

You can change your file system storage type from HDD to SSD using the AWS Management Console and AWS CLI. Although you cannot change the storage type from SSD to HDD on your existing file system, you can take a backup and restore that backup to a new file system with a different storage type.

Large datasets often have redundant data. For example, with user file shares, multiple users tend to have files that are similar or identical. As another example, with software development shares, most binaries remain largely unchanged from build to build. Data Deduplication is a feature in Windows Server that reduces costs that are associated with redundant and uncompressed data by storing duplicated portions of files only once and compressing the data after deduplication. Learn more by visiting the Using Data Duplication documentation.

The storage savings you can achieve with Data Deduplication depends on the nature of your data set, including how much duplication exists across files. Typical savings average 50-60% for general-purpose file shares, with savings ranging 30-50% for user documents, and 70-80% for software development data sets.

You can enable Data Deduplication on your file system by running a single command (Enable-FSxDedup) on the HAQM FSx remote management CLI via PowerShell. Once enabled, Data Deduplication continually and automatically scans and optimizes your files in the background.

You can enable and configure user storage quotas on your file system to monitor usage and allocate storage costs to individual teams, and to impose restrictions at a user-level in order to prevent any one user from storing a lot of data.

You pay only for the resources you use. You are billed hourly for your file systems, based on their deployment type (Single-AZ or Multi-AZ), storage type (SSD or HDD), storage capacity (priced per GB-month), throughput capacity (priced per MBps-month), and your level of SSD IOPS above the default 3 IOPS that are included for every GB of SSD storage (priced per IOPS-mo). You are billed hourly for your backup storage (priced per GB-month). For pricing information, please visit the HAQM FSx pricing page.

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax. For customers with a Japanese billing address, use of AWS services is subject to Japanese Consumption Tax. Learn more.

Scaling storage capacity and throughput capacity is available at no additional cost. Once storage capacity scaling is complete (typically within 1-2 minutes of you requesting a storage capacity increase), you will be billed for that storage capacity moving forward. Once throughput capacity scaling is complete (i.e., the new throughput capacity is available), you will be billed for the new throughput capacity from that point forward.