Read Replicas and Multi-AZ

AWS Basics · Databases on AWS – RDS, Aurora, and ElastiCache · Lesson 2 of 5

Two features, two goals

A Read Replica uses asynchronous replication for read scaling or reporting isolation. It has a separate endpoint, the application must direct reads to it, and replication lag creates eventual consistency. Promotion makes it independent; it is not automatic failover by default.

flowchart LR
  APP["Application"] --> P["Primary<br/>AZ 1a, writes"]
  P -- "sync replication" --> SB["Multi-AZ standby<br/>AZ 1b, no traffic"]
  P -- "async replication" --> RR["Read replica<br/>own endpoint"]
  RR --> REP["Reports, dashboards<br/>read-only"]
  SB -. "failover, same DNS name" .-> APP
  %% step APP: The application writes through the primary's endpoint.
  %% step P: The primary handles all writes.
  %% step SB: Every write is committed on the standby too, so no data is lost on failover; the standby serves no reads.
  %% step RR: A read replica receives changes a little later and has its own endpoint.
  %% step REP: Send heavy read queries there; results may be slightly behind the primary.
  %% step SB: If the primary or its AZ fails, RDS flips the DNS name to the standby, usually within one to two minutes.

Side by side

	Read Replica	Multi-AZ instance (standby)
Purpose	Read scaling, reporting, cross-Region copy	High availability
Replication	Asynchronous	Synchronous
Readable	Yes	No
Endpoint	Separate	Same as primary
Failover	Manual promotion	Automatic
Location	Same AZ, other AZ or other Region	Another AZ in the same Region
Max count	Up to 15 for MySQL, MariaDB and PostgreSQL	One standby

A Multi-AZ DB instance deployment serves availability: a synchronous standby in another AZ and automatic failover through the same endpoint. The standby does not offload reads and still incurs instance and storage costs. Failover happens on AZ or hardware failure, OS patching, instance class changes, or a manual reboot with failover.

Multi-AZ DB clusters

RDS also offers Multi-AZ DB clusters for MySQL and PostgreSQL: one writer and two readable standbys in three AZs, with faster failover (typically under 35 seconds) and a reader endpoint. Distinguish them from the traditional standby model. Read the deployment type rather than inferring behavior from “Multi-AZ.”

Using replicas well

Point read-heavy, lag-tolerant queries (reports, search pages) at the replica endpoint; keep read-your-own-write paths on the primary.
Watch ReplicaLag; a large lag means stale reads.
A cross-Region replica gives a warm copy for disaster recovery and lower read latency abroad; promote it if the primary Region fails, then repoint the application.
A replica can itself be Multi-AZ, and you can create a replica of a Multi-AZ primary without affecting it.
Automated backups must be enabled on the primary to create replicas.

Combining both is common: Multi-AZ for availability, one or more replicas for read scaling.

Command	Purpose
`aws rds create-db-instance-read-replica --db-instance-identifier db-prod-ro --source-db-instance-identifier db-prod`	Create a replica
`aws rds promote-read-replica --db-instance-identifier db-prod-ro`	Make a replica standalone
`aws rds modify-db-instance --db-instance-identifier db-prod --multi-az --apply-immediately`	Enable a Multi-AZ standby
`aws rds reboot-db-instance --db-instance-identifier db-prod --force-failover`	Test a failover

Traps: sending reads to a Multi-AZ standby; expecting a read replica to take over automatically; ignoring replica lag for data users just wrote.