3.5 Database Services - RDS, Aurora, DynamoDB, and More
Key Takeaways
- RDS manages six engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2) with automated backups, point-in-time recovery up to 35 days, and Multi-AZ failover.
- Aurora is AWS-built, MySQL/PostgreSQL-compatible, replicates 6 copies across 3 AZs, scales storage to 128 TB, supports up to 15 low-lag read replicas, and fails over in under 30 seconds.
- DynamoDB is serverless NoSQL with single-digit-millisecond latency, on-demand or provisioned capacity, Global Tables for active-active multi-Region, and DAX for microsecond reads.
- ElastiCache for Redis adds replication, persistence, and Multi-AZ failover; Memcached is simple, multi-threaded, no persistence or failover.
- Match the data model: relational HA -> Aurora/RDS Multi-AZ; key-value at scale -> DynamoDB; caching -> ElastiCache; analytics/OLAP -> Redshift; graph -> Neptune.
Quick Answer: Relational SQL -> RDS or Aurora (Aurora for higher performance/HA). Key-value/document at any scale -> DynamoDB. Caching -> ElastiCache (Redis for features, Memcached for simple multi-threaded). Analytics/OLAP -> Redshift. Graph -> Neptune. MongoDB-compatible -> DocumentDB. Pick the purpose-built database for the data model.
Amazon RDS
RDS is managed relational database hosting for six engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2). AWS handles provisioning, patching, backups, and failover; you keep schema and query control. Automated backups enable point-in-time recovery up to 35 days.
Read Replicas vs Multi-AZ (a constant exam trap)
| Feature | Read Replicas | Multi-AZ |
|---|---|---|
| Purpose | Scale reads | High availability |
| Replication | Asynchronous | Synchronous to standby |
| Readable? | Yes, serve read traffic | No, standby is passive |
| Cross-Region | Yes | No (same Region) |
| Failover | Manual promotion | Automatic (typically 60-120s) |
They solve different problems and are often combined: read replicas for read scaling and Multi-AZ for failover. "Scale read-heavy reporting" -> read replicas; "automatic failover for HA" -> Multi-AZ.
Amazon Aurora
Aurora is an AWS-engineered relational engine compatible with MySQL and PostgreSQL, delivering up to 5x MySQL and 3x PostgreSQL throughput.
| Feature | Detail |
|---|---|
| Storage | 6 copies across 3 AZs, auto-grows 10 GB to 128 TB |
| Durability | Survives loss of 2 copies for writes, 3 for reads |
| Read replicas | Up to 15, typically <10 ms lag, shared storage |
| Failover | Promotes a replica in under 30 seconds |
| Backtrack | Rewind in place to a prior second without a restore |
| Cloning | Copy-on-write clone, instant, no initial storage cost |
Aurora Serverless v2 scales compute in fine increments from 0.5 to 256 ACUs (Aurora Capacity Units) per second of demand - ideal for spiky or multi-tenant workloads where you do not want to size a fixed instance.
Amazon DynamoDB
DynamoDB is a serverless NoSQL key-value and document database with single-digit-millisecond latency at any scale and no servers to manage.
| Feature | Detail |
|---|---|
| Capacity modes | On-Demand (pay-per-request) or Provisioned (RCU/WCU + auto-scaling) |
| Global Tables | Active-active, multi-Region replication |
| DAX | In-memory accelerator delivering microsecond reads |
| Streams | Item-level change feed (trigger Lambda, replicate) |
| TTL | Auto-expire items at no cost |
| PITR | Continuous backups, restore up to 35 days |
Use On-Demand for spiky or new workloads with no capacity planning; use Provisioned with auto-scaling for predictable traffic to lower cost. Add DAX when read-heavy traffic repeatedly reads the same hot items and needs microsecond latency.
Amazon ElastiCache
| Feature | Redis | Memcached |
|---|---|---|
| Data structures | Strings, hashes, lists, sets, sorted sets, streams | Simple key-value |
| Persistence | Yes (snapshots + AOF) | No |
| Replication / failover | Multi-AZ with automatic failover | None |
| Pub/Sub, backup | Yes | No |
| Threading | Single-threaded per shard | Multi-threaded |
Choose Redis when you need replication, persistence, failover, or rich data types (leaderboards, sessions, real-time analytics). Choose Memcached for a simple, horizontally scalable, multi-threaded cache where losing the cache is acceptable.
Other Purpose-Built Databases
| Service | Type | Use case |
|---|---|---|
| Redshift | Columnar warehouse (OLAP) | BI/analytics on terabytes-petabytes |
| Neptune | Graph | Social graphs, fraud detection, knowledge graphs |
| DocumentDB | MongoDB-compatible document | Catalogs, content management, profiles |
| Keyspaces | Cassandra-compatible wide-column | Time-series, high-write IoT |
| Timestream | Time-series | IoT and DevOps metrics |
| QLDB | Immutable ledger | Audit trails, financial records |
| MemoryDB | Durable Redis-compatible | Primary database with in-memory speed |
On the Exam: "Generate complex BI reports over huge historical data" -> Redshift (OLAP), NOT RDS/Aurora (OLTP). "Single-digit-ms key lookups at unpredictable scale" -> DynamoDB. "Detect fraud via relationship traversal" -> Neptune.
Worked Scenario: Combining HA and Read Scaling
A production PostgreSQL workload on RDS suffers two problems: read-heavy reporting queries slow the primary, and a recent AZ event caused downtime. The correct design addresses each with a different feature rather than one tool. Deploy Multi-AZ to get a synchronous standby with automatic failover (typically 60-120 seconds) for high availability, and separately add read replicas to offload reporting traffic from the primary. These are complementary, not alternatives - a frequent exam trap is to assume Multi-AZ also serves read traffic, but the Multi-AZ standby is passive and unreadable.
If the same workload later needs higher performance and up to 15 fast replicas, migrating to Aurora (MySQL/PostgreSQL-compatible) is the natural next step.
Common Traps to Avoid
- Multi-AZ is not read scaling. The standby cannot serve reads; use read replicas for read scaling and Multi-AZ for failover. Combine them when you need both.
- Redshift for OLTP. Redshift is a columnar OLAP warehouse for analytics; never pick it for high-volume transactional reads/writes - that is RDS, Aurora, or DynamoDB.
- DynamoDB for relational joins. If the question requires complex joins, transactions across many tables, or ad-hoc SQL, that is relational (RDS/Aurora), not DynamoDB.
- Memcached when persistence or failover is required. Memcached has no replication, failover, or persistence; ElastiCache for Redis provides all three.
- Aurora Serverless v2 minimum. Serverless v2 scales down to 0.5 ACU but not to zero, so an idle workload still incurs a small floor charge - factor that into very spiky or dev/test cost estimates.
A SaaS application needs a relational database that automatically grows storage, offers up to 15 low-lag read replicas, fails over in seconds, and replicates data across three Availability Zones. Which service best fits?
A real-time gaming leaderboard needs single-digit-millisecond writes that drop to microseconds for repeated reads of the hottest entries, scaling automatically with unpredictable traffic. Which combination fits?
An application needs an in-memory caching layer that survives a node failure through automatic Multi-AZ failover and can persist its dataset to disk. Which choice meets these requirements?