SAA-C03 Design High-Performing Architectures Practice Question

Exhibit

Aurora cluster configuration:
- 1 writer instance
- 1 reader instance
- Application JDBC string: jdbc:mysql://cluster-writer.endpoint.example.com:3306/orders

CloudWatch metrics (peak hour):
- DBWriterCPUUtilization: 84%
- DBReaderCPUUtilization: 17%
- DatabaseConnections: steady
- ReadLatency p95: 38 ms
- WriteLatency p95: 9 ms

Application trace sample:
SELECT order_id, status, total FROM orders WHERE customer_id=? ORDER BY created_at DESC LIMIT 20

Based on the exhibit, an Amazon Aurora MySQL application is read-heavy, but the database writer is nearing CPU limits while the reader instance is mostly idle. The application currently sends all queries to the writer endpoint. Which change should you make first to increase read throughput?

⚠ Common exam trap

Test-takers frequently assume the writer endpoint automatically load-balances reads across all instances, but in Aurora the writer endpoint always points to the primary instance, and only the reader endpoint distributes read traffic.

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

✓

Change the application to send read-only queries to the Aurora reader endpoint.

The Aurora reader endpoint is specifically designed to distribute read-only traffic across all available reader instances, offloading the writer and increasing read throughput. Since the reader instance is idle, directing read queries to the reader endpoint immediately reduces CPU load on the writer without requiring any architectural changes.

Answer analysis

Option-by-option breakdown

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

✗
Keep using the writer endpoint so Aurora can route the reads automatically.
Why it's wrong here
The writer endpoint is a DNS name that always resolves to the current primary instance. It does NOT perform read/write splitting or distribute reads across replicas; any SELECT sent through it continues to consume CPU and connection capacity on the same primary that is already saturated by writes. Since the primary is the bottleneck, keeping reads on the writer endpoint simply leaves the idle reader underutilized and provides zero throughput gain.
✓
Change the application to send read-only queries to the Aurora reader endpoint.
Why this is correct
The reader endpoint is a load-balancing DNS name that distributes each new connection across all available Aurora Replicas in the cluster. By explicitly routing read-only queries to this endpoint, the application offloads its SELECT-heavy workload from the primary to the idle replica, directly reducing CPU strain on the writer and increasing the cluster's aggregate read capacity. This is the intended scaling pattern for Aurora MySQL and resolves the described bottleneck.
✗
Convert the cluster to a single-AZ deployment so network hops are reduced.
Why it's wrong here
Aurora clusters do not operate as a simple single-AZ deployment; the storage layer is replicated across three AZs by default, and the database instances can be spread across AZs for high availability. Moving to a single-AZ configuration would reduce resilience and arguably increase the risk of downtime without addressing the root cause. The reported bottleneck is a query-routing issue, not a network hop issue, so changing AZ placement has no meaningful impact on throughput.
✗
Add an Amazon DynamoDB Accelerator (DAX) cluster in front of Aurora.
Why it's wrong here
Amazon DynamoDB Accelerator (DAX) is an in-memory caching service designed exclusively for Amazon DynamoDB tables. It cannot be placed in front of Aurora MySQL, nor can it intercept, cache, or accelerate SQL queries that are sent to a relational engine. Therefore, adding a DAX cluster would not alter the application's Aurora traffic pattern and offers no relief for the primary instance's read load.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question