RDS and DynamoDB
6 pages · ~4 min✓ Reviewed
Builds on S3. Next up: Lambda and Serverless.
RDS Engines, Multi-AZ and Read Replicas
1. What RDS Is
- Managed relational DB, no OS or SSH access
- MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2
- Aurora: MySQL/PostgreSQL-compatible, 6 copies across 3 AZs, grows to 256 TiB
2. Multi-AZ vs Read Replica
| Multi-AZ | Read replica | |
|---|---|---|
| Replication | Synchronous | Asynchronous |
| Scope | Same Region | Can be cross-Region |
| Purpose | HA / DR | Read scaling |
| Reads | None from standby | Own endpoint |
| Failover | Automatic | None, promote it |
- Primary fails
- DNS flipssame endpoint
- Standby serves~1-2 min
- Multi-AZ DB cluster (two readable standbys) is the exception: standbys serve reads
- Replicas: up to 15 (MySQL/PostgreSQL/MariaDB, Aurora), 5 (Oracle, SQL Server)
- Replica can be promoted to a standalone DB; lag is possible
3. Mistakes
- Counting a replica as your failover
- Sending writes to a replica
- Expecting strictly fresh async reads
4. Interview Point
- Multi-AZ for scaling? No, HA only; standby serves no reads
- Cross-Region read DR? Cross-Region read replica
- Stale replica read? Async replication lag
- Endpoint on failover? Same DNS name flips to standby
RDS Backups and Recovery
1. Automated vs Manual
| Automated | Manual snapshot | |
|---|---|---|
| Made by | Daily snapshot + logs | You |
| Retention | 1-35 days (default 7) | Until you delete |
| DB deleted | Removed unless retained | Survives |
- PITR restores to any second in the window
- Retention
0turns automated backups off
2. Restore and Copy
- Snapshot or PITR
- New instance
- New endpoint
- Repoint app
- Snapshots copy across Regions
- Snapshots share across accounts
- Encryption cannot be removed from a DB
Encrypt an unencrypted DB
- 1Snapshot
- 2Copy with KMS key
- 3Restore the copy
3. Common Mistakes
- Expecting an in-place restore
- Relying on automated backups after deleting the DB
- Disabling backups on a source with read replicas
Restore never overwrites
Every restore makes a new instance with a new endpoint. Repoint the app, then retire the old DB.
DynamoDB Tables, Keys and GSIs
1. Keys
- Serverless key-value/document NoSQL, single-digit-ms latency
- Item limit 400 KB
- Primary key: partition key, or partition + sort key
- Partition key is hashed to pick the partition
- Good: high-cardinality, evenly accessed key
- Bad:
statusor date → hot partition, throttling
2. Query vs Scan
- Sort key orders items in a partition
- Query: one partition key, plus
begins_with,between, ordering - Scan: whole table, slow, costly, avoid in production
python
table.query( KeyConditionExpression=Key('pk').eq('u1') & Key('sk').begins_with('ORDER#'))
one partition, sort-key prefix
3. GSI vs LSI
| GSI | LSI | |
|---|---|---|
| Keys | New partition + sort | Same partition, new sort |
| Created | Anytime | Table creation only |
| Limits | 20; own capacity; eventually consistent only | 5; 10 GB per partition |
4. Interview Point
- Non-key attribute? Add a GSI on it
- Query vs Scan? One partition key vs whole table
- GSI vs LSI? Anytime and 20 vs creation-only and 5
- Hot partition? High-cardinality, evenly accessed partition key
Capacity Modes and Choosing RDS vs DynamoDB
1. Capacity Modes
| On-demand | Provisioned | |
|---|---|---|
| Pay | per request | set RCU + WCU |
| Planning | none, absorbs spikes | auto scaling available |
| Best for | new or unpredictable traffic | steady, cheaper |
- 1 RCU = one strongly consistent 4 KB read/s (two eventually consistent)
- 1 WCU = one 1 KB write/s
- 100 strong reads of 8 KB/s = 2 RCU each = 200 RCU
- Provisioned → on-demand: 4 times per rolling 24 h; back: any time
- Over limit:
ProvisionedThroughputExceededException, retry with backoff
2. RDS or DynamoDB
| RDS | DynamoDB | |
|---|---|---|
| Queries | joins, ad-hoc SQL | known access patterns, key lookups |
| Transactions | large, complex relational | ACID, up to 100 items / 4 MB |
| Fit | existing engine compatibility | massive scale, predictable latency |
- Design the DynamoDB table around its queries
3. Common Mistake
Relational schema
Modelling DynamoDB like relational tables forces Scans. Design keys from the queries first.
AWS Databases Cheat Sheet
1. RDS: HA, Replicas, Backups
| Multi-AZ | Read replica | |
|---|---|---|
| Copy | Synchronous | Asynchronous |
| Goal | HA, auto failover | Read scaling |
| Reads | None | Yes |
| Region | Same | Cross-Region |
| Promotable | No | Yes |
- Automated backups: 1-35 days (default 7), PITR
- Manual snapshots persist after delete
- Every restore makes a new instance
2. DynamoDB Keys
- Partition key hashed: keep it even
- Sort key enables Query ranges; avoid
Scan - GSI: add anytime, eventually consistent
- LSI: only at table creation
3. Capacity and Choice
| On-demand | Provisioned | |
|---|---|---|
| Traffic | Unpredictable | Steady |
| Pay | Per request | Set RCU/WCU |
- 1 RCU = 4 KB strongly consistent read/s
- 1 WCU = 1 KB write/s
- RDS: joins, ad-hoc SQL; DynamoDB: key lookups at scale
4. Interview Point
- Multi-AZ vs replica? Sync failover vs async read scaling
- GSI vs LSI? Any keys, anytime vs same partition key, creation only
- RDS or DynamoDB? Joins and SQL vs known key access at scale
Check yourself
An RDS Multi-AZ instance has slow reports. You expect the standby in the other AZ to share the read load. Will it?
- No: the standby serves no reads; it only waits for failover.
- Add a read replica for reads (async, so results may lag).
A bad DELETE ran 10 minutes ago. Automated backups are on. What do you do, and what happens to the endpoint?
- Run a point-in-time restore to just before the DELETE.
- It creates a new instance with a new endpoint, so repoint the app. The old one is untouched.
How many RCUs for 100 strongly consistent reads per second of 8 KB items?
- 8 KB is 2 units of 4 KB, so 100 × 2 = 200 RCU.
- Eventually consistent would need only 100.