Amazon FSx for OpenZFS FAQs

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.

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.

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 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.