A library catalog points read-only reports at a hostname the team reserved for the standby of a Multi-AZ RDS DB instance. Those connections never get a database session. Where should the reports read?
Select an answer to reveal the explanation.
Short Explanation
The spare generator in the shed does not run the lights while the main generator is up. On a Multi-AZ DB instance the standby does not serve reads, so your reports need a read replica. Pointing them at a standby that has no reader endpoint never opens a session.
Full Explanation
In a Multi-AZ DB instance deployment, RDS keeps a synchronous standby in another Availability Zone and promotes it only during failover. That standby has no connection endpoint and does not accept the reporting sessions, which is why the reserved hostname never opens. A read replica is a separate asynchronous copy with its own endpoint. Point the reports there and leave writes on the primary. A read-only database user on the primary still consumes the writer. There is no switch that turns the standby of a Multi-AZ DB instance into a reader. Restoring a snapshot onto the standby is not a reporting path, and it is not how the standby is maintained. Caveat: this limit is specific to a Multi-AZ DB instance. A Multi-AZ DB cluster is a different deployment and does expose readable standbys. Replica reads can lag the primary, so a report that must see its own latest commit still belongs on the writer. Operational check: the reporting connection string should be the replica endpoint, replica CPU should rise when reports run, and nothing should be listening on a standby address.