RDS and Aurora Databases

1Multi-AZ versus Read Replicas

Multi-AZ and Read Replicas solve different problems. Multi-AZ keeps a synchronous standby in another Availability Zone for high availability and automatic failover — RPO to that standby is effectively zero because writes are confirmed on both. Read Replicas are asynchronous copies used to scale read traffic; they can lag and they are not the Multi-AZ failover mechanism. If the stem says "survive an AZ outage with no data loss," pick Multi-AZ. If it says "improve read performance," pick Read Replicas.

Figure. Multi-AZ: synchronous standby in a second AZ. Read Replicas are a separate async path for scaling reads.

How the exam sorts the two

1. HA / no data loss?Multi-AZ synchronous standby and automatic failover.
2. Read scaling?Read Replicas (async); point reporting queries at replica endpoints.
3. Need both?Enable Multi-AZ for HA and add replicas separately for reads — one does not replace the other.

2RDS engines and managed ops

RDS offers managed MySQL, PostgreSQL, MariaDB, Oracle and SQL Server, plus Amazon Aurora as a MySQL- and PostgreSQL-compatible engine on different storage. AWS handles automated backups, patching and point-in-time recovery so you are not running database OS chores on EC2. The exam distinction is managed relational service versus self-managed DB on an instance — not which SQL dialect you prefer.

RDS is the managed-ops checklist — patching, backups, Multi-AZ — across supported engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server). Engine logos in boxes would violate the no-service-glyph rule and add no topology.

3Aurora shared storage architecture

Aurora separates compute from a shared, distributed storage layer. Data is replicated six ways across three Availability Zones and storage auto-grows in 10 GB increments up to 128 TB. Compute nodes (writer and Aurora Replicas) attach to that shared volume, which is why replica lag is typically sub-10 ms and why adding a reader does not mean copying a whole second disk the way a classic RDS replica might.

Figure. Compute attaches to one distributed volume; storage — not each replica's local disk — holds the six-way copies.

How Aurora splits the roles

1. Shared volumeStorage keeps six copies across three AZs and grows automatically.
2. Writer computeOne primary instance accepts writes against that volume.
3. Reader computeAurora Replicas attach to the same storage for read scaling.

4Failover and the stable endpoint

On Multi-AZ failure, RDS promotes the standby and updates the DNS CNAME for the DB endpoint so applications keep the same hostname. Failover typically completes in about 60–120 seconds; the important exam claim is "same endpoint, AWS repoints it," not "rewrite every connection string." Combine Multi-AZ with automated backups when you also need point-in-time recovery from logical mistakes — failover does not undo a bad DELETE.

Figure. Clients keep one DNS name; failover repoints that name to the new primary — reconnect, do not hardcode IPs.

What happens on primary failure

1. DetectRDS decides the primary in AZ-a is unhealthy.
2. PromoteThe synchronous standby in AZ-b becomes the writer.
3. Repoint DNSThe existing DB endpoint's CNAME moves to the new primary; clients reconnect.

5Aurora cluster and reader endpoints

An Aurora cluster exposes a cluster (writer) endpoint that always points at the current primary for writes, and a reader endpoint that load-balances across Aurora Replicas. Send transactional writes to the writer endpoint; send read-only reporting to the reader endpoint. After failover the writer endpoint moves with the new primary — same stable-name idea as RDS Multi-AZ, specialised into two roles.

Figure. Aurora writer endpoint always targets the primary; reader endpoint load-balances across read replicas.

Where each query goes

1. WritesApplication uses the cluster/writer endpoint.
2. ReadsReporting and read-only traffic use the reader endpoint.
3. FailoverWriter endpoint follows the new primary; readers continue against remaining replicas.

6Backups and retention

Automated backup retention on RDS/Aurora ranges from 0 (disabled) to 35 days and enables point-in-time recovery inside that window. Manual snapshots persist until you delete them and are the cue for long-term keep-forever copies or pre-change safety snaps. Failover protects against instance/AZ loss; backups protect against logical errors and regional restore stories.

Figure. Automated backup retention is a day count (0 disables); snapshots are separate and persist until you delete them.

7RDS storage types

General Purpose SSD (gp3) is the default balanced choice: baseline IOPS and throughput scale with size (and gp3 lets you provision some performance independently of size). Provisioned IOPS (io1/io2) is the latency-sensitive OLTP cue when you must guarantee high IOPS regardless of a modest volume size. Pick gp3 unless the stem stresses consistent high IOPS / low latency under heavy OLTP.

Figure. OLTP latency-sensitive workloads pick provisioned IOPS; gp3 covers most general cases.

How to choose storage

1. Ordinary loadStart with gp3; size for capacity and acceptable baseline I/O.
2. Hard IOPS SLAIf the exam demands sustained high IOPS independent of size, move to io1/io2.
3. Don't confuse with Multi-AZStorage type is performance; Multi-AZ is availability.

8Replica counts and Global Database

RDS MySQL/PostgreSQL support up to 15 read replicas; Aurora allows up to 15 Aurora Replicas per cluster with typically sub-10 ms lag on the shared volume. For a global low-latency read footprint plus disaster recovery, Aurora Global Database replicates across Regions with sub-second lag — the cue when one Region's replicas are not enough. Promoting a Read Replica to a standalone DB is the migration / regional-DR escape hatch on classic RDS.

Figure. RDS and Aurora allow up to 15 same-cluster / same-Region read replicas. Aurora Global Database adds a cross-Region secondary with sub-second lag for global reads and DR — a different scope from the 15-replica cap.