SAP-C02 Question 453
Select 2A company is running a tightly coupled HPC (High-Performance Computing) application that requires low-latency communication between EC2 instances. The workload experiences fluctuating demand, and the architecture must ensure fault tolerance while maintaining high performance. Which combination of solutions should the Solutions Architect implement to meet these requirements?
- A
Use a cluster placement group for EC2 instances.
- B
Use an auto-scaling group with EC2 instances spread across multiple Availability Zones.
- C
Deploy EC2 instances with Elastic Fabric Adapter (EFA) enabled.
- D
Use EC2 Spot Instances to reduce cost.
- E
Deploy the EC2 instances in a spread placement group.
Show answer and explanation
Correct answers: A, C
Explanation
For tightly coupled HPC applications, low-latency and high-bandwidth communication between EC2 instances are critical. Cluster placement groups ensure all instances are launched within a single logical segment of the network, reducing latency. Additionally, enabling Elastic Fabric Adapter (EFA) improves network performance for HPC workloads by providing enhanced communication capabilities. While fault tolerance and cost optimization are important, they must not compromise the low-latency requirements of the application.
- A. Correct.
Cluster placement groups ensure low-latency, high-bandwidth networking between instances, which is crucial for tightly coupled HPC applications.
- B. Incorrect.
While using an auto-scaling group across multiple Availability Zones provides fault tolerance, it introduces latency, which is unsuitable for tightly coupled HPC workloads requiring low-latency communication.
- C. Correct.
Elastic Fabric Adapter (EFA) improves performance for tightly coupled HPC workloads by enabling low-latency, high-throughput networking.
- D. Incorrect.
Spot Instances can reduce costs but are not ideal for tightly coupled HPC workloads due to potential interruptions and the requirement for consistent performance.
- E. Incorrect.
Spread placement groups are designed to reduce the impact of hardware failures by spreading instances across hardware. However, they do not optimize for low-latency communication.