5 · Database Resilience¶

Domain 2 — Design Resilient Architectures · 26%

The single most-tested distinction in this topic: RDS Multi-AZ (availability/failover) vs RDS Read Replicas (read scaling). They look similar and are constantly swapped in distractors. Get that, plus what makes Aurora and DynamoDB Global Tables special, and you've got most of it.

Core concept¶

"Database resilience" bundles three different goals — the exam wants you to match the feature to the goal:

Goal	RDS feature
Survive an AZ/instance failure (availability)	Multi-AZ deployment
Scale read traffic	Read replicas
Survive a Region failure (DR) / low-latency global reads	Cross-Region read replica or Aurora Global Database

These are independent — you can (and often do) run Multi-AZ and read replicas together.

RDS Multi-AZ vs Read Replicas (memorize this table)¶

	Multi-AZ	Read Replica
Purpose	High availability / failover	Read scaling
Replication	Synchronous to a standby	Asynchronous (can be stale)
Standby readable?	No (standby is idle until failover)	Yes — serves read-only queries
Failover	Automatic, same DNS endpoint	Manual — promote replica to standalone
Location	Another AZ (same Region)	Same AZ, cross-AZ, or cross-Region
Count	One standby	Up to 15 (MySQL/MariaDB/PostgreSQL)

Two consequences that drive answers:

A standby is not for reads. If a scenario says "offload reporting/read queries," the answer is read replicas, never Multi-AZ.
A read replica is not automatic HA. It's async (may lag) and failover is a manual promotion — if the scenario says "automatic failover with no data loss," that's Multi-AZ.

The newer Multi-AZ DB cluster option adds two readable standby replicas (blurring the line), but the classic exam framing is the table above.

Aurora — resilience built into storage¶

Amazon Aurora is AWS's MySQL/PostgreSQL-compatible database with a purpose-built, self-healing storage layer. What the exam cares about:

Your data is kept as 6 copies across 3 Availability Zones, continuously self-healing — so it tolerates AZ and disk failures transparently.
Up to 15 Aurora Replicas share the storage, have very low replica lag, and any can be an automatic failover target (failover is fast — typically well under a minute).
Endpoints do the routing: a cluster (writer) endpoint for writes, a reader endpoint that load-balances across replicas for reads, and optional custom endpoints.
Aurora Global Database — one primary Region + up to five secondary Regions with sub-second cross-Region replication; designed for RPO ≈ 1 second, RTO ≈ 1 minute and low-latency global reads. This is the go-to for fast cross-Region DR of a relational database.
Aurora Serverless auto-scales capacity for intermittent/unpredictable workloads.

If a question wants relational + minimal-ops resilience, or fast cross-Region relational DR, Aurora (and Aurora Global Database) is usually the intended answer.

DynamoDB resilience¶

DynamoDB is serverless NoSQL and is highly available by default — it synchronously replicates across three AZs in a Region, no configuration needed. Add:

Global Tables — multi-Region, active-active replication (multi-master). Users read/write the nearest Region; ideal for global low-latency apps and Region-failure resilience.
Point-in-time recovery (PITR) — continuous backups letting you restore to any second in the last 35 days.
On-demand backups and DynamoDB Streams (change data capture, e.g. to trigger Lambda).

When a scenario needs a globally distributed, multi-Region, active-active datastore with no servers to manage → DynamoDB Global Tables.

Backups¶

RDS automated backups — enabled with a retention window of 0–35 days (0 disables them), supporting point-in-time restore. They're deleted when the instance is.
Manual DB snapshots — kept until you delete them; can be copied cross-Region or shared with other accounts — a simple, cheap DR building block.
Restoring a snapshot always creates a new instance/endpoint (you then repoint the app).

Worked example — one feature can't do both jobs¶

An e-commerce database is hitting two problems at once: (1) reporting queries are slowing down the production database, and (2) the business needs automatic failover with no data loss if the database's AZ goes down. A teammate proposes "just add a read replica — it copies the data, so it covers both."

Is that right?

Answer

No — you need both features. A read replica solves problem (1): point reporting/read queries at the replica to offload the primary. But a read replica is asynchronous (can lag) and its failover is a manual promotion, so it does not provide automatic, zero-data-loss failover. For problem (2) you need Multi-AZ, whose synchronous standby fails over automatically on the same endpoint. The correct design runs Multi-AZ and a read replica together — they serve different goals.

Exam traps¶

Multi-AZ = availability (sync, auto-failover, standby not readable); Read Replica = read scaling (async, may be stale, manual promote). Don't swap them.
"Offload reads" → read replica. "Automatic failover / no data loss" → Multi-AZ.
Aurora keeps 6 copies across 3 AZs; up to 15 replicas, any can be a failover target.
Fast cross-Region relational DR → Aurora Global Database (RPO ~1s, RTO ~1min).
DynamoDB is multi-AZ by default; Global Tables add multi-Region active-active.
Cross-Region read replica (or copied snapshots) is a common cheap RDS DR pattern.
RDS automated backups max retention = 35 days; manual snapshots persist until deleted and can be copied cross-Region for DR.

Practice questions¶

Q1. A production RDS MySQL database must fail over automatically with no data loss if its Availability Zone fails. What should be enabled?

A. A read replica in another AZ
B. Multi-AZ deployment
C. Automated backups with 35-day retention
D. A larger instance class

Answer: B

B. Multi-AZ keeps a synchronous standby and fails over automatically on the same endpoint — no data loss, no app change. A read replica (A) is asynchronous and promoted manually. Backups (C) protect data but don't auto-fail-over. Instance size (D) is irrelevant to AZ resilience.

Q2. Reporting queries are overloading a production RDS PostgreSQL instance. The team wants to offload these read-only queries with minimal application change. What should they add?

A. Multi-AZ deployment
B. One or more read replicas, directing reporting queries to them
C. Larger provisioned IOPS
D. Automated backups

Answer: B

B. Read replicas serve read-only traffic, offloading the primary; point reporting at the replica endpoint. Multi-AZ's standby (A) can't serve reads. More IOPS (C) doesn't separate read from write load. Backups (D) don't affect query load.

Q3. A company needs a relational database with a disaster-recovery plan that gives cross-Region failover at roughly RPO of seconds and RTO of about a minute, plus low-latency reads in a second Region. Which is the best fit?

A. RDS Multi-AZ
B. Aurora Global Database
C. DynamoDB Global Tables
D. Cross-Region automated backups

Answer: B

B. Aurora Global Database replicates to secondary Regions in under a second (RPO ~1s, RTO ~1min) and serves low-latency reads there — purpose-built for fast cross-Region relational DR. Multi-AZ (A) is single-Region. DynamoDB (C) is NoSQL, not relational. Cross-Region backups (D) have a much larger RTO/RPO.

Q4. An application needs a globally distributed, active-active datastore so users in different continents can read and write to a nearby Region with single-digit-millisecond latency and no servers to manage. Which service?

A. Aurora Global Database
B. RDS with cross-Region read replicas
C. DynamoDB with Global Tables
D. ElastiCache

Answer: C

C. DynamoDB Global Tables provide multi-Region active-active (multi-master) replication, serverless, with low-latency local reads/writes. Aurora Global Database (A) has one writable primary Region (secondaries are read/DR). Cross-Region RDS replicas (B) are read-only. ElastiCache (D) is a cache, not a primary global datastore.

Q5. Which statement about RDS read replicas is correct?

A. They replicate synchronously and can't be stale.
B. They can serve read traffic, may lag the primary, and can be promoted to a standalone instance for DR.
C. They automatically fail over like Multi-AZ.
D. A DB instance can have at most one read replica.

Answer: B

B. Read replicas are asynchronous (so they can lag), serve read-only traffic, and can be manually promoted to a standalone database — a common DR tactic. A is wrong (they're async); C describes Multi-AZ, not read replicas; D is wrong (multiple replicas are supported).

Next: 6 · Decoupling & Disaster Recovery → · Revise — Database Resilience