Amazon FSx for OpenZFS FAQs

Amazon FSx for OpenZFS is a fully managed file storage service that lets you launch, run, and scale fully managed file systems built on the open-source OpenZFS file system. FSx for OpenZFS makes it easy to migrate your on-premises file servers without changing your applications or how you manage data, and to build new high-performance, data-intensive applications on the cloud.

Amazon FSx for OpenZFS provides fully managed, highly reliable, and easy-to-use file storage that you can access over the industry-standard Network File System (NFS) protocol from virtually any client or workstation running in AWS or on premises. It gives you a rich set of capabilities for managing and working with your data, such as snapshots, data cloning, and compression. Powered by AWS Graviton processors, along with the latest AWS disk and networking technologies, FSx for OpenZFS delivers over 1 million IOPs, with latencies as low as a few hundred microseconds for your high-performance workloads.

Use FSx for OpenZFS to migrate your on-premises data stored in ZFS or other Linux-based file servers to AWS. By providing the same data management capabilities and performance as on-premises NFS or other Linux-based file servers, FSx for OpenZFS lets you move your data without having to modify your existing code or how you manage your data.

If you’re building a new application on AWS, FSx for OpenZFS provides rich capabilities to make it easier to develop, test, and run cloud-native applications. And with support for throughput scaling, FSx for OpenZFS makes it easy to scale your file system along with growing application demands and datasets.

Amazon FSx for OpenZFS is designed to support a wide range of Linux, Windows, and macOS workloads, including big data and analytics, code and artifact repositories, DevOps solutions, web content management, front-end electronic design automation (EDA), genomics research, and media processing. With FSx for OpenZFS, you can deliver the low latency and performance needed for the most demanding applications and workloads.

Amazon FSx for OpenZFS is accessible from Amazon Elastic Compute Cloud (EC2), Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS), Amazon WorkSpaces, Amazon AppStream 2.0, and VMware Cloud on AWS. You can secure and protect your data with Amazon Virtual Private Cloud (VPC) and AWS Key Management Service (AWS KMS). You can monitor storage and performance metrics using Amazon CloudWatch, monitor and secure API calls using AWS CloudTrail and AWS Identity and Access Management (IAM), and manage file systems using AWS CloudFormation.

To get started, create an Amazon FSx for OpenZFS file system using the AWS Management Console, AWS Command Line Interface (AWS CLI), or Amazon FSx API. While creating a file system, you specify the deployment type (Single-AZ or Multi-AZ), storage capacity, throughput capacity, and optionally specify the level of disk IOPS. Within minutes, your file system is available, and you can access it from Linux, Windows, or macOS clients with the NFS protocol (v3, v4, v4.1, v4. 2) FSx for OpenZFS presents data to your users and applications as a local directory or drive, and it provides concurrent access for up to thousands of clients.

A file system is the primary resource in Amazon FSx. You specify the SSD storage capacity, throughput capacity, and IOPS capacity for your file system, and choose an AWS VPC in which your file system is created.

You can access your data from Linux, Windows, or macOS clients running on Amazon EC2, Amazon ECS, Amazon EKS, VMware Cloud on AWS, Amazon WorkSpaces, and Amazon AppStream 2.0.

From a Linux instance, you can access your file data using the standard Linux mount command and the domain name system (DNS) name associated with the volume. From a Windows instance, use Windows Powershell to map a drive letter (for example, Z:) to a file share in your file system with the NFS client. From a macOS instance, use the “Connect to Server” feature to connect to a DNS name associated with your file system. See the Amazon FSx documentation for example mount commands. Once your file share is mounted from any client, you can work with the files and directories in your file system just like you would with a local file system.

Amazon FSx for OpenZFS provides access to shared file storage over the latest versions of the NFS protocol (v3, v4, v4.1, v4.2).

You can access your Amazon FSx for OpenZFS file system from your on-premises environment via AWS Direct Connect or VPN, or use standard copy tools, such as rsync or Robocopy, to copy data from on premises to FSx for OpenZFS. You can also use AWS Snowball to migrate your data to AWS without using Direct Connect or VPN.

Refer to Choosing an Amazon FSx file system page for more details on the different Amazon FSx file storage offerings.

Refer to the Regional Products and Services page for details of Amazon FSx for OpenZFS service availability by Region.

We recommend Multi-AZ highly available (HA) file systems for most production workloads for the high availability and durability model it provides. You should use a Multi-AZ HA file system to ensure continued availability and durability across events such as hardware failures, file system maintenance, and AZ disruption.

Use Single-AZ (HA) for workloads that require consistent single-AZ latencies (e.g., certain EDA and HPC workloads) and as a cost-effective solution for workloads that do not require the high levels of durability that Multi-AZ (HA) provides (e.g., workloads that have replication and failover built in to the application layer and analytics workloads that can rehydrate or regenerate the data.

Use Single-AZ (non-HA) file systems for testing and development, i.e., non-production workloads that do not require high availability or durability and can tolerate downtimes, typically up to 30 minutes, caused by recoverable hardware failures and planned maintenance events.

A: FSx for OpenZFS provides fully managed SSD storage with consistent, latencies as low as a few hundred microseconds. Leveraging caching capabilities embedded in OpenZFS, FSx for OpenZFS file systems deliver even higher performance and lower latencies for frequently accessed data.

FSx for OpenZFS file systems can deliver over 1 million IOPs and 21 GB/s throughput when accessing data cached on the file server, and to hundreds of thousands of IOPS and 10 GB/s throughput when accessing data in SSD storage. With multiple parallel connections per client (via NFS n-connect), you can drive up to the maximum throughput and IOPS levels for your file system from a single client.

When creating a file system, you specify its throughput capacity. Each gigabyte of storage includes three disk IOPS, and you can provision additional disk IOPS as needed. You can scale up or down throughput capacity at any time using the AWS Management Console, AWS CLI, or the Amazon FSx API to meet your changing application needs. Visit the File system performance page for more information

You can provision up to a maximum of 512 TiBs on a single file system. You can easily mount multiple file systems concurrently to provide PB-scale storage for your applications.

By default, volumes can grow up to the available capacity on your file system. You have the option to set a quota for a volume to limit how large the volume can grow. You also have the option to set a reservation for a volume to set aside a minimum amount of storage capacity for that volume. Without a reservation, volumes are thin-provisioned, meaning that they consume storage capacity only for the data stored in them. You can change these settings at any time.

The Amazon FSx Intelligent-Tiering storage class combines the familiarity of network attached storage (NAS) with storage that is fully elastic and that optimizes costs by tiering data automatically. It is currently available on Amazon FSx for OpenZFS file systems.

You should use Intelligent-Tiering to simplify storage management and reduce costs. Its elasticity means you no longer need to manage storage capacity or worry about accommodating unpredictable data sets or running out of space. Its automatic cost optimization with tiering across storage tiers provides up to 85% lower costs than the Amazon FSx solid state drive (SSD) storage class, and up to 20% lower costs compared to traditional on-premises hard disk drive (HDD) deployments.

When creating a file system using the Amazon FSx console, API, or AWS Command Line Interface (AWS CLI), specify the Intelligent-Tiering class. When creating the file system or at any point afterwards, you can also create an optional SSD-based read cache to optimize reads of frequently accessed data.

Use the Amazon FSx for OpenZFS Intelligent-Tiering storage class for most of your NAS data sets. Use the SSD storage class only for data sets that require the performance of all-flash storage across all data (such as chip design workloads, databases, and user shares for data scientists).

The Amazon Intelligent-Tiering storage class is designed to meet the performance needs of a broad spectrum of file workloads. It delivers up to 20 Gigabytes per second of throughput and 400,000 IOPS on OpenZFS. Data in the SSD read cache has sub-millisecond time-to-first-byte latencies, and all other data has time-to-first-byte latencies in the range of tens of milliseconds. Typical file workloads tend to be read-heavy and actively work with only a small portion of the overall data set at any given time, meaning that Amazon FSx for OpenZFS Intelligent-Tiering storage class’s hybrid SSD model provides storage that performs at SSD levels for most workloads while delivering up to 85% cost savings relative to an all-SSD deployment.

By default, Amazon FSx automatically selects an SSD read cache size based on the throughput level you choose for your file system, or you can choose a smaller or larger cache and scale it up or down at any time based on your workload needs. You can change the size of your file system’s SSD read cache with the AWS CLI, AWS SDK, or in the Amazon FSx console. Amazon FSx publishes a cache hit ratio metric (the percentage of reads that are served from the cache) to help determine whether your cache is sized appropriately, which you can see in your file system’s “Monitoring” tab in the Amazon FSx console, or with Amazon CloudWatch. For most workloads, a cache hit ratio of 80% provides the right balance of performance and cost optimization.

Yes. The Amazon FSx Intelligent-Tiering storage class provides an SLA of 99.99%.

For file systems using the Amazon FSx Intelligent-Tiering storage class, Amazon FSx stores all of your data redundantly across multiple Availability Zones (AZs), providing built-in resilience against widespread disaster.

Yes, you can make a backup of your file system using Intelligent-Tiering storage with the Amazon FSx console, API, or AWS CLI. Backing up an Amazon FSx file system creates a separate copy of your file data, which you can use later to restore to one or multiple new file systems. Amazon FSx backups are crash-consistent (allowing you to restore to a point-in-time view of your file system), highly durable (stored in Amazon S3 and designed for 11 nines of durability), and incremental (meaning that each backup adds only the changes since your previous backup, thus saving on backup storage costs by not duplicating data). By default, Amazon FSx initiates a daily automatic backup of your file system during a backup window that you specify. You can create additional backups at any time using the Amazon FSx console, AWS CLI, or API, or create your own automatic backup schedule using AWS Backup.

You can restore from a backup by creating a new file system with the “restore from backup” option. When you do so, you can access all of your data within minutes while the restore completes in the background. Your file system transparently retrieves data from the backup as you access it, so you don’t have to wait for the restore to complete before using the file system.

As with Amazon S3 Intelligent-Tiering, the Amazon FSx Intelligent-Tiering storage class automatically tiers data based on last access time, automatically optimizing costs for less active data. Data accessed in the last 30 days is stored in the Frequent Access tier. Data that hasn’t been accessed in 30 days automatically moves to the Infrequent Access tier, and costs less than data in the Frequent Access tier. Data that hasn’t been accessed in 90 days automatically moves to the Archive tier, and costs less than data in the Infrequent Access tier. When you access data in the Infrequent Access or Archive tiers, the data automatically moves back to the Frequent Access tier. All access to non-cached data has the same performance characteristics, independent of the data’s tier, and there are no additional IOPS, retrieval, or transition costs beyond your normal read/write operation costs.

In addition to representing data in a traditional file-directory structure, FSx for OpenZFS supports the use of volumes within a file system to further organize your data. Each file system contains one or more volumes, which are isolated data containers for directories and files. You can create and manage individual volumes using the AWS Management Console, AWS CLI, or the Amazon FSx API, and clients access volumes by mounting them from Linux, macOS, or Windows as a network location. Individual volumes can be configured independently, meaning you can set up features such as thin provisioning or compression at the volume level.

By default, volumes can grow up to the available capacity on your file system. You have the option to set a quota for a volume to limit how large the volume can grow. You have the option to set a reservation for a volume to set aside a minimum amount of storage capacity for that volume. Without a reservation, volumes are thin-provisioned, meaning that they consume storage capacity only for the data stored in them. You can change these settings at any time.

FSx for OpenZFS offers a rich set of ZFS-powered capabilities for working with data, including point-in-time snapshots, in-place data cloning, and on-demand data replication across file systems. With FSx for OpenZFS, you can create snapshots of your volumes at any time, making it easy to retain, manage, and restore historical versions of your databases or applications. Data cloning enables makes it easy for you to test multiple features and changes in parallel without interrupting your existing users or applications, and without needing to duplicate your data. On-demand data replication across file systems provides a simple and resilient way to synchronize data for disaster recovery, read replicas, and test and development workflows, without the extra work of establishing connectivity between your file systems or detecting and handling network interruptions.

As an example, if you are running a database workload and would like to test a database operation prior to applying it in production environment, you can test the operation by creating a clone of your database, running the operation against the clone volume to validate that it works as expected. Once you are done with your test, you can copy your clone volume to a full-copy volume to retain the results for long-term or production use.

FSx for OpenZFS supports a rich set of storage efficiency features including Zstandard and LZ4 compression to reduce the storage capacity your data consumes, volume reservations and volume quotas to control the amount of space used by individual volumes, and user quotas to control the usage of individual end-users. These features help you reduce or manage the storage footprint in your file system and backup storage.

Enabling compression may reduce file system performance for write-heavy workloads as data is compressed as it is being written to disk. However, for read-heavy workloads, compression can significantly improve the overall throughput performance of your file system as it reduces the amount of data sent between these disks and the storage server. See the Amazon FSx for OpenZFS Performance documentation for more details. 

Amazon FSx is a fully managed service, so all of the file storage infrastructure is managed for you. When you use Amazon FSx, you avoid the complexity of deploying and maintaining complex file system infrastructure. FSx for OpenZFS offers all of the power of ZFS, without the complexity often found with managing ZFS file systems

To create, view, and delete file systems, volumes, and backups, you can use the AWS Management Console, the AWS CLI, and the Amazon FSx API. We also offer support for advanced ZFS capabilities natively in the FSx console and API, meaning that you don’t need to be an expert in ZFS in order to take advantage of features like ZFS snapshots and cloning.

With Multi-AZ (HA) and Single-AZ (HA) file systems, Amazon FSx deploys a high-availability (HA) pair of file servers with automatic failover and failback to ensure high availability. With Multi-AZ (HA) file systems, Amazon FSx deploys this pair of file servers across two AWS Availability Zones (AZs) and automatically replicates your data across these two AZs to ensure high durability and deploys a high-availability (HA) pair of file servers across two AZs with automatic failover and failback to ensure high availability and durability even in the event of an AZ-wide disruption. Additionally, Amazon FSx continuously monitors for hardware failures, and automatically replaces infrastructure components in the event of a failure. File systems automatically fail over and back as needed (typically within 60 seconds), and clients automatically fail over and back with the file system.

With Single-AZ (non-HA) file systems, Amazon FSx resumes availability across failure events by continuously monitoring for hardware failures and automatically replacing infrastructure components in the event of a failure, typically within 30 minutes.

Amazon FSx also takes highly durable backups (stored in S3) of your file system daily, and allows you to take additional backups at any point.

A: Yes. The Amazon FSx SLA provides for a service credit if a customer's monthly uptime percentage is below our service commitment in any billing cycle.

To protect against end users or applications accidentally deleting or unintentionally modifying files in your volumes, you can take snapshots (point-in-time images of your volumes, stored within your file system) to allow end users or application administrators to easily undo file changes and compare file versions. End users and application administrators can view snapshots in the “.zfs/snapshot” directory at the root of a volume, and can access individual files and folders in those snapshots. You can manage your FSx for OpenZFS snapshots using the AWS Management Console, AWS CLI, or Amazon FSx API.

FSx for OpenZFS also offers file system backups that are designed to support archival, data retention, and compliance needs. Backups are a secondary, offline, highly durable copy of a file system stored in Amazon S3. Backups are point-in-time consistent (representing a consistent view of your entire file data set as it looked at a given time), incremental (you pay only for the changes since the last backup for a given backup), easy to manage (via the AWS Management Console, AWS CLI, or Amazon FSx API), and quick to create and restore (with an RTO of 5-10 minutes).

Daily automatic backups are enabled by default, and you can update the retention policy at any time with just a few clicks in the Amazon FSx Console. FSx for OpenZFS also provides the ability to copy file system backups to other AWS Regions to meet cross-Region disaster recovery or business continuity objectives.

When you create a Multi-AZ (HA) or Single-AZ (HA) file system, Amazon FSx automatically provisions two individual file servers: . For Multi-AZ (HA) file systems, one of these is a “preferred” server in your preferred AZ, and the other a “standby” server in your standby AZ, each with its own set of storage volumes. Only one of these file servers is actively serving data at any time (usually the preferred file server), but both maintain persistent and identical copies of your data. For Single-AZ (HA) file systems, both servers are in the same AZ. Only one of these file servers is actively serving data at any time, but both are connected to the same set of storage volumes, which themselves replicate data for high durability.

Amazon FSx continuously monitors the health of your file servers to quickly detect any issues. If the preferred file server becomes unavailable for any reason (e.g., due to an isolated hardware failure, a planned maintenance event, or, in the case of Multi-AZ file systems, an AZ-wide interruption), the service will automatically fail over to the standby file server so you can resume file system operations without any loss of availability. Amazon FSx will map the file system’s network address to the newly active standby file server, so your Linux- and Windows-based applications can continue accessing data – uninterrupted – from the same network location. Your file system will also automatically fail back once the preferred file server is restored to a healthy state. These failover and failback events are transparent to your users and applications: your file system will continue to serve NFS traffic from the same network address, allowing NFS clients to continue accessing your data without manual intervention.

Amazon FSx automatically performs a failover on a Multi-AZ (HA) or Single-AZ (HA) file system in the event of a loss of availability to the active file server for any reason, including a hardware failure, a loss of connectivity, or, in the case of Multi-AZ file systems, an AZ-wide disruption. Amazon FSx will also temporarily fail over to the standby file server during planned maintenance during a maintenance window or if you change your file system’s throughput capacity.

Yes. FSx for OpenZFS automatically encrypts data at rest and in transit. Your file system data and backups are always encrypted at rest using keys you manage through AWS KMS. You can use service-owned keys or your own customer-managed keys. Amazon FSx automatically encrypts data in transit when it is accessed from Amazon EC2 instances that support encryption in transit (supported Amazon EC2 client instances).

You configure your file system to be associated with an Amazon VPC and VPC Security Groups, and only Amazon EC2 instances within that VPC (or a peered VPC) and that match the Security Group rules can access your file system. You control who can administer your file systems, volumes, and backups (for example, create, update, and delete) using AWS IAM. Additionally, you control which users and groups have access to which files and directories on your volumes using POSIX permissions.

Yes. You can access file systems from another VPC (including a VPC in another Region) using AWS Transit Gateway or VPC Peering, and you can access file systems from on premises using AWS Direct Connect or VPN.

You can monitor and secure API calls using AWS CloudTrail and AWS IAM and detect and flag suspicious API usage patterns using Amazon GuardDuty.

You pay per GB per month for the data you store on Amazon FSx Intelligent-Tiering storage class, with the price dependent on the tier the data is stored in, and you pay per GB per month for your provisioned SSD read cache. When you write data, you pay per write operation, and when you read data that is not in the SSD read cache, you pay per read operation. As with other Amazon FSx file systems, you pay per MBps per month of throughput capacity that you provision for your file servers.

You are billed for file systems based on storage capacity provisioned (per GB-month), throughput provisioned (per MBps-month), and optional additional SSD IOPS provisioned (per IOP-month). You are also billed for backups based on storage used (per GB-month), and for data transferred (per GB) across Availability Zones, across AWS Regions, and to your on-premises environment. While pricing is quoted on a monthly basis, your usage is prorated by the second and you are billed for your average usage over a month.

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.