Question

Difficulty: HardOptimizing Compute and Storage Performance

An enterprise runs a high-performance compute (HPC) financial simulation application on a fleet of Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The instances process incoming client requests, run resource-intensive simulations, and store large intermediate scratch files locally. The raw historical data models are hosted in an Amazon S3 bucket.

During market opening hours, the incoming request volume spikes instantly by 200×200\times. During these events, the ALB drops connections during the first five minutes of the traffic spike. Concurrently, the compute nodes experience severe write latency and CPU underutilization because the default EBS gp3 volumes (100 GiB100\text{ GiB}) cannot keep up with the I/O throughput required for the intermediate scratch files.

Which two actions should the Solutions Architect take to resolve these bottlenecks? (Select TWO.)

  1. Contact AWS Support to pre-warm the Application Load Balancer with the expected request rate and payload size before the market opens.Answer
  2. Migrate the compute instances to an instance store-enabled family and configure the application to write transient scratch files to the local NVMe storage.Answer
  3. C
    Configure a target tracking scaling policy on the Auto Scaling group using the ALBRequestCountPerTarget metric to dynamically scale the load balancer and backend capacity.
  4. D
    Enable Multi-AZ on an Amazon RDS for PostgreSQL instance and route read queries for the data models to the standby instance endpoint.
  5. E
    Configure the Auto Scaling group scale-out policies with a cooldown period of 10 seconds10\text{ seconds} to rapidly provision new EC2 instances during the traffic spike.

Answer

Contact AWS Support to pre-warm the Application Load Balancer with the expected request rate and payload size before the market opens, and migrate the compute instances to an instance store-enabled family to write transient scratch files to the local NVMe storage.
Pre-warming the Application Load Balancer prepares the load balancer infrastructure to handle the sudden 200×200\times traffic spike without dropping packets or requests. Migrating the instances to an instance store-enabled family provides dedicated local NVMe storage, which delivers the sub-millisecond latency and high IOPS required for the compute fleet's transient scratch files, resolving the storage bottleneck.

Step-by-Step Solution

1
Analyze the load balancer performance during rapid traffic spikes.
Standard Application Load Balancers scale dynamically but reactively. An instantaneous 200×200\times traffic spike will overwhelm the balancer before it can scale, leading to dropped connections.
AWS Support must pre-warm the ALB to handle predictable, sudden flash spikes.
2
Assess the performance characteristics of the local scratch storage.
The EBS gp3 volumes configured with default settings are limited to 3,000 IOPS and 125 MB/s, causing high write latency and CPU underutilization during simulation runs.
Transient scratch space requires high-performance, low-latency disk storage. Moving to instance store-enabled EC2 instances provides local NVMe storage that easily handles these I/O requirements.
3
Evaluate and eliminate incorrect scaling and database options.
Target tracking scaling is too slow for instantaneous spikes. RDS Multi-AZ standbys cannot serve read traffic. Extremely short cooldown periods (e.g., 10 seconds10\text{ seconds}) lead to duplicate scaling actions before instances are fully bootstrapped.
Ensures the solution avoids common architectural misconceptions regarding database replication and Auto Scaling cooldown configurations.

Key Concept

Optimizing compute scaling for flash traffic and utilizing high-performance local instance store for transient write workloads.

Alternative Method

Instead of pre-warming the ALB manually, if the traffic spike is predictable and occurs at a precise time daily, a Scheduled Scaling policy can be configured on the Auto Scaling group to scale out the EC2 instances in advance, though the ALB itself must still be pre-warmed by AWS Support if the spike is extremely large and sudden.
Estimated Time:3m 0s
Rate this question