Question

Difficulty: Very hardOptimizing Compute and Storage Performance

A financial services company runs a high-frequency trading application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The instances process incoming transactions and write detailed raw execution logs to attached 500 GiB Amazon EBS gp3 volumes (with default configurations of 3,000 IOPS and 125 MB/s throughput) before archiving the logs to Amazon S3. Transactional state is maintained in an Amazon Aurora MySQL DB cluster.

During weekly scheduled flash trading events, the company experiences the following performance issues:
- The ALB immediately drops a significant percentage of incoming requests, returning HTTP 503 (Service Unavailable) errors, because traffic surges from 2,000 requests/second to 150,000 requests/second within 30 seconds.
- The EC2 instances experience severe write latency and high disk queue length as the log writing throughput surges to 450 MB/s with 9,500 IOPS during peak trade processing.

Which of the following actions should the Solutions Architect recommend to resolve these performance bottlenecks? (Select TWO.)

  1. Request AWS Support to pre-warm the Application Load Balancer with the expected peak request rate and rate of increase before the scheduled events.Answer
  2. Modify the EBS gp3 volumes to provision 10,000 IOPS and 500 MB/s throughput to accommodate the peak log ingestion rate.Answer
  3. C
    Configure a target tracking scaling policy for the EC2 Auto Scaling group based on the Application Load Balancer's RequestCountPerTarget metric to scale the ALB capacity dynamically ahead of the spike.
  4. D
    Migrate the database to Amazon RDS MySQL with a Multi-AZ deployment and use the standby instance to load balance the read and write workloads.
  5. E
    Reduce the Auto Scaling group's scaling cooldown period to 20 seconds to allow the EC2 instances to launch rapidly and handle the workload.

Answer

To resolve the performance bottlenecks, the Solutions Architect should recommend requesting AWS Support to pre-warm the Application Load Balancer and modifying the EBS gp3 volumes to provision 10,000 IOPS and 500 MB/s throughput.
The correct solution addresses the network bottleneck by pre-warming the ALB to handle the sudden 150,000 requests/second spike, and resolves the storage bottleneck by provisioning sufficient IOPS (10,000) and throughput (500 MB/s) on the EBS gp3 volumes to handle the 9,500 IOPS and 450 MB/s logging workload.

Step-by-Step Solution

1
Analyze the Application Load Balancer HTTP 503 errors caused by the flash traffic spike (2,000 to 150,000 requests/second).
Identify that the ALB cannot scale dynamically fast enough for instantaneous surges, leading to dropped requests.
Establishing that standard ALB auto-scaling is too gradual and requires pre-warming by AWS Support.
2
Analyze the EC2 EBS storage bottleneck during peak log writes (9,500 IOPS and 450 MB/s).
Determine that the default gp3 configurations (3,000 IOPS, 125 MB/s) are throttling the application write throughput.
Determining that configuring the gp3 volumes to provision 10,000 IOPS and 500 MB/s satisfies the performance requirements in a cost-effective manner.
3
Evaluate the proposed DB and Auto Scaling group adjustments.
Eliminate RDS Multi-AZ migration and aggressive cooldown reductions as viable solutions.
Ensuring that the final configuration avoids passive standby architectures and Auto Scaling group thrashing.

Key Concept

Optimizing EBS storage throughput/IOPS and scaling load balancers for rapid traffic spikes
Rate this question