aws_fsx_lustre_file_system cost estimation
A high-performance Lustre file system for HPC and ML. Bills per GB of provisioned storage, with throughput coupled to capacity. 1.2 TB at 125 MB/s/TiB is ~$174/month.
An aws_fsx_lustre_file_system provides the massively parallel throughput that HPC, ML training, and analytics workloads need from a shared file system. Cost is driven by provisioned storage capacity, and on the SSD deployment types throughput scales with the per-unit-storage-throughput setting — so capacity and performance are bought together.
A 1.2 TB SSD file system at 125 MB/s/TiB is about $174/month. Scratch file systems are the cheaper, transient tier — fast, no replication, meant for temporary data you can regenerate. Persistent file systems cost more and keep data durable across the workload's life. Choosing scratch for genuinely transient HPC data (intermediate results, staged datasets) is the main cost lever.
Because throughput is tied to provisioned storage on these types, over-provisioning capacity also over-provisions (and over-pays for) throughput. Size the file system to the working set plus headroom, not the worst case.
c3x prices the file system from storage_capacity and per_unit_storage_throughput, so the provisioned cost is visible before you create a multi-terabyte file system.
Terraform example
A minimal but realistic configuration that C3X can estimate.
resource "aws_fsx_lustre_file_system" "scratch" {
storage_capacity = 1200
subnet_ids = [aws_subnet.compute.id]
deployment_type = "SCRATCH_2"
per_unit_storage_throughput = 125
tags = {
Name = "ml-training-scratch"
}
}Pricing dimensions
What you actually pay for when you provision aws_fsx_lustre_file_system.
| Dimension | Unit | What's being charged |
|---|---|---|
| Provisioned storage | per GB-month | Billed for the provisioned capacity. On SSD types, throughput scales with per_unit_storage_throughput, so capacity and performance are bought together. ~$0.145/GB-month (SSD, 125 MB/s/TiB) → 1.2 TB ≈ $174/month |
| Throughput tier | per MB/s/TiB | Higher per-unit throughput tiers (250/500/1000 MB/s/TiB) raise the per-GB rate. Pick the lowest tier that meets the workload's bandwidth need. |
Sample C3X output
A 1.2 TB SCRATCH_2 SSD file system at 125 MB/s/TiB:
aws_fsx_lustre_file_system.scratch
└─ Provisioned storage (SSD, 125 MB/s/TiB) 1200 GB-month $174.00
Monthly $174.00Optimization tips
Common ways to reduce aws_fsx_lustre_file_system cost without changing the workload.
Use SCRATCH for transient data
Significant vs persistent for transient dataScratch file systems are cheaper than persistent and meant for temporary HPC/ML data you can regenerate. Use persistent only for data that must survive — intermediate results and staged datasets belong on scratch.
Size capacity to the working set
Proportional to over-provisioning avoidedBecause throughput scales with storage on SSD types, over-provisioning capacity over-pays for throughput too. Provision the working set plus modest headroom rather than the worst case.
Pick the lowest throughput tier that works
Tier-dependentHigher per-unit throughput tiers raise the per-GB rate. Measure the workload's actual bandwidth need before selecting 250+ MB/s/TiB.
Tier cold data to S3 with data repository links
Workload-dependentFSx for Lustre can link to an S3 bucket as a data repository, so cold input/output data lives in cheap S3 and only hot data occupies the expensive Lustre file system.
FAQ
Why is throughput tied to storage on FSx for Lustre?
On the SSD deployment types, throughput is provisioned as MB/s per TiB of storage, so the two scale together. Adding capacity adds throughput (and cost); the per_unit_storage_throughput tier sets how much bandwidth each TiB delivers.
What's the difference between scratch and persistent cost?
Scratch is cheaper and transient — no replication, meant for temporary data. Persistent costs more and keeps data durable. For HPC intermediate data you can regenerate, scratch is the right, cheaper choice.
How does c3x estimate FSx for Lustre cost?
From storage_capacity and per_unit_storage_throughput, priced at the SSD per-GB rate for that throughput tier, so the provisioned monthly cost is clear before deployment.
Can I reduce cost by offloading to S3?
Yes. Linking the file system to an S3 data repository keeps cold input/output data in S3 and reserves the expensive Lustre capacity for the active working set.
Related resources
Estimate this resource in your own Terraform
Free, open source, no API key. C3X parses your Terraform and shows line-item cost for every resource, including aws_fsx_lustre_file_system.