Question

Difficulty: MediumPerformance and Scalability Optimization

A biotechnology organization is launching a centralized clinical trial telemetry portal. Every quarter, hundreds of partner laboratories upload trial results simultaneously within a 15-minute window, causing web traffic to instantly spike from 100 requests per second to over 60,000 requests per second. The application layer runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The database backend is a Single-AZ Amazon RDS for PostgreSQL DB instance, where 90% of the operations during the submission window are read-heavy validation queries. Which strategy should a Solutions Architect implement to optimize the performance and scalability of the architecture under this load?

  1. Submit an AWS Support request to pre-warm the Application Load Balancer prior to the upload window. Migrate the database to Amazon Aurora PostgreSQL, and configure Aurora Auto Scaling to dynamically provision Aurora Replicas to handle the read query volume.Answer
  2. B
    Rely on the Application Load Balancer's automatic scaling to adjust to the traffic load. Enable Multi-AZ deployment for the Amazon RDS for PostgreSQL DB instance, and configure the application to direct all validation read queries to the standby replica in the secondary Availability Zone.
  3. C
    Submit an AWS Support request to pre-warm the Application Load Balancer. Implement Amazon ElastiCache for Memcached to cache query results, configuring multi-AZ replication and failover to ensure cached results remain highly available and replicated across zones.
  4. D
    Configure the EC2 Auto Scaling group cooldown period to be shorter than the instance bootstrapping time to accelerate scaling. Modify the Amazon RDS instance to use Provisioned IOPS (SSD) storage to handle the increased read query load during the window.

Answer

Submit an AWS Support request to pre-warm the Application Load Balancer prior to the upload window. Migrate the database to Amazon Aurora PostgreSQL, and configure Aurora Auto Scaling to dynamically provision Aurora Replicas to handle the read query volume.
The correct solution involves requesting AWS Support to pre-warm the Application Load Balancer to accommodate the sudden spike from 100 to 60,000 requests per second, which exceeds the normal dynamic scaling speed of the ALB. To scale the database layer, which is 90% read-heavy, migrating to Amazon Aurora PostgreSQL and configuring Aurora Auto Scaling dynamically provisions read replicas to distribute the read query workload.

Step-by-Step Solution

1
Address the immediate ALB scaling bottleneck.
By pre-warming the ALB, AWS provisions sufficient capacity in advance to handle the massive traffic spike from 100 to 60,000 requests per second, avoiding HTTP 503 errors and dropped requests.
Standard ELB auto-scaling is gradual and cannot scale instantly to a multi-magnitude traffic spike within minutes.
2
Select a database engine that supports horizontal read scaling.
Migrating to Amazon Aurora PostgreSQL allows the addition of up to 15 Aurora Replicas that share the same underlying storage volume.
Single-instance RDS for PostgreSQL or standard RDS Multi-AZ deployments cannot dynamically scale read operations horizontally.
3
Implement dynamic database read scaling.
Aurora Auto Scaling automatically adds and removes replicas based on CPU utilization or connection count targets, scaling the database capacity during peak periods.
This matches the read-heavy nature of the telemetry validation workload (90% reads) and optimizes operational overhead and cost.

Key Concept

Handling massive traffic spikes requires pre-warming the load balancer, while scaling read-heavy database workloads requires horizontal replica scaling instead of relying on passive standby instances.
Rate this question