A business application needs to survive a database interruption, and its reporting screens are becoming slow. Enabling “Multi-AZ” sounds like a way to solve both problems. The result depends on the exact Amazon RDS deployment: a standby for availability is not automatically a reader for application queries.

Before changing the architecture, write two separate requirements. How should the application recover when an instance or Availability Zone has a problem? Which queries need more read capacity, and how current must their results be? These questions can lead to different design decisions.

Artwork: original concept illustration contrasting protected database capacity with separate readers; it is not a deployment diagram or a customer performance result.

Start with the exact RDS deployment type

Capture the engine, version, Region, deployment option and endpoints from the actual environment. Avoid using “Multi-AZ” as a complete architecture description in a proposal. AWS distinguishes a Multi-AZ DB instance deployment from a Multi-AZ DB cluster deployment, and their readers behave differently.

For a Multi-AZ DB instance deployment, RDS maintains a synchronous standby in another Availability Zone for availability and failover. That standby does not serve application read traffic. It is therefore not an extra query endpoint for the reporting team.

Understand what a readable cluster changes

A Multi-AZ DB cluster has one writer and two readable instances across three Availability Zones. These reader instances also support failover. This is a different deployment option, not a setting that turns a single standby into a reporting server.

Check engine and regional support, instance choices and application compatibility before proposing it. Reader data can lag behind the writer, so a reader endpoint is not a blanket guarantee of immediately current results. Define what the application should do when a user saves a record and then expects to see that change on the next screen.

Use read replicas for a defined read workload

AWS documents RDS DB instance read replicas separately. Replication is asynchronous, and the application must direct the appropriate reads to the replica. Creating one does not automatically move existing queries away from the source instance.

Reporting, exports and other tolerant workloads may be candidates, subject to engine capabilities and measured behaviour. Do not route every read to a replica without reviewing consistency requirements. A replica that is behind can show an older order status, balance or approval state even while replication is functioning.

ITZ’s software consulting service can help map application requirements to the database design. Discuss availability and read scaling for your application.

Prepare a workload and consistency checklist

  • Identify the slow screens or jobs and the queries they generate.
  • Record response time, concurrency and database load during the affected period.
  • Separate queries requiring fresh transactional state from reports that can tolerate an agreed delay.
  • Document the writer and reader connection paths, credentials and connection-pool behaviour.
  • Set monitoring and an owner for replica lag, failed connections and capacity pressure.

This evidence may reveal a query or indexing problem that should be addressed before adding instances. Test proposed changes against a representative workload. A larger topology can add cost and operating tasks without repairing an inefficient query or an application that still sends everything to the writer.

Test failover as an application event

Availability is more than the database service changing roles. Plan an approved test with a clear maintenance window, a rollback decision and the people responsible for the application. Observe how connections recover, whether requests are retried safely and whether partially completed operations are reconciled.

Record the measured interruption and the business task affected. Do not quote a universal recovery time from the presence of a standby alone. Keep backups and restore testing in the plan: a highly available deployment does not replace the ability to recover a mistaken data change. Our backup restore test checklist provides a separate validation approach.

Make the decision reviewable

The final recommendation should name the exact deployment, explain which requirement it addresses, identify application changes and estimate ongoing cost using the chosen configuration. Include monitoring, testing and ownership rather than only an architecture picture. Review database storage headroom separately so capacity assumptions do not disappear behind the availability discussion.

Request an ITZ database architecture review with your engine, deployment type and the business symptom. Share redacted configuration details through an agreed channel; never include production passwords in an enquiry.

Official AWS documentation checked on 24 October 2026. This guide concerns Amazon RDS deployment options; Amazon Aurora has its own architecture and documentation. Feature availability and suitability must be checked for the selected engine and Region.