Submit feedback on
Infrequently Accessed Data Retained on High-Performance FSx File Systems
We've received your feedback.
Thanks for reaching out!
Oops! Something went wrong while submitting the form.
Close
Infrequently Accessed Data Retained on High-Performance FSx File Systems
Amay Chandravanshi
CER:

CER-0328

Service Category
Storage
Cloud Provider
AWS
Service Name
Amazon FSx
Inefficiency Type
Inefficient Configuration
Explanation

Amazon FSx file systems are designed for performance-sensitive workloads such as shared enterprise file systems, high-performance computing, analytics, and machine learning. Storage costs are driven by provisioned capacity (measured in GB-months) and throughput capacity (measured in MBps-months), regardless of how frequently the stored data is actually accessed. When datasets become archival, historical, or reference-only in nature — often after project completion, workload migration, or data lifecycle changes — retaining them on high-performance FSx storage results in sustained premium charges for data that could reside on significantly cheaper alternatives.

The severity of this inefficiency varies by FSx variant. FSx for Windows File Server is most directly exposed because it lacks native automatic tiering to external cold storage tiers — all data remains on provisioned SSD or HDD capacity with no built-in mechanism to move cold data to lower-cost object storage. FSx for NetApp ONTAP, by contrast, offers automatic data tiering to a lower-cost capacity pool tier, but this feature must be properly configured with appropriate tiering policies per volume; if left at default settings or misconfigured, cold data may still occupy expensive SSD storage. FSx for Lustre and FSx for OpenZFS support tiering storage classes that automatically move data between access tiers, but only when this storage class is selected at deployment. In all cases, the waste stems from the same root cause: high-performance storage capacity being consumed by data that no longer requires — or never required — that level of performance.

Relevant Billing Model

Amazon FSx billing is based on provisioned resources, with no minimum fees or setup charges. The primary cost dimensions are:

  • Storage capacity — charged per GB-month of provisioned (or consumed, depending on variant) storage. Pricing varies by file system type, deployment type (Single-AZ vs. Multi-AZ), and storage media (SSD vs. HDD).
  • Throughput capacity — charged per MBps-month of provisioned throughput, which determines network I/O limits, CPU, and memory resources available to the file server.
  • Optional SSD IOPS — charged per IOPS-month for provisioned IOPS above the included baseline (3 IOPS per GB of SSD storage).
  • Backups — charged per GB-month of backup storage consumed.

Critically, storage capacity charges accrue based on what is provisioned, not on how frequently data is read or written. Cold data occupying provisioned FSx capacity incurs the same per-GB-month cost as actively accessed data. For FSx for NetApp ONTAP, a lower-cost capacity pool tier is available for infrequently accessed data, but only when tiering policies are enabled and properly configured at the volume level.

Detection
  • Identify FSx file systems associated with completed projects, retired applications, or workloads that are no longer actively running.
  • Review file system access patterns over a representative period to assess whether stored data is infrequently read or written.
  • Evaluate whether the performance characteristics of the current FSx file system type (SSD latency, high throughput) are still required for the datasets it holds.
  • Assess FSx for NetApp ONTAP volumes to confirm whether tiering policies are configured and whether cold data is being moved to lower-cost storage tiers as expected.
  • Review FSx for Lustre file systems to assess whether tiering or external storage integration options are configured for datasets with declining access frequency.
  • Review FSx for Windows File Server deployments for the presence of archival, historical, or reference-only datasets that could be migrated to lower-cost storage.
  • Confirm whether data lifecycle policies are defined and enforced across the organization to prevent long-term retention of cold data on high-performance file storage.
Remediation
  • For FSx for NetApp ONTAP, enable and configure appropriate volume-level tiering policies to automatically move infrequently accessed data to lower-cost storage tiers, and adjust cooling periods to match workload access patterns.
  • For FSx for Lustre, consider using tiering storage classes for workloads with mixed access patterns, or leverage external storage integration options to release cold file contents and reclaim FSx storage capacity.
  • For FSx for Windows File Server, migrate infrequently accessed or archival data to lower-cost storage services such as S3 using data transfer tools, since this variant does not support native automatic tiering to external storage.
  • Decommission FSx file systems that no longer support active workloads, ensuring data is archived or migrated before deletion.
  • Implement data lifecycle governance policies that require periodic review of FSx storage contents and mandate migration of cold data to appropriate storage tiers.
  • Enable storage efficiency features such as compression and deduplication where available to reduce the effective storage footprint and associated costs for data that must remain on FSx.
Submit Feedback