SAP-C02 Practice Question 34: Tightly Coupled HPC Network
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 4 · question 4 of 10
An aerospace firm runs computational fluid dynamics simulations on 200 EC2 instances using Open MPI. The job is tightly coupled: every solver iteration ends with a collective operation in which all ranks exchange data, so the slowest link sets the pace for the whole cluster.
The fleet currently runs on c5n.18xlarge instances distributed across three Availability Zones in a spread placement group, a layout the team chose to protect the run from a single-AZ failure. Profiling shows the job spends 60 percent of its wall-clock time inside MPI communication calls, and a full simulation takes nine hours. The engineers have confirmed the code is not I/O bound and that each rank's working set fits comfortably in memory. They want the communication time cut as far as the platform allows; the run is checkpointed and can simply be restarted if infrastructure fails.
What should the solutions architect recommend?
Show answer and explanation
Answer:
An Elastic Fabric Adapter is the network device AWS provides for exactly this workload. EFA gives lower and more consistent latency and higher throughput than the TCP transport normally used in cloud HPC, because MPI talks to the Libfabric API which bypasses the operating system kernel and drives the EFA device directly, using the Scalable Reliable Datagram protocol. Open MPI 4.1 and later is supported. The cluster placement group is the other half: it packs the instances close together in one Availability Zone for the lowest inter-node latency. Giving up the multi-AZ spread is the correct trade here, because the stem says the run is checkpointed and restartable; the resilience the spread bought was never needed.
Option A changes the placement strategy but not the transport. A partition placement group is designed to isolate groups of instances from correlated hardware failure, which deliberately spreads them apart; ENA is ordinary IP networking and is already in use on c5n, so collective latency is unchanged.
Option C is the trap. EFA traffic cannot cross Availability Zones (only the ordinary IP traffic from the interface's ENA device remains routable), so attaching EFAs to a fleet spread over three AZs means the accelerated path is unusable between them, and a spread placement group is the opposite of what a latency-bound collective wants.
Option D attacks a bottleneck the engineers already excluded. They confirmed the job is not I/O bound and that the working set fits in memory, so more RAM and more EBS throughput leave the 60 percent spent in MPI communication untouched.
Reference: Elastic Fabric Adapter for AI/ML and HPC workloads on Amazon EC2