Question

Difficulty: Very hardOptimizing Compute and Storage Performance

A digital publishing company operates a real-time news portal on AWS. The web application runs on Amazon EC2 instances within an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The database tier uses an Amazon RDS for PostgreSQL Multi-AZ deployment.

During breaking news events, traffic instantly spikes from 500 requests/sec500\text{ requests/sec} to over 80,000 requests/sec80,000\text{ requests/sec} within 1 minute1\text{ minute}. The following table summarizes the metrics observed during these peak events:

MetricBaseline ValuePeak Traffic Value (Spike)Target Threshold
ALB Request Rate500 requests/sec500\text{ requests/sec}80,000 requests/sec80,000\text{ requests/sec}80,000 requests/sec80,000\text{ requests/sec}
ALB HTTP 502/504 Rate0%0\%24%24\%<0.1%< 0.1\%
EC2 Bootstrapping TimeN/A300 seconds300\text{ seconds}<30 seconds< 30\text{ seconds}
RDS CPU Utilization (Primary)15%15\%100%100\%<70%< 70\%
RDS CPU Utilization (Standby)5%5\%5%5\%N/A
DB Replication Lag0 seconds0\text{ seconds}N/A<5 seconds< 5\text{ seconds}

Which combination of actions should the solutions architect implement to optimize the compute, storage, and database layers to resolve these performance bottlenecks while meeting the target thresholds?

  1. Request AWS Support to pre-warm the ALB for the scheduled flash traffic events. Configure an ASG Warm Pool with warm-started instances to reduce capacity delivery time. Create Amazon RDS PostgreSQL Read Replicas, configure an Application Auto Scaling policy for these replicas, and update the application to route read queries to the replica endpoints.Answer
  2. B
    Request AWS Support to pre-warm the ALB for the scheduled flash traffic events. Configure the ASG to use a step scaling policy based on CPU utilization. Enable read routing to the RDS PostgreSQL Multi-AZ standby instance by modifying the DB connection string to point to the standby's endpoint.
  3. C
    Rely on the ALB's default automatic scaling to adapt to the traffic spike. Configure an ASG Warm Pool with stopped instances to minimize running costs. Create Amazon RDS PostgreSQL Read Replicas, and configure a single DNS CNAME record in Route 53 to load-balance read traffic across the primary and standby DB instances.
  4. D
    Request AWS Support to pre-warm the ALB for the scheduled flash traffic events. Increase the minimum capacity of the ASG permanently to handle the peak request rate. Configure the application to route read queries to the standby DB instance using the RDS cluster endpoint to automatically load-balance database queries.

Answer

The correct solution involves requesting AWS Support to pre-warm the ALB to prevent initial connection drops, using an Auto Scaling Group Warm Pool with warm-started instances to bring initialization times under 30 seconds, and deploying RDS Read Replicas with Auto Scaling while routing read queries to the replica endpoints rather than attempting to query the passive Multi-AZ standby instance.
The correct answer provides a comprehensive optimization plan for all three layers. It addresses the load balancer bottleneck by pre-warming the ALB to handle the massive traffic surge. It resolves the EC2 provisioning lag by utilizing ASG Warm Pools, which keep instances pre-bootstrapped and ready to serve traffic in under 30 seconds. Finally, it addresses the database bottleneck by scaling reads using RDS Read Replicas, correctly identifying that the standard RDS Multi-AZ standby instance is passive and cannot serve read traffic.

Step-by-Step Solution

1
Address load balancer scaling limitations.
Request AWS Support to pre-warm the ALB before scheduled breaking news events.
Standard ALB auto-scaling is reactive and cannot scale fast enough to handle an instantaneous spike of 80,000 requests/sec, causing HTTP 502/504 errors.
2
Optimize compute tier initialization latency.
Implement an ASG Warm Pool with warm-started instances.
This bypasses the 300-second bootstrapping delay, allowing pre-initialized instances to join the active fleet in under 30 seconds during a scale-out event.
3
Resolve database CPU saturation.
Deploy RDS PostgreSQL Read Replicas, configure Application Auto Scaling, and point application read queries to the replica endpoints.
The primary DB instance CPU is saturated by read-heavy reporting queries. Deploying read replicas offloads this traffic. The standby instance in a standard RDS Multi-AZ deployment is strictly passive and cannot serve read traffic.

Key Concept

Optimizing multi-tier architectures for sudden traffic spikes requires proactive load balancer pre-warming, compute initialization acceleration (Warm Pools), and database read scaling via active read replicas instead of passive Multi-AZ standby instances.
Estimated Time:3m 0s
Rate this question