Module 5 · SAA-C03

Databases

RDS, Aurora, DynamoDB, ElastiCache and purpose-built databases: choose by data model, availability and performance.

DomainResilient architectures
DomainHigh-performing architectures
DomainCost-optimized architectures
15 diagrams
10 scenarios
12 services

5-minute essentials

RDS Multi-AZ: a synchronous standby in another AZ, automatic failover via the same DNS name; the standby (single-standby instance deployment) does not serve reads.Question asks to "improve availability" → Multi-AZ; "offload reads" → read replica. They are different things.
A read replica replicates asynchronously, is readable, can be in the same or another Region, and can be promoted to a standalone DB (RDS MySQL up to 15 replicas).Heavy reporting slows the main DB → read replica; cross-Region DR → cross-Region read replica, then promote.
RDS automated backups are kept 0–35 days (0 disables them) and support point-in-time recovery; manual snapshots are kept until you delete them.Need to keep more than 35 days → manual snapshots or AWS Backup.
Aurora: shared storage with copies across 3 AZs, grows automatically (up to 256 TiB depending on version), up to 15 Aurora Replicas, replica lag usually under 100 ms.Aurora failover is fast because replicas read the same storage; use the writer endpoint for writes and the reader endpoint to spread reads.
Aurora Global Database: 1 writer Region + up to 10 read-only secondary Regions, replication usually under 1 second.Cross-Region DR with low RPO / RTO, or low-latency reads for global users.
Aurora Serverless v2 scales with demand; RDS Proxy pools connections for Lambda / apps that open many connections.Lambda exhausts RDS connections → RDS Proxy (also speeds up failover and uses IAM / Secrets Manager).
DynamoDB: NoSQL key-value with millisecond latency at any scale; items up to 400 KB; on-demand (pay per request) or provisioned (RCU / WCU, with auto scaling).Unpredictable traffic → on-demand; steady traffic, want lower cost → provisioned + auto scaling.
1 RCU = 1 strongly consistent read (or 2 eventually consistent reads) per second for an item ≤ 4 KB; 1 WCU = 1 write per second for an item ≤ 1 KB; transactions cost double.Capacity calculation questions: round item size up to a multiple of 4 KB (reads) or 1 KB (writes).
DynamoDB keys: partition key (+ sort key). GSI: entirely different key, created any time, eventually consistent only. LSI: same partition key, different sort key, must be created with the table, max 5.Need to query on another attribute → GSI; avoid Scan.
DynamoDB Streams + Lambda for change-driven processing; Global Tables for multi-Region active-active; PITR restores to any second within 35 days; TTL deletes expired items automatically.Send an email on each new order → Streams + Lambda; users on several continents writing → Global Tables.
Caching: DAX for DynamoDB (microseconds, almost no code changes); ElastiCache for any source (Valkey / Redis OSS: replication, backups, rich data structures; Memcached: simple, multithreaded, no replication).Repeated heavy reads from RDS → ElastiCache (cache-aside); leaderboard → Valkey / Redis sorted set.
Purpose-built databases: DocumentDB (MongoDB), Neptune (graph), Keyspaces (Cassandra), Timestream (time series), Redshift (data warehouse, OLAP), MemoryDB (durable Redis as a primary DB).Questions usually describe the data model → choose by model: friend relationships → Neptune; time-based IoT data → Timestream.
RDS encryption must be enabled at creation; for an unencrypted DB: snapshot → copy the snapshot with encryption → restore.A read replica has the same encryption state as its source.

Diagrams

RDS Multi-AZ and read replicas

Writes go to the primary; the standby in another AZ receives data synchronously and is used only on failover. A read replica receives data asynchronously and serves reads (reporting).

Step by step

Every write is copied synchronously to the standby in another AZ.
The read replica receives data asynchronously; the reporting tool reads from it so the primary isn't slowed down.
Primary or AZ a fails: RDS moves the DNS name to the standby, and the app reconnects to the same endpoint.

Aurora: writer, readers and shared storage

All instances read and write the same cluster volume with copies across 3 AZs. Write via the writer endpoint, read via the reader endpoint (spread across replicas). If the writer fails, a replica is promoted.

Step by step

Writes go through the writer endpoint; data lives on the shared cluster volume.
Reads go through the reader endpoint, spread across Aurora Replicas (lag usually under 100 ms).

Aurora Global Database

One Region writes; read-only secondary Regions receive data, usually in under 1 second, over dedicated infrastructure. If the primary Region fails, promote a secondary Region.

Step by step

Writes happen in the primary Region and are replicated at the storage layer to the secondary Region, usually in under 1 second.
European users read from the nearby Region; if the primary Region fails, fail over to the secondary cluster.

RDS Proxy pooling connections for Lambda

Thousands of Lambda invocations open connections to the proxy; the proxy reuses a small pool of database connections and gets credentials from Secrets Manager.

Step by step

Each Lambda environment connects to the proxy instead of the database.
The proxy reuses a small connection pool and gets credentials from Secrets Manager; failover is faster.

Cache-aside with ElastiCache

Read the cache first; on a miss, read the database and write the result to the cache with a TTL. When writing new data, delete (or update) the key in the cache.

DAX in front of DynamoDB

The app switches to the DAX client (same API). Cache hits return in microseconds; writes go through DAX to DynamoDB.

Step by step

Repeated reads are served from DAX memory (microseconds).
Cache miss or write: DAX calls DynamoDB, then updates the cache.

DynamoDB keys, GSI and LSI

The Orders table is keyed on customerId + orderDate. An LSI keeps the partition key and changes the sort key (must be created with the table). A GSI uses an entirely different key (status) and can be added later.

Step by step

LSI: same customer, sorted by another attribute; strongly consistent reads possible.
GSI: query on an entirely different attribute without a Scan; eventually consistent only.

DynamoDB Streams triggering processing

Each item change becomes a record in the stream (kept 24 hours). Lambda reads in batches to send notifications, update a search index, or record statistics.

Step by step

The app only writes to the table; DynamoDB puts the changes into the stream.
Lambda reads the stream in batches, sends emails and updates the search index.

DynamoDB Global Tables: writes in multiple Regions

Each Region has a read/write replica; changes are replicated to the other Regions. Users read and write in the nearest Region.

Step by step

Each location reads and writes the replica in its nearby Region (active-active).
Changes are replicated to the other replicas.

Choosing a database by data model

No single database fits every job: questions usually describe the data and how it is queried, and the answer is the service built for that model.

RDS: automated backups, point-in-time restore, manual snapshots

Every kind of restore (point-in-time or from a snapshot) creates a NEW DB instance with a new endpoint and never overwrites the old one: the app must change its connection string.

Step by step

Automated backups: a daily storage snapshot during the backup window, with transaction logs uploaded to S3 every 5 minutes; kept for the number of days you set (0 disables them).
Manual snapshots never expire and remain after the instance is deleted (up to 100 manual snapshots per Region).
Point-in-time restore: pick any moment within the backup retention period; the result is a NEW instance.
Restoring from a snapshot also creates a new instance: point the app at the new endpoint before deleting the old instance.

Encrypting a running unencrypted RDS instance

RDS encryption can only be enabled at creation; it cannot be turned on in place, nor turned off later. The method: snapshot → copy the snapshot with encryption → restore a new instance (or use a blue/green deployment).

Aurora Serverless v2: writer and readers scale by ACU

A cluster can mix serverless and provisioned instances. Compute scales in ACUs (about 2 GiB RAM per ACU); storage is shared and separate from compute.

Step by step

The serverless writer scales ACUs up and down with load, in steps as small as 0.5 ACU, without dropping connections; newer versions support a minimum of 0 ACU (auto-pause when idle).
Readers in promotion tier 0–1 scale along with the writer to be ready for failover; tiers 2–15 scale independently (good for reporting).
When compute scales down, data stays intact on the cluster volume (6 copies across 3 AZs); provisioned readers can be mixed into the same cluster.

Choosing a DynamoDB capacity mode

On-demand is the default AWS recommends. Provisioned fits steady, predictable load; reserved capacity applies only to provisioned tables in the Standard table class.

Step by step

New app, spiky and unpredictable load: on-demand, pay per request, no capacity planning.
Steady, predictable load: provisioned (pay for reserved throughput even if unused) + auto scaling.
Long-term stable baseline: buy reserved capacity for the provisioned portion to get a discount.

Redshift RA3: compute separate from managed storage, Spectrum reads the data lake

The leader node receives SQL, plans the query and aggregates results; compute nodes run in parallel. With RA3 (and newer RG) data lives in managed storage: local SSD + S3, with compute and storage billed separately.

Step by step

The leader takes the query and splits it across compute nodes running in parallel; only compute nodes are billed.
Data that exceeds local SSD is offloaded to managed storage on S3 automatically: grow storage without adding nodes.
Spectrum queries files on S3 (the data lake) directly without loading them into the cluster.
Don't want to manage a cluster: Redshift Serverless provisions and scales compute automatically.

Quick comparisons

Multi-AZ vs read replica

	Multi-AZ (DB instance)	Read replica
Purpose	High availability, failover	Read scaling, DR
Replication	Synchronous	Asynchronous
Readable	No (standby)	Yes
Scope	Different AZ, same Region	Same AZ, different AZ or different Region
When the primary fails	Automatic failover, same endpoint	Must promote, new endpoint

RDS vs Aurora

	RDS	Aurora
Engine	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2	MySQL-, PostgreSQL-compatible
Storage	EBS attached to the instance, provisioned up front (with autoscaling)	Shared cluster volume, copies across 3 AZs, grows automatically
Read replicas	Up to 15 (MySQL), asynchronous	Up to 15, usually under 100 ms, failover targets
Multi-Region	Cross-Region read replica	Global Database (up to 10 secondary Regions, under 1 second)

DynamoDB: GSI vs LSI

	GSI	LSI
Partition key	Different from base table	Same as base table
Creation	Any time	Only at table creation
Limit	20 per table (default, can request increase)	5 per table
Strongly consistent reads	No	Yes
Capacity	Separate RCU / WCU	Shared with table; item collection up to 10 GB

Choosing a cache

	DAX	ElastiCache (Valkey / Redis OSS)	ElastiCache (Memcached)
Works with	DynamoDB only	Any source	Any source
Code changes	Almost none (SDK compatible with the DynamoDB API)	Yes (cache-aside, write-through)	Yes
Replication / failover	Yes (1 primary + up to 10 replicas)	Yes	No
Backups, data structures	—	Backups; sorted sets, lists, pub/sub…	No backups (node-based); simple key-value only, multithreaded

Databases by data model

Need	Service
Relational, transactional (OLTP)	RDS, Aurora
Key-value / document at scale, consistent latency	DynamoDB
MongoDB-compatible	DocumentDB
Graph (social networks, recommendations, fraud detection)	Neptune
Cassandra-compatible	Keyspaces
Time series (IoT, metrics)	Timestream
Data warehouse, analytics (OLAP)	Redshift
In-memory cache	ElastiCache
Durable Redis as the primary database	MemoryDB

Exam scenarios

1An RDS MySQL database must fail over automatically to another host when an AZ has an outage, without the app changing its connection string.

Show answer

Right: Enable Multi-AZ
Synchronous standby; on failure, RDS points the same DNS name to the standby automatically.

Wrong: Create a read replica in another AZ
The replica is asynchronous, must be promoted manually, and the endpoint changes.

2Month-end reporting queries slow down the orders database (RDS PostgreSQL).

Show answer

Right: Create a read replica and point the reporting tool at it
Moves heavy read load off the primary.

Wrong: Enable Multi-AZ
The standby does not serve reads.

Wrong: Increase the instance size
Paying all month for a load that lasts a few days.

3A global app on Aurora needs cross-Region DR with an RPO of about 1 second and low-latency reads in Europe.

Show answer

Right: Aurora Global Database with a secondary cluster in Europe
Replication usually under 1 second; the secondary cluster serves local reads and can be promoted if the primary Region fails.

Wrong: Daily snapshots copied to another Region
RPO up to 24 hours.

4Thousands of concurrent Lambda functions cause RDS to report "too many connections".

Show answer

Right: Put RDS Proxy between Lambda and RDS
The proxy keeps a shared connection pool, supports IAM / Secrets Manager and speeds up failover.

Wrong: Increase max_connections and the instance size
Only raises the limit; doesn't solve the constant opening / closing of connections.

5Product pages read the same data from RDS thousands of times per second; you want to reduce DB load and latency.

Show answer

Right: ElastiCache (Valkey / Redis OSS) with cache-aside and TTL
Reads from memory in microseconds; the DB only receives cache misses.

Wrong: DAX
DAX works only with DynamoDB.

6A DynamoDB table gets very frequent repeated reads of the same items and needs microsecond latency without rewriting caching logic.

Show answer

Right: DynamoDB Accelerator (DAX)
Write-through cache compatible with the DynamoDB API; just swap the client.

Wrong: ElastiCache
You must write the caching and data sync logic yourself.

7A new app with unpredictable traffic (sometimes zero, sometimes spiking) wants no capacity planning.

Show answer

Right: DynamoDB on-demand
Pay per request, adapts to load automatically.

Wrong: DynamoDB provisioned without auto scaling
Throttled during spikes, wasted capacity when idle.

8A DynamoDB table is keyed on customerId; now you need to find orders by status without a Scan.

Show answer

Right: Create a GSI with partition key status
A GSI has a different key and can be added after the table exists.

Wrong: Create an LSI on status
An LSI must be created with the table and keeps the same partition key, customerId.

Wrong: Scan with a filter
Reads the whole table and burns RCUs.

9Each new order in DynamoDB must trigger a confirmation email, without changing the order-writing code.

Show answer

Right: Enable DynamoDB Streams and have Lambda process the stream
Each item change becomes a stream record; Lambda polls them in batches automatically.

Wrong: A scheduled Lambda that scans the table
Delayed, and Scan burns RCUs.

10A social networking app needs fast "friends of friends with the same interests" queries.

Show answer

Right: Amazon Neptune
A graph database that traverses multi-hop relationships efficiently.

Wrong: RDS with many JOINs
Multi-level JOINs get slower as data grows.

Quick picks

Which database, and how should it scale?

When you need	Use
Relational, high availability within one Region	RDS Multi-AZ or Aurora · see diagram
Offload reads from RDS / Aurora	Read replica / Aurora Replica + reader endpoint · see diagram
Cross-Region DR, RPO about 1 second	Aurora Global Database · see diagram
Lambda opens too many connections	RDS Proxy · see diagram
Cache for read-heavy data from RDS	ElastiCache (cache-aside) · see diagram
Microsecond cache for DynamoDB	DAX · see diagram
Key-value at scale, consistent latency	DynamoDB (choose a good key, GSI for other queries) · see diagram
Process changes to DynamoDB data	DynamoDB Streams + Lambda · see diagram
Write in multiple Regions at once	DynamoDB Global Tables · see diagram
Graph, document, time series, data warehouse	Neptune, DocumentDB, Timestream, Redshift · see diagram
Migrate an on-premises database to AWS with minimal downtime	DMS (+ Schema Conversion when changing engines)

Common pitfalls

Using the Multi-AZ standby to offload reads (a single-standby Multi-AZ instance is not readable).
Using a read replica as an automatic HA solution within one Region: the replica must be promoted and the endpoint changes.
Thinking RDS automated backups can be kept longer than 35 days.
Using DAX for RDS, or ElastiCache for DynamoDB, when the question stresses "no code changes".
Choosing Memcached when you need replication, backups or sorted sets.
Creating an LSI on an existing table (not possible) or expecting strongly consistent reads on a GSI.
Choosing a low-cardinality partition key (e.g., status) for a large table: hot partitions, throttling.
Using Scan for frequent queries instead of Query + GSI.
Storing items larger than 400 KB in DynamoDB: put the file in S3 and store the path.
Assuming you can enable encryption on a running unencrypted RDS instance: you must go through a snapshot.
Using Redshift for OLTP, or RDS for analytics over billions of rows.
Using RDS for workloads that write from multiple Regions at once: that's DynamoDB Global Tables.

Services in this module

Numbers that change (checked against AWS docs)

RDS replicates to read replicas asynchronously; a read replica can be in another Region and be promoted to a standalone DB; RDS does not auto-scale the number of read replicas. checked 2026-10-16 ↗
RDS for MySQL: up to 15 read replicas per source DB instance in the same Region. checked 2026-10-16 ↗
RDS automated backups are kept 0–35 days (0 disables them); default 7 days when created in the console, 1 day when created via API / CLI. checked 2026-10-16 ↗
The Aurora cluster volume has copies across 3 AZs and grows automatically up to 256 TiB depending on engine version. checked 2026-10-16 ↗
Aurora supports up to 15 Aurora Replicas; replica lag usually under 100 ms; replicas are failover targets. checked 2026-10-16 ↗
Aurora Global Database: 1 primary Region and up to 10 secondary Regions; replication usually under 1 second. checked 2026-10-16 ↗
DynamoDB: items up to 400 KB; 1 RCU = 1 strongly consistent read or 2 eventually consistent reads per second for an item ≤ 4 KB; 1 WCU = 1 write per second for an item ≤ 1 KB; transactions cost double. checked 2026-10-16 ↗
DynamoDB: up to 5 LSIs and 20 GSIs by default per table. checked 2026-10-16 ↗
DynamoDB PITR restores to any second within up to 35 days (configurable 1–35 days). checked 2026-10-16 ↗
DAX: 1 primary node and 0–10 read replicas per cluster. checked 2026-10-16 ↗
ElastiCache Memcached is multithreaded with no replication / failover; Valkey and Redis OSS have replication, failover, pub/sub, sorted sets and backups. checked 2026-10-16 ↗
RDS point-in-time restore creates a new DB instance and does not modify the original; RDS uploads transaction logs to S3 every 5 minutes. checked 2026-10-19 ↗
RDS encryption can only be enabled at creation; to encrypt an existing instance, copy a snapshot with encryption and restore (or use blue/green); encryption cannot be disabled. checked 2026-10-19 ↗
Aurora Serverless v2: 1 ACU ≈ 2 GiB RAM; range 0–256 ACU (0 ACU = auto-pause, depending on engine version); a cluster can mix serverless and provisioned instances. checked 2026-10-19 ↗
DynamoDB: on-demand is the recommended default mode; reserved capacity applies only to provisioned tables in the Standard table class, 1-year term (3 years in some Regions). checked 2026-10-19 ↗
Redshift RA3 / RG use managed storage (local SSD + S3), with compute and storage billed separately; only compute nodes are billed, not the leader node. checked 2026-10-19 ↗

Practice this module →