A bank's RDS for PostgreSQL instance is near its CPU limit, and Performance Insights shows the time going to read-only reporting queries. Writes are light. The standby in the Multi-AZ pair does not serve those reads. What should be added?
Select an answer to reveal the explanation.
Short Explanation
The standby is a spare engine, not a second reading room. You are burning the writer's CPU on reports, and a Multi-AZ standby will not answer those queries. Add a read replica and aim the reporting at it, because a larger spare still does not serve reads.
Full Explanation
A Multi-AZ deployment for RDS for PostgreSQL keeps a synchronous standby for failover. That standby does not accept client connections, so the read-only reporting queries stay on the writer and drive its CPU up. A read replica is a separate copy with its own endpoint that does accept those reads. Pointing the reporting queries at the replica endpoint takes that work off the writer while the light writes stay on the primary. A larger Multi-AZ standby is still a standby. Making it larger does not make it serve the reporting queries. A standard Multi-AZ DB instance does not offer a second writer in the pair, so both nodes cannot accept the reports. An extra backup window creates recovery points. It does not give the reports a query endpoint, and the reports cannot run against snapshot storage as if it were the live database. Caveat: a replica can lag the writer, so a report that must see its own latest write still belongs on the primary. Operational check: after the reporting connection string changes, confirm replica CPU rises, primary CPU falls, and replica lag stays inside what the report can tolerate.