Inactive FSx File System

There is no stop or pause option, so a file system keeps its full cost until it is deleted. File systems are commonly left behind after a file server migration cutover, a finished HPC or analytics project, a proof of concept, or the retirement of the application that mounted them.

Unlike Amazon EFS, which bills mainly for the data stored, an idle FSx file system with provisioned SSD storage and high throughput capacity can cost as much on a quiet day as on a busy one. Deleting it also needs care: FSx for Windows File Server takes a final backup by default when a file system is deleted, and that backup is not subject to the retention policy, so it keeps billing until someone deletes it manually.

Storage capacity

Billed per GB-month of provisioned SSD or HDD capacity for most FSx deployment types, independent of activity

Throughput capacity

Billed per MBps-month of provisioned throughput whether or not clients generate traffic

Provisioned SSD IOPS

Billed per IOPS-month above the included baseline where user-provisioned IOPS are configured

Backups

Billed per GB-month; final and user-initiated backups persist after the file system is deleted

• For each file system, sum the CloudWatch metrics DataReadBytes, DataWriteBytes and MetadataOperations (AWS/FSx namespace, FileSystemId dimension) over 30 or more days and flag those at or near zero
• Check ClientConnections where it is published (FSx for Lustre, and FSx for Windows file systems with at least 32 MBps throughput capacity) for sustained zero values
• Cross-check the file system's DNS name, SVM endpoints or mount targets against application configuration, Active Directory group policies and EC2 fstab entries to confirm nothing still references it
• Review tags, creation date and owner, and look for file systems tied to completed migrations, closed projects or deleted environments

• Confirm with the owner that the data is no longer needed, or archive it to Amazon S3 or another lower-cost store before removal
• Delete the file system with DeleteFileSystem; for ONTAP, delete its volumes and storage virtual machines first, and for Lustre, unmount it from all clients first
• Decide explicitly on the final backup: skip it with SkipFinalBackup where it is not required, or record an expiry for it, since final and user-initiated backups continue to bill after deletion
• If the file system is still needed occasionally, reduce throughput capacity to the lowest level that meets its needs, because storage capacity on most FSx types cannot be reduced in place
• Tag FSx file systems with owner and expiry at creation and alert when client I/O stays at zero

• Amazon FSx for Windows File Server Pricingaws.amazon.com
• DeleteFileSystem - Amazon FSx API Referencedocs.aws.amazon.com
• Monitoring with Amazon CloudWatch - FSx for Windows File Serverdocs.aws.amazon.com
• Amazon FSx for Lustre metrics and dimensionsdocs.aws.amazon.com
• COST04-BP01 Track resources over their lifetimedocs.aws.amazon.com