Choosing the Right Azure Virtual Machine for Ansys CFX

If you are moving Ansys CFX turbomachinery simulation software to the cloud, the first question is not whether Azure can run your computational fluid dynamics (CFD) workloads, but it is which Virtual Machine (VM) delivers the best balance of performance and cost. Azure offers multiple AMD EPYC-based HPC VMs, each optimized differently for compute, memory bandwidth, and price. As a result, the largest VM or the lowest hourly-cost option is not necessarily the most economical choice once the cost of completing a simulation is considered.

Ultimately, two metrics matter most: the time to complete a simulation and the cost to run the simulation. To evaluate both, we benchmarked a CFX airfoil case at 10M, 50M, and 100M mesh nodes across Azure HBv5, HBv4, HX, and Fams_v7 VMs. We then validated the optimal HBv5 tuning approach using the TUDA transonic compressor benchmark from TU Darmstadt, a widely recognized open benchmark for turbomachinery CFD. This allowed us to assess whether the observed performance benefits extend beyond a single airfoil test case to a fundamentally different CFD workload.

Key findings include:

• The latest generation HBv5 VM is 2-3x faster than a 176-core node on real meshes, and on any 50M mesh nodes and up it is highly cost effective.
• On small meshes the economics flip: a 176-core HBv4 delivers the lowest cost per solve.
• Despite its low hourly cost, Fams_v7 is the most expensive per simulation on large meshes.
• The TUDA compressor study confirms that the performance benefits seen in the airfoil benchmarks also apply to larger turbomachinery workloads, while smaller models require more careful MPI rank tuning to achieve optimal results. The practical answer to "which VM should I choose?" depends on mesh size and how you run. This guide gives you the crossover points to make that decision with confidence.

Benchmark overview

The benchmark used an external-aerodynamics airfoil model at 10M, 50M, and 100M mesh nodes. All simulations were performed in single precision using the CPU-based CFX solver. The study evaluated 168 VM, mesh, and rank-count configurations across four Azure VM families and included 254 solver runs, retaining the best result for each configuration.

Performance was measured using CFD Solver wall-clock time rather than total workflow runtime. This distinction matters because preprocessing, partitioning, storage, and workflow orchestration overheads vary by environment. Solver wall-clock time isolates the computational workload and provides the clearest view of how each VM family executes and scales CFX.

There is also a practical CFX-specific reason to focus on the solver timer. CFX output can report timing for both partitioning and solving, and partitioning is often less sensitive to core count. If users measure the partitioner, scaling may appear artificially flat. The 50M and 100M cases required large partitioning due to 64-bit indexing, while the 10M case used 32-bit indexing.

 

Table 1. AMD EPYC-based Azure VM families evaluated in the CFX benchmark.

Note: HBv4 and HX share the identical 9V33X CPU, so on compute they are near interchangeable. The primary difference is memory capacity, not speed.

Performance comparison

The performance story is best seen in the chart below. HBv5 delivered the shortest solver runtime across all three mesh sizes, and its advantage widened as the workload grew. On the 100M-cell model, HBv5 completed the solve in roughly one-third of the time required by HBv4 or HX.

 

 

Figure 1. Best solver wall-clock time by VM family and mesh size. Lower is faster.

Three observations stand out:

• HBv5 wins every mesh, and its lead widens with size: it is about 2x faster than a 176-core node at 10M, and about 2.9x faster at 100M.
• HBv4 and HX produced similar solver performance, consistent with their shared AMD EPYC 9V33X processor generation.
• Fams_v7 showed strong low-rank performance, but it caps at 80 cores and ends up about 7x slower than HBv5 on the 100M mesh.

 

Why cost-per-simulation matters

Raw speed and sticker price both mislead in the cloud, because you rent the whole VM by the hour regardless of how many cores a job uses. The metric that governs your bill is cost per completed simulation.

Cost per run = solver wall-clock seconds / 3600 x VM hourly rate (Linux, South Central US.) This ties speed and price together, and it is the metric a cloud-adoption business case should be built on.

Table 2. Azure retail list prices used in the benchmark calculations: Linux, South Central US.

Table 3. Cost per solve using PAYG pricing and best solver wall-clock time.

 

 

Figure 2. Cost to solve the 100M-cell benchmark once.

The cost analysis reveals an important shift as model sizes increase. For the smallest 10M mesh case, HBv4 delivers the lowest cost per simulation, despite HBv5 achieving the fastest runtime. However, as workloads grow to 50M and 100M mesh nodes, HBv5 emerges as both the fastest and most cost-effective platform, with its performance advantage more than offsetting the higher hourly VM rate.

 

In contrast, Fams_v7 illustrates the danger of evaluating cloud resources based solely on hourly pricing. While it offers one of the lowest hourly costs, its longer runtimes make it the most expensive option on a per-simulation basis for larger CFD workloads. For organizations running CFX regularly, Reserved Instances can further improve the economics, reducing infrastructure costs by roughly 50% while preserving the same performance characteristics.

How CFX scales on Azure HBv5

HBv5 keeps winning as meshes grow because it provides scaling headroom. On the 100M mesh, HBv5 goes from 550 seconds at 16 ranks to 42 seconds at 368 ranks, a 13.2x speed-up, and still gains from higher rank counts at the top of its range.

 

 

Figure 3. HBv5 scaling for the 100M-cell CFX airfoil benchmark.

Fams_v7 can be attractive at very low rank counts, but its scaling is constrained by its 80-core configuration. HBv4 and HX scale to 176 cores before approaching a plateau. HBv5 continues extracting value up to 368 ranks, which is why its advantage grows as models become larger.

Transonic compressor validation on HBv5

The TUDA transonic compressor benchmark is selected because it tests the same HBv5 tuning approach on a different physics, i.e., a turbomachinery workload, not just the original airfoil case. The result is consistent: spreading ranks one-per-CCD-first across the 48 CCDs, combined with MPI pinning, helps heavier cases to continue scaling as more of the node is used.

 

 

 

Figure 4. TUDA transonic compressor scaling on HBv5 with CCD-spread + MPI pinning. Lower solver wall-clock time is better.

This case is a 43M mesh node model and improves from 218 seconds at 48 ranks to 57 seconds at 368 ranks, a 3.8x speed-up, showing that large turbomachinery models have more parallel work available per rank and can keep scaling further up the CCD ladder.

 

 

Figure 5. Radial Compressor 20M scaling on HBv5 using CCD-spread MPI rank placement.

The Radial Compressor 20M benchmark shows the other side of the sizing rule. Solver wall-clock time decreases from 1,173 seconds at 48 ranks to 331 seconds at 368 ranks, a 3.5× reduction in turnaround time, but most of the benefit is captured before the full-node configuration. Above roughly 150–250 ranks the scaling efficiency tapers, because the case is smaller per rank and communication/startup overheads become more visible. This makes the radial-compressor case a useful example: HBv5 still delivers the fastest turnaround, but smaller turbomachinery models should not automatically use every core if cost-per-solve is the goal.

 

Choosing the right Azure VM for your CFX workload

The practical rule is to match the VM to the workload rather than to the price tag. For production meshes of roughly 50M mesh nodes and above, HBv5 is the preferred starting point because it offers the strongest combination of turnaround time and cost per completed simulation. For smaller or high-volume short runs around 10M mesh nodes, HBv4 can provide a better cost-per-solve profile.

HX should be selected over HBv4 when the additional memory footprint is required, not because compute performance is expected to differ materially. Fams_v7 can be useful for development, sanity checks, or occasional small runs, but it should not be the default production-throughput VM for larger CFX workloads. Users should also validate MPI choice, use large partitioning when required, measure solver time rather than partitioning time, and avoid over-provisioning ranks on small meshes

 

Practical tuning notes for CFX on Azure VMs

• Validate MPI choice. MPI performance varied across the Azure VM families tested, with HBv5, HBv4, and Fams_v7 favoring one configuration and HX another. Validate MPI options for your workload and VM configuration.
• Partition big meshes with -part-large. The 50M and 100M meshes need 64-bit integer indexing, while the 10M mesh runs 32-bit.
• Measure the solver wall-clock, not the partitioner. CFX output can report total wall-clock time twice: first for partitioning, then for the solver. If scaling looks flat as ranks increase, you may be timing the partitioner.
• Do not over-provision ranks on small meshes. Tiny cases can hit communication overhead before they use every core.

Key takeaways for Azure cloud adoption

• HBv5 is the preferred platform for production-scale CFX workloads, delivering both the fastest runtimes and the lowest cost per solve on larger meshes.
• HBv4 remains attractive for smaller workloads where minimizing cost per simulation is more important than minimizing runtime.
• Cloud sizing decisions should be based on cost per simulation rather than hourly VM pricing.

Taken together, Azure gives CFX users a practical cloud-sizing framework: select the VM based on mesh size, solver scalability, and cost per completed simulation.

 

Learn More:

Learn more about Ansys CFX capabilities

Request a Microsoft Azure Free Trial