How do I reduce costs for my Amazon FSx for NetApp ONTAP file system?

My Amazon FSx for NetApp ONTAP costs are higher than expected and I want to understand how to reduce them. Or, I want to reduce the FSx service costs by optimizing FSx filesystem usage across SSD storage, capacity pool tiering, provisioned IOPS, throughput, and backup retention.

Akhil Pabba

Published Oct 15, 2026

Last modified Oct 15, 2026

The cost of an Amazon FSx for NetApp ONTAP file system is driven by five independent components: SSD (primary) storage, capacity pool storage, provisioned SSD IOPS, throughput capacity, and backup storage. You are billed for what you provision (SSD storage, IOPS above the included rate, throughput capacity) and for what you consume (capacity pool storage, backup storage). Because each lever is priced separately, you can lower your bill by right-sizing each one against real usage instead of leaving provisioning at its initial, conservative values.

This article walks through five actions, in the order that gives the safest savings:

Tier cold data to the capacity pool (biggest lever, lowest risk)
Right-size SSD storage capacity
Right-size provisioned SSD IOPS
Right-size throughput capacity
Reduce automatic backup retention

Important: SSD IOPS have a floor of 3 IOPS/GiB of SSD storage, so reduce SSD storage before IOPS. After any change to storage, IOPS, or throughput you must wait 6 hours (a cooldown period) before changing any of the three again. Review CloudWatch metrics over a representative window (the peak/busy season, not a quiet week) before reducing anything.

Tier cold data to the capacity pool tier

Every FSx for ONTAP file system has two storage tiers. The SSD (primary) tier is provisioned, high performance storage for the active portion of your data. The capacity pool is a fully elastic, cost optimized tier for infrequently accessed data that grows and shrinks automatically. Capacity pool storage is priced significantly lower per GB than SSD, so moving cold data off SSD is usually the single largest saving with the least risk.

Tiering is controlled per volume by a tiering policy and a cooling period:

Tiering policy	What tiers to the capacity pool
Auto	Both user data and Snapshot data that have been inactive (cold) for the cooling period
Snapshot-only	Only Snapshot data that is cold
All	All user data is marked cold immediately and tiered
None	Nothing tiers; data stays on SSD

The cooling period (tiering minimum cooling days, default 31) sets how long data must be inactive before it's treated as cold. Note ONTAP's tiering thresholds, which are relative to SSD used capacity:
• ≤ 50% SSD used: only All-policy volumes tier.
• > 50% SSD used: Auto and Snapshot-only tier per the cooling-days setting.
• ≥ 90% SSD used: cold data read back is left in the capacity pool (not promoted to SSD).
• ≥ 98% SSD used: all tiering stops.
Action: For volumes with large amounts of infrequently accessed data, set the policy to Auto (or Snapshot-only if you only want to tier snapshots) and tune the cooling period to match your access patterns. As a best practice, keep the SSD tier at ≤ 80% utilization so tiering, throughput scaling, and maintenance work correctly.

For more information, please see Managing storage capacity .

For instructions to modify storage data tiering policies, see How do I use the NetApp ONTAP CLI to modify storage data tiering policies for my FSx for ONTAP volume?

Right-size SSD (primary) storage capacity

Tiering reduces how much data lives on SSD, but you still pay for the SSD capacity you have provisioned. If your provisioned SSD tier is much larger than what you actively use, you may be able to shrink it.

Important: generation matters. Second-generation file systems (SINGLE_AZ_2, MULTI_AZ_2): you can increase or decrease SSD storage capacity. First-generation file systems (SINGLE_AZ_1, MULTI_AZ_1): SSD capacity is increase-only — you cannot decrease it. On first-gen, use the analysis below to right-size volumes and drive tiering, but you cannot reclaim the SSD tier itself. Confirm your file system's DeploymentType in the FSx console before planning a decrease.

Step 2a - Assess utilization in CloudWatch. Look at SSD-tier utilization over a representative window:

StorageCapacityUtilization (Detailed file system metric, StorageTier = SSD), which shows the percent of the SSD tier in use.
StorageCapacity and StorageUsed (file system metrics) - these represent absolute provisioned vs. used storage.

If the sustained maximum is comfortably below your provisioned SSD size (with headroom to stay ≤ 80%), there may be room to reduce. For more information, please see Monitoring with Amazon CloudWatch

Step 2b - Confirm from inside the ONTAP. For an accurate picture of used vs. free space before you resize, run these from the ONTAP CLI:

1
2
3
df -h
volume show -fields size,used,available,percent-used
storage aggregate show-space

Use these outputs to estimate how far the SSD tier can be safely reduced (remember the 80% guideline and leave headroom for growth). ONTAP volumes are thin-provisioned, so shrinking oversized volumes frees space that (on second-gen) lets you decrease the file system's SSD tier.

Step 2c - Decrease (second-gen only). Use the FSx console, the UpdateFileSystem API , or the AWS CLI. Note the constraints: SSD capacity increases must be at least 10% of current capacity, and a 6-hour cooldown applies between any storage/IOPS/throughput change.

For instructions on how to update, please see Updating storage capacity and provisioned IOPS

Right-size provisioned SSD IOPS

For every GiB of SSD storage, FSx automatically includes 3 SSD IOPS at no additional charge, up to a file-system maximum (160,000 SSD IOPS per file system; the ceiling also depends on throughput capacity and HA-pair configuration). SSD IOPS run in one of two modes :

Automatic — FSx maintains exactly 3 IOPS/GiB as storage changes. No extra IOPS charge.
User-provisioned — you set a specific IOPS number. It must be ≥ 3 IOPS per GiB of SSD storage (the minimum floor). Any IOPS you provision above the included 3/GiB rate is billed separately (measured in IOPS-months).

So the classic example holds: a 10,000 GiB file system has a minimum of 30,000 IOPS. You cannot go below the 3×/GiB floor — which is exactly why you reduce SSD storage first (Step 2): a smaller SSD tier lowers the floor.

Action: In CloudWatch, compare your provisioned IOPS against actual demand. Sum the operation-count metrics — DataReadOperations + DataWriteOperations + MetadataOperations (each is a Sum over the period; divide by the period seconds to get ops/sec), or use the console's Total IOPS (operations/sec) view. If you are in User-provisioned mode well above what your workload uses, lower the value toward the 3-IOPS/GiB baseline (or switch to Automatic) to stop paying for unused provisioned IOPS.

For more information about CloudWatch metrics, please see File system metrics .

Right-size throughput capacity

Throughput capacity sets the network and file-server performance of the file system, and you are billed for the throughput capacity you provision, whether or not you use it. You can increase or decrease the throughput capacity at any time.

Review these CloudWatch metrics over your busy period -

NetworkThroughputUtilization (%) — network throughput used as a percentage of the provisioned limit.
FileServerDiskThroughputUtilization (%) — throughput between the file server and the SSD tier as a percentage of the provisioned limit.

If peak utilization sits well below 100% with consistent headroom, step the throughput capacity down to the next tier that still covers your peak. When sizing, provision enough to cover read throughput + 2 times the write throughput for your workload, and keep headroom for spikes. Over-provisioning will cost more and under-provisioning throttles the workload, so base the decision on observed peaks, instead of averages.

For instructions, please see How to modify throughput capacity

Reduce automatic backup retention

By default, Amazon FSx takes one automatic daily backup of your file system's volumes during the backup window you set at creation, and keeps each backup for a retention period (default 30 days, adjustable from 0 to 90 days). Backups are incremental and billed as backup storage, so a shorter retention window means fewer stored backups and lower cost.

Important: Lowering the retention period permanently deletes automatic daily backups that fall outside the new window. Setting retention to 0 disables automatic backups and deletes all existing automatic backups for the file system's volumes. Confirm you no longer need the older backups (and that they are not required for compliance or retention obligations) before you proceed.

Set AutomaticBackupRetentionDays to the smallest value that meets your recovery and compliance requirements, via the FSx console, the UpdateFileSystem API , or the AWS CLI. If you also keep manual or AWS Backup copies, factor those into your recovery plan before trimming automatic retention.

For instructions to update automatic daily backups, please see Updating file systems