AWS ParallelCluster pricing: what an HPC cluster costs and how to cut it

AWS ParallelCluster builds high-performance computing (HPC) clusters on AWS, and it has no price of its own. In AWS's words, "you only pay for the AWS resources that are created when you create or update AWS ParallelCluster images and clusters". So AWS ParallelCluster pricing is the price of what a cluster is made of: a head node that never stops, Slurm queues of compute nodes that come and go with the jobs, shared storage such as Amazon FSx for Lustre, logs in Amazon CloudWatch, and the data transfer between them. This article covers what each part is, how it works under the hood, what it bills in the Paris Region (eu-west-3), and the ways AWS documents to pay less. Four priced clusters show what the levers do to whole monthly bills, and the cost section opens with an index of the levers, in the order to work through them.

What AWS ParallelCluster is, and why it has no price of its own

AWS ParallelCluster is a cluster management tool that AWS supports. The user guide says what it does: "It automatically sets up the required compute resources, scheduler, and shared file system." You drive it with a command line interface (pcluster), an API, a web interface (PCUI), a Python library, or as an AWS CloudFormation custom resource, and you describe each cluster in one YAML file: its head node, its queues, its shared storage, its monitoring.

The scheduler is Slurm. The same page notes that "Starting with AWS ParallelCluster version 3.16.0, AWS Batch as a scheduler is no longer supported." Every resource the tool creates is an ordinary AWS resource in your account, billed under its own service: there is no "ParallelCluster" line on the bill. The list of AWS services it uses is long, from Amazon EC2 and Amazon EBS to Amazon DynamoDB and Amazon Route 53, but a few lines carry almost all of the cost:

How an AWS ParallelCluster cluster works, under the hood

AWS describes CloudFormation as "the main service used by AWS ParallelCluster. Each cluster in AWS ParallelCluster is represented as a stack". Creating a cluster creates that stack; deleting the cluster deletes it, with the resources it manages.

Scroll the diagram sideways →

The head node and the login nodes

AWS lists the logs of Slurm's controller, slurmctld, among the head node's, and those of its node daemon, slurmd, among the compute fleet's (Integration with Amazon CloudWatch Logs): it follows that the head node runs the Slurm controller. It "tracks provisioned instances in a DynamoDB table", and by default it also serves files: with SharedStorageType left at Ebs, "the head node will export portions of its root volume as shared directories for compute nodes and login nodes using NFS" (HeadNode section). Two constraints shape its cost. Its instance type must have the compute nodes' architecture, and it cannot change: the update policy reads "If this setting is changed, the update is not allowed." A head node is sized once, for the life of the cluster.

Login nodes, since version 3.7.0, give users a shell without the head node; a pool's Count "Specifies the number of login nodes to keep active" (LoginNodes section). It follows that, like the head node, they run, and bill, all the time.

The Slurm queues: static nodes and dynamic nodes

Each queue has compute resources, each with a MinCount and a MaxCount. The Scheduling section gives the defaults: MinCount "The default is 0", MaxCount "The default is 10". The nodes up to MinCount are static: "At cluster creation time, the head node waits for all the static nodes to be ready before signaling the success of cluster creation." The others are dynamic, and ScaledownIdletime "Defines the amount of time (in minutes) that there's no job and the Slurm node terminates. The default value is 10." The Slurm guide for multiple queue mode draws the line: "Dynamic nodes automatically enter the POWER_DOWN state after ScaledownIdletime. In contrast, static nodes in most cases aren't powered down", and "Backing instances for POWER_DOWN nodes are immediately terminated. The terminate process usually is finished in a few minutes." It follows that static nodes bill every hour the cluster exists, and dynamic nodes from their launch until a few minutes after ScaledownIdletime.

A queue's CapacityType is ONDEMAND by default, SPOT, or CAPACITY_BLOCK; with a Capacity Block, "all the instances part of the Capacity Block reservation are managed as static nodes". Spreading a queue over zones has a price too, in AWS's words: "The use of multiple Availability Zones might cause increases in storage networking latency and added inter-AZ data transfer costs."

Instances for HPC: EFA, the HPC types and Graviton

Tightly coupled jobs, such as MPI simulations, exchange data between nodes all the time. For them, AWS offers the Elastic Fabric Adapter (EFA), which "provides lower and more consistent latency and higher throughput", and EFA, in the EC2 guide's words, "is available as an optional Amazon EC2 networking feature that you can enable on any supported instance at no additional cost". Its traffic "can't cross Availability Zones or VPCs". A queue turns it on with Efa / Enabled, off by default, usually with a cluster placement group.

The HPC instance types (hpc6a, hpc6id, hpc7a, hpc7g, hpc8a) all have EFA and one thread per core, and none of them supports Spot. Two of them run in Paris: the EC2 list of instance types by Region gives "Hpc6id | Hpc7a" for Europe (Paris), and the Paris price list has rows for those two only. Every hpc7a size has the same price, and AWS lists the same 768 GiB and 300 Gbps for each: it follows that a smaller size buys the same memory and network per node for fewer cores.

AWS Graviton instances run the same queues for less per hour when the code builds for arm64: a c7g.16xlarge costs 19.0% less than a c7i.16xlarge of the same 64 vCPU, computed. The same vCPU count is not the same number of cores: AWS's specifications give the c7i.16xlarge 32 cores of two threads each, and the c7g.16xlarge 64 cores of one thread. A code run one process per core, with simultaneous multithreading off, gets twice the cores on the c7g node. Whether it does the same work in the same hours is for a benchmark of the real jobs to say.

Shared storage: EBS, EFS and the FSx file systems

The SharedStorage section mounts Amazon EBS volumes, Amazon Elastic File System (Amazon EFS), Amazon FSx for Lustre, FSx for NetApp ONTAP or FSx for OpenZFS on every node. Storage the cluster creates is "managed": by default it is deleted with the cluster (DeletionPolicy Delete), unless set to Retain, or Snapshot for EBS. External storage, created outside the cluster, is never deleted by it.

Amazon FSx for Lustre is the file system built for HPC. Its default deployment type in ParallelCluster is SCRATCH_2, and the two families bill differently. Scratch file systems "are designed for temporary storage and shorter-term processing of data. Data isn't replicated and doesn't persist if a file server fails". Persistent ones replicate their data, and the same guide tells the storage classes apart: "For SSD and HDD-based file systems, data is automatically replicated within the same Availability Zone in which the file system is located. For Intelligent-Tiering file systems, data is replicated across multiple Availability Zones." SSD and HDD file systems bill by their throughput tier, since, in ParallelCluster's words, "You pay for the amount of throughput that you provision"; Intelligent-Tiering bills its throughput apart. A scratch, SSD or HDD file system can be linked to an S3 bucket, so the data lives in S3 and the file system only while it is needed; "Intelligent-Tiering file systems don't support linking to Amazon S3 data repositories" (Using data repositories with Amazon FSx for Lustre).

Logs and monitoring

Cluster logs stream to CloudWatch Logs by default, with a CloudWatch dashboard and alarms for the head node. The Monitoring section sets RetentionInDays to 180 by default and the log DeletionPolicy to Retain: the logs outlive the cluster. Detailed monitoring of the compute fleet is off by default; "There are added costs when this feature is enabled."

In short: A cluster bills as its parts: a head node and login nodes every hour, compute nodes only while they exist, storage by the GB-month it exists, and logs by the GB, so the settings that decide when each part exists decide the bill.

What AWS ParallelCluster is used for, and how it compares with AWS PCS

ParallelCluster's use is to stand up an HPC cluster with a scheduler users already know: simulations that span many nodes over EFA, parameter sweeps of independent jobs, genomics pipelines, rendering. AWS suggests building on it, for example "a genomics portal that automates an entire DNA sequencing workflow".

AWS also runs Slurm for you. AWS Parallel Computing Service (AWS PCS) "is a managed service that makes it easier to run and scale high performance computing (HPC) workloads ... using Slurm". The difference shows on the bill: with ParallelCluster the head node is an instance you pay for by the hour; with AWS PCS, its FAQs describe "an hourly controller fee based on the size of the managed Slurm controller", a node management fee per managed instance, and EC2 and storage on top. The pages read for this article publish no side-by-side comparison of the two, or with AWS Batch, which ParallelCluster no longer offers as a scheduler.

How AWS ParallelCluster pricing works

Compute: the hours of each node

Every node bills its instance's hourly price for the hours it exists. A head node m7i.xlarge costs $0.2352 per hour, $171.70 a month, computed; one hpc7a.96xlarge left running as a static node costs $6,245.37 a month, computed. The table of instances above lists the others with their monthly amounts.

Savings Plans apply to these hours like any EC2 hours. In Paris, the 1-year No Upfront Compute Savings Plan rate of an hpc7a.96xlarge is $8.0847 per hour, and the EC2 Instance Savings Plan rate $6.7373 per hour, against $8.5553 per hour On-Demand.

Storage: FSx for Lustre, EBS and EFS in Paris

FSx for Lustre bills "the average amount of storage provisioned for your file systems per month, measured in GB-months", with "no minimum fees or set-up charges", "prorated by the second" (FSx for Lustre pricing). The throughput tier is in the price of each GB:

So the same 12,000 GB costs $1,944.00 a month as a scratch file system and $10,128.00 as Persistent 2 at 1,000 MB/s per TiB, computed, if each exists the whole month.

Logs and data transfer

In short: The tool is free; the hours of the head node and of every compute node, the GB-months of every volume and file system, and the GB of logs are what a cluster costs, at the prices of the instance types and storage tiers you choose.

Architecture patterns around AWS ParallelCluster, and what they cost

Four illustrative configurations in Paris, each priced before and after the levers of the next section, line by line from the AWS Price List: a queue whose nodes never stop, a file system kept between campaigns, a queue moved to Graviton, and interruptible jobs moved to Spot. None is a client case; every amount is computed, and each card lists its assumptions and what it leaves out. The EC2 patterns price the instances of a web application the same way.

Pattern 1 of 4 · Illustrative configuration

A simulation cluster that keeps its compute nodes on

A head node and a Slurm queue of 8 hpc7a.96xlarge nodes with EFA, all static (MinCount equal to MaxCount), running all month; then MinCount 0, so the nodes exist only while jobs run and for the default 10 idle minutes after, and a Compute Savings Plan on the head node, the one instance that never stops.

Scroll the diagram sideways →

The static queue ran 5,840 node-hours a month; the dynamic one runs 1,240, 155 hours a node, computed. The 10 idle minutes after each run add up to 40 node-hours, $342.21 a month, 3.2% of the bill with the levers, computed; setting ScaledownIdletime lower would trade them against more node launches.

Before · All nodes static, all month$50,214.46

With the levers · Scaled to zero, head node committed$10,795.20

• Compute$50,134.65 → $10,738.78, too small to draw
• Storage$79.81 → $56.42, too small to draw

Before · All nodes static, all month: compute $50,134.65, storage $79.81, total $50,214.46 a month.

With the levers · Scaled to zero, head node committed: compute $10,738.78, storage $56.42, total $10,795.20 a month.

With the levers: $39,419.26 a month less (78.5% less), computed.

A simulation cluster that keeps its compute nodes on, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
All nodes staticBefore the levers		$50,214.46	—
MinCount 0, nodes scale to zeroLever: Let idle compute nodes scale to zero		$10,836.69	−$39,377.77
1-year Compute Savings Plan, head nodeLever: Commit only to the part that never stops		$10,795.20	−$41.49

USD, before tax. AWS Price List, eu-west-3, offer file published October 23, 2026, fetched October 26, 2026.

Levers

• Let idle compute nodes scale to zero
• Commit only to the part that never stops

The bills line by line, the assumptions and the sources

A simulation cluster that keeps its compute nodes on, before: All nodes static, all month Illustrative

8 static nodes, 730 hours each, used or not.

Line	A month
Compute	$50,134.65
Head node, m7i.xlarge1 instance × 730 h × $0.2352 /h	$171.70
Compute nodes, hpc7a.96xlarge8 instances × 730 h × $8.5553 /h	$49,962.95
Storage	$79.81
Head node root volume (gp3)40 GB × $0.0928 /GB-mo	$3.71
Shared EBS volume, /shared (gp3)500 GB × $0.0928 /GB-mo	$46.40
Their root volumes (gp3)320 GB × $0.0928 /GB-mo	$29.70
A month, computed	$50,214.46

A simulation cluster that keeps its compute nodes on, with the levers: Scaled to zero, head node committed Illustrative

Dynamic nodes, 155 hours each, and the head node on a Savings Plan.

Line	A month
Compute	$10,738.78
Head node, m7i.xlarge, 1-year Compute Savings Plan1 instance × 730 h × $0.17837 /h	$130.21
Compute nodes, hpc7a.96xlarge8 instances × 155 h × $8.5553 /h	$10,608.57
Storage	$56.42
Head node root volume (gp3)40 GB × $0.0928 /GB-mo	$3.71
Shared EBS volume, /shared (gp3)500 GB × $0.0928 /GB-mo	$46.40
Their root volumes (gp3)320 GB × 155 h / 730 h × $0.0928 /GB-mo	$6.31
A month, computed	$10,795.20

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• A head node m7i.xlarge with a 40 GB gp3 root volume, a 500 GB gp3 shared volume, and one compute resource of 8 hpc7a.96xlarge (192 cores each, EFA on, one cluster placement group), each with a 40 GB gp3 root volume; root volume sizes are illustrative (the default comes from the AMI).
• The jobs keep each node busy 150 hours a month, in 30 runs; after each run Slurm waits ScaledownIdletime (default 10 minutes) before it terminates the node, so each dynamic node exists 155 hours a month.
• A dynamic node's root volume is attached at launch, and EC2 deletes a root volume attached at launch when its instance is terminated, unless the AMI or the launch says otherwise (Preserve data when an instance is terminated); so it bills for the hours the node exists.
• The Compute Savings Plan is the 1-year No Upfront rate of the head node's On-Demand SKU, used every hour of the month. It is the Compute plan, not the cheaper EC2 Instance Savings Plan, which commits to one instance family in the Region: a move of the cluster to Graviton (pattern 3) changes the head node's family.

Not counted

• CloudWatch Logs, the DynamoDB table and the Route 53 hosted zone that ParallelCluster creates, and data transfer: small next to the nodes, and the same in both variants.
• Node launch time: a dynamic node bills from its launch, before its first job starts.

Sources

• Scheduling section (AWS ParallelCluster)
• HeadNode section (AWS ParallelCluster)
• Specifications for Amazon EC2 high-performance computing instances
• Amazon EC2 instance types by Region
• Slurm guide for multiple queue mode
• Preserve data when an instance is terminated
• Savings Plans types

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 23, 2026, fetched October 26, 2026. Illustrative configuration, not a client case.

Pattern 2 of 4 · Illustrative configuration

A Lustre file system kept all month for two campaigns

12,000 GB of project data on an FSx for Lustre Persistent 2 file system, kept all month; then the data in Amazon S3 Standard, and a SCRATCH_2 file system of the same size created with the cluster for each of two 120-hour campaigns, and deleted with it.

Scroll the diagram sideways →

The scratch file system exists 240 hours a month instead of 730, and the data that stays between campaigns pays S3's price instead of Lustre's: 72.3% less, computed. The price is that scratch data is not replicated: results go back to S3 before the file system is deleted.

Before · Persistent 2 kept all month$3,348.00

With the levers · Scratch per campaign, data in S3$927.12

• Storage$3,348.00 → $927.12, too small to draw

Before · Persistent 2 kept all month: storage $3,348.00, total $3,348.00 a month.

With the levers · Scratch per campaign, data in S3: storage $927.12, total $927.12 a month.

With the levers: $2,420.88 a month less (72.3% less), computed.

Levers

• Use scratch file systems for short-lived data, and S3 for the rest
• Delete what a deleted cluster leaves behind

The bills line by line, the assumptions and the sources

A Lustre file system kept all month for two campaigns, before: Persistent 2 kept all month Illustrative

One persistent file system, 730 hours.

Line	A month
Storage
FSx for Lustre, Persistent 2 SSD, 250 MB/s per TiB12,000 GB × $0.279 /GB-mo	$3,348.00
A month, computed	$3,348.00

A Lustre file system kept all month for two campaigns, with the levers: Scratch per campaign, data in S3 Illustrative

S3 all month, a scratch file system 240 hours.

Line	A month
Storage	$927.12
Amazon S3 Standard, the project data12,000 GB × $0.024 /GB-mo	$288.00
FSx for Lustre, SCRATCH_2, during the campaigns12,000 GB × 240 h / 730 h × $0.162 /GB-mo	$639.12
A month, computed	$927.12

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 12,000 GB of project data (StorageCapacity 12,000 GiB, a multiple of 2,400 GiB as SCRATCH_2 and PERSISTENT_2 require), read by the jobs during two campaigns of 120 hours each a month. The capacity is billed as 12,000 GB-months, as AWS's FSx for Lustre pricing examples bill the smallest file system's 1,200 as "1,200 GB".
• Before: PERSISTENT_2, SSD, 250 MB/s per TiB, the throughput tier just above scratch's 200 MB/s per TiB baseline; no backups.
• With the levers: the data stays in S3 Standard (first 50 TB tier); a SCRATCH_2 file system linked to the bucket is created for each campaign and deleted after it (DeletionPolicy Delete, the default), so it exists 240 hours a month.
• A scratch file system does not replicate its data: what the jobs write must be exported to S3 before the file system is deleted.

Not counted

• S3 requests made by the imports and exports, and the compute nodes: the same jobs run in both variants.
• Data transfer between the bucket and the file system, in the same Region: no page read for this article prices it.
• The minutes each import takes before a campaign can start.

Sources

• SharedStorage section (AWS ParallelCluster)
• Deployment and storage class options for FSx for Lustre file systems
• Amazon FSx for Lustre pricing

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 11, 2026 and October 15, 2026, fetched October 26, 2026. Illustrative configuration, not a client case.

Pattern 3 of 4 · Illustrative configuration

A throughput queue on x86 or on Graviton

2,000 instance-hours a month of loosely coupled jobs on c7i.16xlarge with an m7i.xlarge head node; then the same hours on c7g.16xlarge (AWS Graviton3) with an m7g.xlarge head node, since the head node must have the queue's architecture.

The bill falls by 19.0% less, computed, for the same instance-hours: the head node moves to Graviton with the queue, since a cluster has one architecture. If the jobs ran slower on Graviton, the hours would grow and eat into it: the benchmark comes first.

Before · x86 (c7i.16xlarge)$6,958.90

With the levers · Graviton (c7g.16xlarge)$5,633.99

• Compute$6,958.90 → $5,633.99, too small to draw

Before · x86 (c7i.16xlarge): compute $6,958.90, total $6,958.90 a month.

With the levers · Graviton (c7g.16xlarge): compute $5,633.99, total $5,633.99 a month.

With the levers: $1,324.91 a month less (19.0% less), computed.

Levers

• Move to Graviton where the code builds for arm64

The bills line by line, the assumptions and the sources

A throughput queue on x86 or on Graviton, before: x86 (c7i.16xlarge) Illustrative

Intel nodes and head node.

Line	A month
Compute	$6,958.90
Head node, m7i.xlarge1 instance × 730 h × $0.2352 /h	$171.70
Compute nodes, c7i.16xlarge10 instances × 200 h × $3.3936 /h	$6,787.20
A month, computed	$6,958.90

A throughput queue on x86 or on Graviton, with the levers: Graviton (c7g.16xlarge) Illustrative

Graviton nodes and head node.

Line	A month
Compute	$5,633.99
Head node, m7g.xlarge1 instance × 730 h × $0.1904 /h	$138.99
Compute nodes, c7g.16xlarge10 instances × 200 h × $2.7475 /h	$5,495.00
A month, computed	$5,633.99

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 10 nodes of 64 vCPU, 200 hours each a month: 2,000 instance-hours of independent jobs (parameter sweeps), with no EFA.
• The comparison is at equal vCPU, not equal cores: a c7i.16xlarge has 32 cores of two threads each, a c7g.16xlarge 64 cores of one thread (AWS's compute optimized specifications). A code run one process per core, with simultaneous multithreading off, gets twice the cores on the c7g node.
• The jobs take the same hours on both: an assumption, not an AWS figure. A benchmark of the real code decides; if it runs slower on Graviton, the hours grow, and if it runs one process per core, they may shrink.
• The code and its libraries build for arm64; the head node and the compute nodes use the ParallelCluster AMI of their architecture.

Not counted

• Root volumes, shared storage and logs: the same in both variants.
• The work of porting and testing the code on arm64.

Sources

• HeadNode section (AWS ParallelCluster)
• Scheduling section (AWS ParallelCluster)
• Specifications for Amazon EC2 compute optimized instances

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 23, 2026, fetched October 26, 2026. Illustrative configuration, not a client case.

Pattern 4 of 4 · Illustrative configuration

Interruptible jobs on a Spot queue

1,000 instance-hours a month of jobs that checkpoint and can restart, on an On-Demand queue of c7i.16xlarge; then the same hours on a queue with CapacityType SPOT and the price-capacity-optimized strategy, the head node kept On-Demand.

The Spot hours would have cost $3,393.60 On-Demand, computed; their Spot price is not in the AWS Price List. HPC instance types cannot join this queue: none of them supports Spot.

Before · On-Demand queue$3,565.30

• Compute$3,565.30, too small to draw

With the levers · Spot queue$171.70 priced lines

+ 1,000 Spot instance-hours, not priced. Not drawn: a bar of the priced lines would show the Spot hours as free.

Before · On-Demand queue: compute $3,565.30, total $3,565.30 a month.

With the levers · Spot queue: compute $171.70, priced lines $171.70 a month, plus 1,000 Spot instance-hours, not priced.

No difference is computed: the Spot hours have no list price (AWS: up to 90% less than On-Demand).

Levers

• Run interruptible jobs on Spot queues

The bills line by line, the assumptions and the sources

Interruptible jobs on a Spot queue, before: On-Demand queue Illustrative

Head node and compute nodes On-Demand.

Line	A month
Compute	$3,565.30
Head node, m7i.xlarge1 instance × 730 h × $0.2352 /h	$171.70
Compute nodes, c7i.16xlarge4 instances × 250 h × $3.3936 /h	$3,393.60
A month, computed	$3,565.30

Interruptible jobs on a Spot queue, with the levers: Spot queue Illustrative

Head node On-Demand, compute nodes on Spot.

Line	A month
Compute	$171.70
Head node, m7i.xlarge1 instance × 730 h × $0.2352 /h	$171.70
Compute nodes, c7i.16xlarge on Spot1,000 instance-hours · On-Demand equivalent, as c7i.16xlarge: $3,393.60, computed	Not priced
Priced lines, a month, computed	$171.70
+ 1,000 Spot instance-hours, not priced (AWS: up to 90% less than On-Demand)

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 4 nodes c7i.16xlarge, 250 hours each a month; the jobs write checkpoints and are requeued when a node is interrupted.
• HPC instance types (hpc6a, hpc6id, hpc7a, hpc7g, hpc8a) do not support Spot: a Spot queue uses other types.
• The head node stays On-Demand: it runs the scheduler and is not interruptible work.

Not counted

• The hours an interrupted job runs again from its last checkpoint.
• Root volumes, shared storage and logs: the same in both variants.

Sources

• Working with Spot Instances (AWS ParallelCluster)
• Specifications for Amazon EC2 high-performance computing instances

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 23, 2026, fetched October 26, 2026. Illustrative configuration, not a client case.

How to reduce AWS ParallelCluster costs

Each lever below comes from AWS documentation, the last one from the Well-Architected Framework; their order is this article's: see what each cluster bills, remove what outlives its use, reshape the compute and the storage around the jobs, keep the traffic in one zone, commit only where the usage is steady, and look again:

1. Lever 01,SeeSee what each cluster billsAlways, and first
2. Lever 02,TrimDelete what a deleted cluster leaves behindAfter every deleted cluster
3. Lever 03,TrimSet a retention on the cluster's logsEvery cluster that streams logs
4. Lever 04,ReshapeLet idle compute nodes scale to zeroQueues that wait between jobs
5. Lever 05,ReshapeSize the head node and the login nodes for their jobBefore the cluster is created
6. Lever 06,ReshapeKeep HPC instances for tightly coupled jobsChoosing a queue's instance type
7. Lever 07,ReshapeMove to Graviton where the code builds for arm64Code that builds and runs on arm64
8. Lever 08,ReshapeRun interruptible jobs on Spot queuesJobs that checkpoint and can restart
9. Lever 09,ReshapeUse scratch file systems for short-lived data, and S3 for the restData read during campaigns
10. Lever 10,ReshapeProvision Lustre throughput for what the jobs readPersistent file systems
11. Lever 11,RouteKeep a cluster in one Availability ZoneQueues over several zones
12. Lever 12,CommitCommit only to the part that never stopsOnce the rest is done
13. Lever 13,ReviewReview on a cadenceQuarterly to yearly, by share of the bill

In short: Scale the compute to the jobs first, keep storage only as long as the data needs it, choose Graviton or Spot where the jobs allow, and commit last, to the head node and whatever else truly never stops.

FAQ

How much does AWS ParallelCluster cost?

Nothing for the tool: you pay for the resources it creates. In Paris, a cluster's floor is its head node, $171.70 a month for an m7i.xlarge, computed, plus its volumes; the compute nodes, the shared storage and the logs come on top (How AWS ParallelCluster pricing works).

How do I make an AWS ParallelCluster queue scale to zero?

Leave MinCount at 0, its default: the queue then has only dynamic nodes, launched for jobs and terminated after ScaledownIdletime, 10 minutes by default (Let idle compute nodes scale to zero).

Can AWS ParallelCluster use Spot Instances?

Yes, per queue, with CapacityType SPOT, for jobs that can be interrupted. HPC instance types do not support Spot, so a Spot queue uses other types (Run interruptible jobs on Spot queues).

FSx for Lustre scratch or persistent?

Scratch for data the jobs need for a campaign and can rebuild from S3; persistent for data that must survive a file server failure or stays in use for months. In Paris, scratch is $0.162 per GB-month, Persistent 2 from $0.184 per GB-month (Storage in Paris).

AWS ParallelCluster or AWS PCS?

Both run Slurm. With AWS ParallelCluster you run the head node yourself and pay for it as an instance; AWS PCS manages the Slurm controller for an hourly fee and charges per managed node. AWS publishes no side-by-side comparison on the pages read for this article (What AWS ParallelCluster is used for).