An enterprise SaaS company hosts a high-throughput reporting application. The application'… — AWS Certified Solutions Architect - Professional

An enterprise SaaS company hosts a high-throughput reporting application. The application's web tier runs on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The database tier consists of an Amazon RDS for PostgreSQL DB instance in a Multi-AZ deployment on a $db.m6g.4xlarge$ instance with a $2\text{ TB}$ Provisioned IOPS SSD ( $gp3$ ) storage volume configured at $12,000\text{ IOPS}$ and $500\text{ MB/s}$ throughput. During monthly billing cycles, tenants execute resource-intensive reporting queries, causing primary DB instance CPU utilization to reach $98\%$ and causing write transactions to fail due to lock contention and connection timeouts. The reporting queries require data that is no more than $5\text{ seconds}$ out of date. Additionally, during the first hour of the billing cycle, the application experiences a massive, instantaneous surge in traffic that results in HTTP 503 Service Unavailable errors for initial users. Which combination of actions should a Solutions Architect recommend to optimize performance and resolve these issues?

A
Enable RDS Multi-AZ read routing to send read-only reports to the standby DB instance. Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) before the billing cycle begins.
B
Create an Amazon RDS read replica and direct read-only queries to its endpoint. Rely on the Application Load Balancer's automatic scaling and set the EC2 Auto Scaling group cooldown period to $60\text{ seconds}$ to absorb the traffic spike.
Create an Amazon RDS read replica and configure the reporting application to direct read-only queries to the read replica endpoint. Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) prior to the start of the monthly billing cycle.Answer
D
Modify the application to distribute read-only queries between the primary DB instance and the secondary standby DB instance. Configure the Application Load Balancer with a target tracking policy based on RequestCountPerTarget.

Answer

Create an Amazon RDS read replica and configure the reporting application to direct read-only queries to the read replica endpoint. Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) prior to the start of the monthly billing cycle.

Directing read-only queries to an Amazon RDS read replica offloads compute-heavy workloads from the primary DB instance, resolving the primary CPU exhaustion and preventing write transaction timeouts. The replica lag for RDS PostgreSQL is typically under

1\text{ second}

, which satisfies the consistency constraint of data being no more than

5\text{ seconds}

out of date. Furthermore, pre-warming the Application Load Balancer (ALB) ensures that the load balancer is pre-scaled to handle the instantaneous surge of traffic at the beginning of the billing cycle, preventing initial HTTP 503 errors.

Step-by-Step Solution

Identify the primary database bottleneck and consistency requirements.

The primary RDS DB instance's CPU utilization spikes to

98\%

due to read-heavy reporting queries, but the reports can tolerate data up to

5\text{ seconds}

out of date.

Since the write queries are failing due to resource exhaustion on the primary, read queries must be offloaded to a secondary compute resource that supports asynchronous replication with lag under

5\text{ seconds}

Select the correct RDS read scaling mechanism.

Deploy an Amazon RDS read replica. Verify that it typically operates with sub-second replication lag.

Amazon RDS Multi-AZ standby instances are passive and cannot accept read queries. Horizontal scaling of reads must be achieved using read replicas, not standby instances.

Address the web tier load balancing drop in initial requests.

Identify that the surge is instantaneous (flash traffic) and request ALB pre-warming from AWS Support.

Dynamic auto-scaling policies react to sustained traffic increases and are too slow to scale the ALB immediately, leading to dropped requests at the very start of the traffic spike. Pre-warming prepares the ALB capacity in advance.

Key Concept

Offloading read traffic to RDS Read Replicas for database compute optimization, and pre-warming Application Load Balancers for instantaneous traffic spikes.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics