SAA-C03 Design Resilient Architectures Practice Question

A financial analytics platform runs an Amazon Aurora MySQL cluster with one writer and two readers. During month-end reporting, read traffic spikes and the application sometimes receives TooManyConnections errors on the reader endpoint. The architect wants to absorb bursts without changing application code and must keep failover behaviour intact. Which change meets these requirements?

⚠ Common exam trap

The trap here is treating a load balancer as a connection pooler, when only RDS Proxy multiplexes client connections onto a smaller backend set.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Add an Amazon RDS Proxy in front of the Aurora cluster and point the application at the proxy endpoint

Amazon RDS Proxy sits between the application and Aurora, maintaining a warm pool of database connections that are shared across many client connections. This absorbs connection bursts and prevents TooManyConnections errors without application changes beyond updating the endpoint. Because RDS Proxy is failover-aware, it automatically routes to the new writer during a failover, preserving the resilience behaviour the architect requires.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Increase the aurora_max_connections parameter on the cluster parameter group and reboot the readers
Why it's wrong here
Raising max_connections increases the ceiling but each new connection consumes memory on the DB instance, and a burst can still exhaust the instance. Rebooting readers causes downtime and does not change the fundamental connection-per-client model, so the TooManyConnections errors would recur under load. It also does not improve failover behaviour or absorb spikes efficiently.
✗
Replace the reader endpoint with a Network Load Balancer that distributes TCP connections across the Aurora readers
Why it's wrong here
A Network Load Balancer can distribute TCP connections, but it does not pool or reuse database connections, so each client connection still becomes a separate Aurora connection and the limit is still reached. It also bypasses Aurora's native reader endpoint health checks and failover awareness, which can route traffic to an unavailable reader. This does not meet the resilience requirement.
✓
Add an Amazon RDS Proxy in front of the Aurora cluster and point the application at the proxy endpoint
Why this is correct
RDS Proxy pools and shares database connections, so bursts of application connections are multiplexed onto a smaller set of database connections, eliminating TooManyConnections errors without code changes beyond the endpoint. It preserves Aurora failover by automatically redirecting to the new writer, and it can be associated with read-only endpoints for reader traffic. This directly addresses connection exhaustion while keeping resilience.
✗
Convert the readers to Aurora Replicas in a second Region and use a global database secondary cluster
Why it's wrong here
Aurora Global Database is designed for cross-Region disaster recovery and low-latency reads in remote Regions, not for absorbing connection bursts within the primary Region. The secondary cluster has its own connection limits and would not receive the primary reader traffic without application changes. It adds complexity and cost without solving the connection exhaustion problem.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question