An online tax-filing platform is preparing for the final filing day of the tax year. The platform currently handles a baseline load of 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 RPS within a -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.)
- Submit a support ticket to AWS to pre-warm the Application Load Balancer to the expected peak of requests per second prior to the scheduled filing deadline.Answer
- 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
- CRely on the Application Load Balancer's built-in automatic scaling to dynamically partition and provision capacity as traffic increases during the peak filing hours.
- DConfigure 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.
- EMigrate 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 surge in traffic within a -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
Key Concept
Performance and Scalability Optimization under sudden flash traffic and mixed database workloads.