Question

Difficulty: HardPerformance and Scalability Optimization

An online tax-filing platform is preparing for the final filing day of the tax year. The platform currently handles a baseline load of 2,0002,000 requests per second (RPS) using Amazon ECS tasks on AWS Fargate behind an Application Load Balancer (ALB). The backend database is an Amazon Aurora PostgreSQL DB cluster. Based on historical data, traffic is expected to spike instantaneously to 120,000120,000 RPS within a 22-minute window. During this peak period, users will also run resource-intensive financial reporting dashboards that execute complex analytical queries. Which two actions should the Solutions Architect take to optimize the performance and scalability of this solution? (Select TWO.)

  1. Submit a support ticket to AWS to pre-warm the Application Load Balancer to the expected peak of 120,000120,000 requests per second prior to the scheduled filing deadline.Answer
  2. Configure Amazon Aurora Auto Scaling to dynamically scale reader instances in the cluster and update the reporting application to query the cluster reader endpoint.Answer
  3. C
    Rely on the Application Load Balancer's built-in automatic scaling to dynamically partition and provision capacity as traffic increases during the peak filing hours.
  4. D
    Configure a Multi-AZ deployment for the database cluster and configure the reporting application to direct analytical queries to the passive standby instance in the secondary Availability Zone.
  5. E
    Migrate the backend APIs to AWS Lambda functions and configure them to run with default unreserved concurrency to allow unlimited scaling during the peak hours.

Answer

The correct actions are submitting a support ticket to AWS to pre-warm the Application Load Balancer to the expected peak traffic, and configuring Amazon Aurora Auto Scaling to dynamically provision reader instances while directing reporting queries to the reader endpoint.
The correct architecture requires pre-warming the Application Load Balancer (ALB) because standard load balancer scaling is reactive and cannot keep up with an instantaneous 6,000%6,000\% surge in traffic within a 22-minute window. Pre-warming pre-partitions the ALB's capacity. Additionally, to handle resource-intensive reporting queries without impacting write transactions on the primary DB instance, the reporting queries must be routed to the reader endpoint, backed by Aurora Auto Scaling. This dynamically adds reader instances (Aurora Replicas) as read load increases.

Step-by-Step Solution

1
Identify the scaling limits of the Application Load Balancer (ALB) under flash traffic conditions.
An instantaneous traffic increase from 2,0002,000 RPS to 120,000120,000 RPS (a 6,000%6,000\% increase) will overwhelm the ALB's normal scaling rate, causing dropped requests.
Requesting AWS Support to pre-warm the ALB ensures the load balancer is pre-partitioned with the necessary capacity.
2
Analyze the database read scalability requirement.
The database is receiving heavy write traffic from tax filings, while users are running intensive reporting queries. To prevent performance degradation on the primary database instance, read queries should be routed to the reader endpoint.
By separating read and write workloads, write performance remains unaffected by heavy read traffic.
3
Configure horizontal read scaling.
Enabling Amazon Aurora Auto Scaling dynamically provisions additional Aurora Replicas to handle the read workload on the reader endpoint.
Ensuring low-latency query performance without affecting the primary instance.

Key Concept

Performance and Scalability Optimization under sudden flash traffic and mixed database workloads.
Rate this question