A media company's Aurora writer is at high CPU while its readers sit idle. The busy statements are read-only audience reports, and the application sends those reports to the writer endpoint. Where should the reports connect?
Select an answer to reveal the explanation.
Short Explanation
The readers are extra cashiers with the lanes roped off, and every customer is still in the writer's line. You sent read-only reports to the writer endpoint, which always lands on the writer. Point them at the reader endpoint, because a second pool aimed at the writer just makes a longer line.
Full Explanation
An Aurora cluster has a writer endpoint that resolves to the current writer and a reader endpoint that spreads connections across the Aurora replicas. Read-only reporting sent to the writer endpoint consumes the writer's CPU and never reaches the idle readers. Retargeting that workload at the reader endpoint is the change that uses the capacity already running. A second connection pool does not change the endpoint, so both pools still land on the writer. The writer's instance endpoint is that one instance. Aurora does not silently move a connection from the writer instance endpoint onto a reader. A snapshot is a recovery point, not a live SQL endpoint you query in place to shed load. Caveat: the reader endpoint includes the replicas, and a report that cannot tolerate replica lag still belongs on the writer. Operational check: after the connection change, confirm reader CPU rises, writer CPU falls, and the report results stay inside the lag the audience numbers can accept.