RDS, Read Replicas and Multi-AZ

By the end of this lesson you will be able to

• Explain what Amazon RDS manages for you and what stays your job, name its engines, and say why you cannot SSH into it.
• Choose an instance class and a storage type, find the endpoint, and set up storage auto scaling with a sensible maximum threshold.
• Explain how read replicas work (asynchronous, eventually consistent, own endpoints, up to 15), what they cost inside and across Regions, and how to promote one.
• Diagnose the “I edited my post but still see the old one” problem as replica lag and fix it.
• Describe a Multi-AZ DB instance (synchronous standby, one DNS name, automatic failover) and a Multi-AZ DB cluster (one writer, two readable standbys), and convert Single-AZ to Multi-AZ.
• Design cross-Region disaster recovery for RDS, and pick the right answer among read replica, Multi-AZ instance, Multi-AZ cluster and cross-Region replica in any exam question.

#Amazon RDS: a database you do not have to babysit

#Why a managed database

A relational database (an RDBMS) keeps data in tables of rows and columns, joins them with keys, answers SQL queries and protects every transaction with the ACID guarantees. You can install one yourself on an EC2 instance. Then you also own everything around it: the operating system, patches, backups, replication, failover, monitoring, disk growth. That work never ends, and one mistake can lose data.

Amazon RDS (Relational Database Service) runs the database engine for you. You choose an engine, a size and a few settings; AWS runs the servers.

#The engines

RDS runs six engines:

Amazon Aurora also lives in the RDS console, but it is AWS’s own cloud-native engine, compatible with MySQL and PostgreSQL, with a different storage design. It has its own lesson (7.3). The owner’s notes list five engines plus Aurora; Db2 is the newer sixth.

#No SSH

RDS is a managed service: AWS owns the host. You connect to the database port (5432 for PostgreSQL, 3306 for MySQL and MariaDB, 1521 for Oracle, 1433 for SQL Server, 50000 for Db2) with a database client. You cannot SSH into the server, see its file system, install agents or patch the OS yourself. That is what makes the patching, backups and failover safe for AWS to automate.

If a legacy application needs OS-level access, custom OS patches or a third-party agent on the database host, standard RDS is the wrong answer. The right answers are RDS Custom (Oracle and SQL Server only, lesson 7.2) or running the database on EC2 yourself.

#Instance classes, storage and the endpoint

Instance classes decide CPU and memory, with the same families you met for EC2 (lesson 4.1), prefixed with db.:

• Burstable (db.t4g, db.t3): small and cheap, for development and light load.
• General purpose (db.m7g, db.m6i…): balanced CPU and memory.
• Memory optimized (db.r7g, db.x2iedn…): large caches for busy databases.

Changing the class is vertical scaling: the instance restarts, so a Single-AZ database is down for a few minutes. With Multi-AZ, the change is applied to the standby first and the downtime shrinks to one failover (you will see this below).

Storage is EBS underneath (lesson 5.2), and you pick the type:

Most engines allow up to 64 TiB per instance (SQL Server 16 TiB).

Every DB instance gets an endpoint: a DNS name such as mydb.c9akciq32xyz.us-east-1.rds.amazonaws.com plus a port. Applications connect to that name, never to an IP address, because RDS moves the name to another machine during failover. Remember this: the endpoint is what makes Multi-AZ failover invisible to the application, and a promoted read replica keeps its own endpoint, which is why promoting one forces a connection-string change.

#Scaling RDS in three directions

Use vertical scaling when the database itself is short of CPU or memory, and replicas when the load is mostly reads (reports, analytics, product pages).

#Storage auto scaling

With storage auto scaling on, RDS watches free space and grows the volume for you, online. RDS starts a storage increase when all three conditions hold:

1. Free space is 10% or less of the allocated storage.
2. That low-space condition has lasted at least 5 minutes.
3. The previous storage change has finished optimising, and fewer than 4 storage changes have happened in the last 24 hours.

It adds the largest of: 10 GiB, 10% of the current allocation, or the growth it predicts for the next 7 hours from the last hour of the FreeStorageSpace metric.

You must set a maximum storage threshold (--max-allocated-storage): the ceiling auto scaling may reach. It has to be at least 10% above the current size, and AWS recommends at least 26% above, so you get the “approaching the maximum” event before you hit it. Other facts:

• It works for every RDS engine, but not on magnetic storage.
• Turning it on or changing the threshold needs no reboot.
• Storage never shrinks, by auto scaling or by hand. To shrink, create a smaller instance and move the data (for example with a blue/green deployment).
• It is built for slow, unpredictable growth. A huge one-off load can fill the disk faster than auto scaling can follow, and the database then sits in the storage-full state, refusing writes. Allocate space before a big load.

The slides and many older courses give the third condition as “6 hours since the last storage change”. That was the rule until AWS changed it; today it is “optimisation finished and fewer than 4 changes in 24 hours”. If an exam option says 6 hours, it is quoting the old rule; the other two numbers (10% free, 5 minutes) are unchanged.

#Read replicas

#How they work

A read replica is a read-only copy of a DB instance. When you create one, RDS takes a snapshot of the source, builds a new instance from it, and then keeps it up to date with the engine’s own replication. The source becomes the primary.

• Replication is asynchronous: the primary commits, answers the application, and ships the change to the replicas afterwards. So replicas run slightly behind, and reads from them are eventually consistent.
• A replica accepts only read-only connections: SELECT works; INSERT, UPDATE and DELETE fail.
• Each replica has its own endpoint. RDS does not split reads and writes for you: the application (or a proxy, or a Route 53 record you manage) must send reads to replica endpoints and writes to the primary.
• A replica can live in the same AZ, another AZ or another Region.
• A replica is billed as a normal DB instance, with its own class and storage (keep it at least as big as the primary, or it falls behind).
• RDS has no auto scaling for replicas: you add and remove them yourself. (Aurora can auto scale its replicas, lesson 7.3.)
• A replica can be promoted to a standalone database (see below), and a replica can itself be Multi-AZ.

How many replicas can one source have?

The owner’s notes say “usually 5”. That was the old limit and still appears in older material; today the quota is 15 per source for most engines, which is also the number the slides use.

#What replicas are for

The main use case is offloading reads. A production database is busy with normal traffic. Now the business wants a reporting or analytics application with heavy queries that scan millions of rows (an OLAP workload). Run it against the primary and every customer feels it. Create a read replica, point the reporting tool at the replica’s endpoint, and the production primary is untouched. Replicas only ever answer SELECT-type statements.

Other uses: serve reads while the primary is briefly unavailable (for example during maintenance, accepting stale data), keep a copy near users in another Region, and disaster recovery by promotion.

#Network cost

AWS normally charges for data that crosses AZ boundaries, and for data leaving a Region. RDS makes one special exception:

You always pay for the replica instance and its storage; the question is only the replication traffic.

#Replica lag and the “old post” problem

This is one of the most famous exam scenarios.

The gap is replica lag (also called replication lag), and the behaviour is eventual consistency: the replicas do not have the change immediately, but they eventually all agree. You can see the lag in seconds in the CloudWatch metric ReplicaLag. It grows when:

• the primary takes a burst of heavy writes;
• the replica is a smaller class than the primary, or short of IOPS;
• long queries on the replica slow down the apply process;
• the replica is in another Region (more network distance).

How to fix it, depending on the requirement:

A Multi-AZ standby does not help: it is synchronous, but nobody can read from it.

#Promoting a replica

You can promote a read replica to a standalone DB instance with one action (aws rds promote-read-replica). What happens:

1. The replica stops replicating; the link to the source is broken for good (you cannot reattach it).
2. It reboots (a few minutes) and comes back as a normal read/write instance with its own backups.
3. It keeps its own endpoint, so applications must be pointed at that new name.
4. Anything the primary had not yet shipped (the lag) is not on the promoted copy.

This is how you “write through a read replica”: you can’t, until you promote it, and then it is no longer a replica. Promotion is used for disaster recovery, for splitting a database, and for zero-surprise migrations. It is always manual (or your own automation); RDS never promotes a replica by itself.

#Multi-AZ DB instance: availability, not speed

#How it works

With a Multi-AZ DB instance deployment, RDS creates a standby in another AZ of the same Region and keeps it in step with synchronous replication: every write is stored on the primary and the standby before the application hears “committed”.

• One DNS name. The application only knows the endpoint. During failover RDS points that name at the standby, so the application needs no change, only a reconnect.
• Automatic failover, typically 60–120 seconds, with no manual intervention.
• The standby cannot be read. It has no endpoint and accepts no connections. Multi-AZ does not add read capacity and is not a scaling tool.
• No data loss for committed transactions, because both copies have them.
• The price: you pay for the standby (roughly double a Single-AZ instance), and commits are a little slower because each one waits for the second AZ.
• Backups are taken from the standby, so the primary does not pause for them.

RDS fails over automatically when:

After a failover RDS builds a new standby, so you are protected again.

Two practical details: applications must retry after the connection drops, and must not cache DNS forever. Java applications that connect with JDBC cache DNS answers in the JVM; AWS recommends a DNS TTL of 60 seconds or less (networkaddress.cache.ttl=60). RDS also emits events when a failover starts and ends, which you can send to email or SNS.

#Single-AZ to Multi-AZ without downtime

You can turn an existing Single-AZ instance into Multi-AZ with Modify → Multi-AZ: Yes (or aws rds modify-db-instance --multi-az). It does not stop the database. Inside, RDS:

1. takes a snapshot of the primary’s storage volumes;
2. restores new volumes for the standby in another AZ from that snapshot;
3. starts synchronous replication between the two, and the status returns to available.

The new volumes load their blocks in the background, so write latency can rise until the standby is fully warmed up. AWS therefore suggests doing it in a quiet period, or, for a sensitive production database, creating a read replica, making it Multi-AZ, letting it catch up, and promoting it.

#Is Multi-AZ disaster recovery?

The slides title Multi-AZ “Disaster Recovery” and the notes call it “HA & DR”. Be precise: Multi-AZ protects against the loss of an instance, its storage or one AZ, all inside one Region. That is high availability. If the whole Region is unavailable, the primary and the standby are both gone. Protection against a Region outage needs a cross-Region read replica (or cross-Region backups, lesson 7.2). In exam answers, “high availability”, “automatic failover” and “survive an AZ failure” mean Multi-AZ; “another Region” means a cross-Region replica.

#Multi-AZ DB cluster: readable standbys

A newer deployment option, easy to confuse with Aurora clusters:

• Three DB instances in three AZs: one writer and two reader instances.
• Semi-synchronous replication: a commit succeeds once at least one reader has the change. Every commit is in at least two AZs, but the writer does not wait for the slower reader.
• The two standbys are readable. A writer endpoint always points at the writer, and a reader endpoint spreads connections over the readers (each instance also has its own endpoint).
• Failover typically under 35 seconds, to the reader with the most recent changes; the writer endpoint moves with it.
• Lower write latency than a Multi-AZ instance, because the instances use fast local NVMe storage for the transaction log.
• Only RDS for MySQL and RDS for PostgreSQL, on instance classes with local NVMe (db.m6gd, db.r6gd and similar).
• Readers still apply changes slightly later, so replica lag and the read-after-write problem still exist.
• It is not Aurora: Aurora shares one storage volume across up to 15 replicas (lesson 7.3).

#Disaster recovery across Regions

#The trick question

The owner’s notes include this exam question:

You would like a disaster recovery strategy for your RDS PostgreSQL database so that, during a Regional outage, the database can quickly serve both reads and writes in another Region. The DR database must be highly available. What do you recommend?

The correct answer is create a read replica in a different Region and enable Multi-AZ on the read replica. The tempting wrong answer is “Enable the Multi-Region option on the main database.” Three ideas make it clear:

1. A read replica can take writes, after promotion

   Normally a replica is read-only. In a disaster you promote the replica in the DR Region (say us-west-2, when us-east-1 is down). It stops being a replica and becomes a standalone primary that accepts reads and writes. So “read and write” in the question does not rule out a read replica.

2. Multi-AZ on the replica makes the DR database highly available

   A plain replica, once promoted, is a Single-AZ database: one AZ failure in the DR Region and you are down again. If you enable Multi-AZ on the replica from the start, the replica keeps its own synchronous standby, and the promoted database is highly available from the first minute. That is why the slides note that read replicas can be set up as Multi-AZ for DR.

3. “Enable Multi-Region” does not exist

   Standard RDS has no Multi-Region checkbox. Multi-AZ works only inside one Region. The official way to get an RDS copy into another Region is a cross-Region read replica (cross-Region automated backup replication is the slower, cheaper alternative). The option is invented to confuse you.

#Same need, different service, different answer

Exam writers love to put one service’s feature into another service’s options. Match the cross-Region DR feature to the service named in the question:

#Choosing the right option

The features combine: a primary can be Multi-AZ and have read replicas, and a replica can be Multi-AZ.

#How RDS fits into system design

• Start with Multi-AZ for anything in production. The extra cost buys automatic failover and maintenance with only a short blip. Choose a Multi-AZ DB cluster on MySQL or PostgreSQL when failover time matters or you can use the readable standbys.
• Add read replicas when reads dominate, and design the application for it: a write connection to the primary, a read pool across replica endpoints, read-your-own-writes for anything a user has just changed, and an alarm on ReplicaLag.
• Plan disaster recovery by Region: a cross-Region replica (Multi-AZ if the DR copy must be HA) for minutes of RTO and seconds of RPO, or cross-Region backups for a cheaper, slower plan. Practise the promotion and the connection-string change before you need it, ideally with a Route 53 record (for example db.example.com) in front of the endpoints.
• Turn on storage auto scaling with a realistic threshold, but size storage yourself before planned big loads.
• Keep connection handling robust: retries, short DNS caching, and connection pooling. RDS Proxy (lesson 7.4) shortens failover further and pools connections.
• Migrations: AWS DMS copies an on-premises database into RDS while the source keeps running; promotion of a replica or a blue/green deployment helps with upgrades.

#Try it yourself

# 1. A PostgreSQL instance: Multi-AZ, gp3, storage auto scaling up to 500 GiB
aws rds create-db-instance \
  --db-instance-identifier shop-db \
  --engine postgres --db-instance-class db.m7g.large \
  --allocated-storage 100 --storage-type gp3 --max-allocated-storage 500 \
  --multi-az --master-username app --manage-master-user-password \
  --db-subnet-group-name private-db --vpc-security-group-ids sg-0abc1234def567890

# 2. Find the endpoint (the DNS name your app uses) and which AZs are in use
aws rds describe-db-instances --db-instance-identifier shop-db \
  --query "DBInstances[0].[Endpoint.Address,Endpoint.Port,AvailabilityZone,SecondaryAvailabilityZone,MultiAZ]"

# 3. A read replica in another AZ, and one in another Region (inter-Region transfer is billed)
aws rds create-db-instance-read-replica --db-instance-identifier shop-db-rr1 \
  --source-db-instance-identifier shop-db --availability-zone us-east-1c
aws rds create-db-instance-read-replica --region us-west-2 \
  --db-instance-identifier shop-db-dr --multi-az \
  --source-db-instance-identifier arn:aws:rds:us-east-1:111122223333:db:shop-db

# 4. Watch replica lag (seconds) on the replica
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=shop-db-rr1 \
  --start-time 2026-10-25T10:00:00Z --end-time 2026-10-25T11:00:00Z \
  --period 60 --statistics Maximum

# 5. Test failover: reboot with failover, then see the AZs swap
aws rds reboot-db-instance --db-instance-identifier shop-db --force-failover
aws rds describe-events --source-identifier shop-db --source-type db-instance --duration 60

# 6. Convert a Single-AZ instance to Multi-AZ (no downtime)
aws rds modify-db-instance --db-instance-identifier legacy-db --multi-az --apply-immediately

# 7. Disaster: promote the cross-Region replica (replication ends for good)
aws rds promote-read-replica --region us-west-2 --db-instance-identifier shop-db-dr

# 8. A Multi-AZ DB cluster (MySQL or PostgreSQL only): writer + 2 readable standbys
aws rds create-db-cluster --db-cluster-identifier orders-cluster \
  --engine postgres --db-cluster-instance-class db.r6gd.large \
  --storage-type io2 --iops 3000 --allocated-storage 100 \
  --master-username app --manage-master-user-password
aws rds describe-db-clusters --db-cluster-identifier orders-cluster \
  --query "DBClusters[0].[Endpoint,ReaderEndpoint]"

On the replica, writes fail and reads work, and you can see how far behind it is:

-- PostgreSQL replica
SELECT pg_is_in_recovery();                         -- true on a replica
SELECT now() - pg_last_xact_replay_timestamp() AS lag;
UPDATE posts SET title = 'x' WHERE id = 1;          -- ERROR: cannot execute UPDATE in a read-only transaction

-- MySQL replica
SHOW REPLICA STATUS\G                                -- Seconds_Behind_Source

#Summary

Key takeaways

• RDS is a managed relational database: AWS handles hardware, OS and engine patching, backups, Multi-AZ failover and replicas; you handle schema, queries, sizing and access. Engines: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, IBM Db2 (Aurora is separate). No SSH; for OS access use RDS Custom (Oracle, SQL Server) or EC2.
• Connect through the endpoint (a DNS name). Storage is EBS: gp3 for most, io2 for steady high IOPS. Changing the instance class is vertical scaling with a reboot.
• Storage auto scaling: when free space ≤ 10% for 5 minutes and the last change has finished optimising (≤ 4 changes in 24 h; older material says 6 hours), RDS adds the largest of 10 GiB, 10% or the predicted 7-hour growth, up to your maximum storage threshold. No downtime; storage never shrinks.
• Read replicas: up to 15 per source (Db2: 3), same AZ, cross-AZ or cross-Region, asynchronous, eventually consistent, read-only (SELECT), each with its own endpoint; the app must send reads there. Use them for reporting and read-heavy load. Same-Region replication is free, cross-Region is billed.
• Replica lag explains “I updated it but see the old data”. Fix with read-your-own-writes from the primary, a cache, or Aurora; watch ReplicaLag.
• Promoting a replica makes it a standalone read/write database, ends replication, keeps its own endpoint, and is always manual. Replicas never fail over automatically.
• Multi-AZ DB instance: synchronous standby in another AZ, one DNS name, automatic failover in 60–120 s, standby not readable, not for scaling, about double the cost. Single-AZ → Multi-AZ is online: snapshot, restore in another AZ, then sync.
• Multi-AZ DB cluster: one writer + two readable standbys in three AZs, semi-synchronous, reader endpoint, failover under 35 s, MySQL and PostgreSQL only.
• Cross-Region DR for RDS = cross-Region read replica, promoted manually; enable Multi-AZ on the replica if the DR database must be HA. “Multi-Region option” does not exist. Aurora → Global Database; DynamoDB → Global Tables.

Self-check: RDS, read replicas and Multi-AZ30 questions