How to Offload Read Traffic Using Aurora Reader Endpoint
Exhibit
Aurora cluster summary: - 1 writer instance: db.r6g.large - 2 reader instances: db.r6g.large - Writer CPU avg: 82% / p95 91% - Reader CPU avg: 18% / p95 26% - Database connections: 480 total, all established to the cluster writer endpoint - Query sample: 72% SELECT, 22% INSERT/UPDATE, 6% administrative queries
Based on the exhibit, an application runs on Amazon Aurora MySQL. The writer instance is frequently near 85% CPU while the reader instance is under 20% CPU. Application traces show that most of the database traffic is read-only SELECT queries, but the code currently sends all queries to the writer endpoint. What should the solutions architect recommend to improve performance with the smallest functional change?
Quick Answer
The answer is to point read-only database traffic to the Aurora reader endpoint while keeping writes on the writer endpoint. This is correct because the Aurora reader endpoint automatically distributes read-only SELECT queries across all available reader instances, offloading the writer instance and reducing its CPU utilization from the observed 85% down to a more balanced load. On the SAA-C03 exam, this scenario tests your understanding of Aurora’s read replica architecture and the critical distinction between the writer endpoint (for writes and read-after-write consistency) and the reader endpoint (for read scaling). A common trap is to suggest adding more reader instances without changing the connection logic, which fails to offload the writer; the smallest functional change is simply modifying the application’s read connection string. Memory tip: think of the reader endpoint as a “load-balancing librarian” that hands out books (reads) to available assistants, leaving the head librarian (writer) free to update the catalog (writes).
⚠ Common exam trap
Watch out — candidates often think increasing instance size (Option A) is the simplest fix, but they overlook the fact that Aurora's architecture is designed to offload reads to reader instances, which is a more cost-effective and scalable solution with minimal code change.
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
✓
Point read-only database traffic to the Aurora reader endpoint and keep writes on the writer endpoint.
The Aurora reader endpoint distributes read-only traffic across all available reader instances, offloading the writer instance and reducing its CPU utilization. Since the application traces show most traffic is read-only SELECT queries, this change requires only modifying the connection string for reads while keeping writes on the writer endpoint, making it the smallest functional change.
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 writer instance size and keep all traffic on the writer endpoint.
Why it's wrong here
A larger writer can postpone saturation, but it wastes available read capacity and does not fix the traffic split problem.
- ✓
Point read-only database traffic to the Aurora reader endpoint and keep writes on the writer endpoint.
Why this is correct
This directly uses the cluster’s read scale-out capability. The reader endpoint distributes read traffic across replicas, reducing load on the writer and increasing read throughput without changing schema or database engine.
- ✗
Convert the cluster to a Multi-AZ RDS PostgreSQL deployment to get automatic failover and better read performance.
Why it's wrong here
This changes both the engine and architecture, and it is not the lowest-impact way to improve read throughput for Aurora MySQL.
- ✗
Enable cross-Region read replicas so SELECT queries are routed to a remote Region for improved performance.
Why it's wrong here
Cross-Region replication helps disaster recovery and regional locality, but it adds latency and operational complexity rather than solving local writer saturation.
Go deeper
Related to this question
About these practice questions
One of 302 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
7 more ways this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An application uses an Amazon Aurora cluster. The workload becomes read-heavy, but the team cannot change the database schema. They need higher read throughput while keeping writes on the primary. What should they do?
easy- ✓ A.Create Aurora read replicas and use the reader endpoint for read traffic
- B.Switch the cluster to a single-AZ Aurora configuration to reduce coordination overhead
- C.Increase DynamoDB capacity units instead of modifying the database layer
- D.Enable CloudFront caching for database queries to serve results from edge locations
Why A: Aurora read replicas are designed to offload read traffic from the primary instance, and the reader endpoint automatically load-balances connections across all replicas. Since the workload is read-heavy and the schema cannot change, adding read replicas directly increases read throughput without modifying the application's database schema. The reader endpoint ensures that read queries are directed to the replicas while writes continue to hit the primary instance.
Variation 2. A web application uses an Amazon Aurora DB cluster. The workload is becoming read-heavy, and the application team wants to increase read throughput without changing the database schema. They can adjust the application to route reads differently. What should they do?
easy- ✓ A.Add Aurora read replicas and route read queries to the cluster reader endpoint
- B.Switch the cluster to Multi-AZ with a longer failover target clock
- C.Move all reads to the writer endpoint to reduce connection overhead
- D.Disable automated backups to reduce storage overhead and speed reads
Why A: Adding Aurora read replicas and routing read queries to the cluster reader endpoint is the correct approach because Aurora replicas share the same underlying storage volume as the primary instance, so they can serve read traffic with minimal replication lag. The reader endpoint automatically load-balances connections across all available replicas, increasing aggregate read throughput without requiring any schema changes.
Variation 3. An application uses Amazon Aurora MySQL. CloudWatch shows the writer instance near 85% CPU while the only reader instance averages 15% CPU. Trace logs show that all SELECT statements still target the writer endpoint. The workload is read-heavy, and the application already tolerates eventual consistency for reads. Which two changes will best increase total read throughput without a schema redesign? Select two.
hard- ✓ A.Point read-only queries to the Aurora reader endpoint instead of the writer endpoint.
- ✓ B.Add one or more additional Aurora Replicas and distribute read traffic across them.
- C.Convert the cluster to a single-AZ RDS MySQL instance to reduce replication overhead.
- D.Replace the writer endpoint with the instance endpoint of the primary node to speed up SELECT queries.
- E.Add Amazon ElastiCache and move all database writes into the cache layer.
Why A: The Aurora reader endpoint is designed to distribute read-only connections across all available Aurora Replicas, offloading SELECT queries from the writer instance. Currently, all SELECT statements target the writer endpoint, causing the writer's CPU to be at 85% while the reader instance is underutilized at 15%. By redirecting read traffic to the reader endpoint, the writer's CPU load decreases, and the existing reader instance can handle more read throughput without any schema changes.
Variation 4. A web application uses an Amazon Aurora DB cluster for a read-heavy workload. The team wants to increase read throughput without changing the database schema or rewriting application data access patterns. Which two changes should they make? Select two.
medium- ✓ A.Add Aurora Replicas to scale out read traffic across multiple database instances.
- ✓ B.Send read queries to the Aurora reader endpoint so they are distributed across the replicas.
- C.Point all queries to the writer endpoint so Aurora can balance reads and writes internally.
- D.Enable Multi-AZ standby for the cluster to increase the number of read-only connections.
- E.Move the database to a single larger instance class instead of adding replicas.
Why A: Adding Aurora Replicas (Option A) directly increases read throughput by distributing read-only queries across multiple database instances, which is ideal for a read-heavy workload. Sending read queries to the Aurora reader endpoint (Option B) ensures that these queries are load-balanced across all available replicas, offloading the writer instance and improving overall performance without requiring schema or application changes.
Variation 5. A web application uses an Amazon Aurora DB cluster for a read-heavy workload. The application team needs higher read throughput but cannot change the database schema. They want to avoid blocking writes and are willing to route read traffic separately. What is the most appropriate architecture change?
medium- ✓ A.Create Aurora read replicas and route SELECT queries to an Aurora reader endpoint.
- B.Scale up the writer instance storage only; read capacity will automatically increase without using a reader endpoint.
- C.Move the Aurora cluster to Multi-AZ deployment mode only; read scaling is handled automatically without replicas.
- D.Replace the cluster with a single RDS instance because it offers consistent performance for both reads and writes.
Why A: Creating Aurora read replicas and routing SELECT queries to the Aurora reader endpoint is the most appropriate architecture change because Aurora's reader endpoint distributes read traffic across up to 15 low-latency read replicas, providing higher aggregate read throughput without blocking writes. This approach requires no schema changes and allows the application to separate read and write traffic, directly addressing the read-heavy workload requirement.
Variation 6. A production application writes to an Amazon Aurora PostgreSQL cluster. Users report that during business-hour reporting runs, write latency increases. The application team wants to keep the writer focused on OLTP writes while still providing low-latency reads for reporting queries. What architectural approach should the solutions architect recommend?
medium- ✓ A.Create Aurora read replicas and direct reporting read-only connections to the cluster reader endpoint.
- B.Resize the writer instance to a larger class so it can handle both writes and reads with fewer slowdowns.
- C.Enable cross-region replication for the entire cluster so reporting always runs in the secondary Region.
- D.Disable read replicas and use caching only in the application layer, keeping all queries connected to the writer endpoint.
Why A: A is correct because creating Aurora read replicas and directing reporting read-only connections to the cluster reader endpoint offloads read traffic from the writer instance. This allows the writer to focus on OLTP writes, while the reader endpoint load-balances read-only queries across replicas, providing low-latency reads for reporting without impacting write performance.
Variation 7. A customer portal uses Amazon Aurora MySQL. The application currently sends all SELECT queries to the writer instance endpoint. During traffic spikes, read latency increases, and the team wants the cluster to survive a writer failover without manual endpoint changes for the application. Which changes should the team make? Select three.
hard- ✓ A.Replace the hard-coded DB instance endpoint with the Aurora reader endpoint for read traffic.
- ✓ B.Add additional Aurora Replicas and spread read queries across them.
- ✓ C.Enable Aurora Auto Scaling for the replicas so the cluster can add readers during demand spikes.
- D.Keep sending all traffic to the writer endpoint because it always has the freshest data.
- E.Replace Aurora with a single larger RDS instance and continue using the same read pattern.
Why A: The Aurora reader endpoint automatically distributes read-only connections across all available Aurora Replicas, including the writer instance if it is configured to accept reads. This eliminates the need for manual endpoint changes during a failover, as the reader endpoint remains constant while the underlying instances change.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.