RDS

1What RDS Is

RDS (Relational Database Service) runs a managed instance of a real relational engine (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle) — AWS handles patching, backups, and (optionally) failover, but the database itself is still ordinary Postgres/MySQL underneath; every concept from databases/fundamentals, databases/modeling, and databases/scaling applies unchanged.

aws rds create-db-instance \
  --db-instance-identifier app-db-prod \
  --engine postgres \
  --db-instance-class db.t3.medium \
  --allocated-storage 100 \
  --master-username appadmin \
  --manage-master-user-password \
  --multi-az \
  --db-subnet-group-name app-db-subnet-group \
  --vpc-security-group-ids sg-0db

2Multi-AZ: High Availability, Not Read Scaling

Multi-AZ provisions a synchronous standby replica in a different Availability Zone. Every write is confirmed on both the primary and the standby before RDS acknowledges it back to the application — this is the RDS-managed version of the primary/replica replication pattern from databases/scaling/02-replication, specifically tuned for durability over throughput. If the primary fails, RDS automatically fails over to the standby, typically within about a minute, by flipping a DNS CNAME (the application's connection endpoint never changes).

The standby is not queryable — you cannot send read traffic to it. Multi-AZ exists purely for availability/durability, not for scaling reads.

3Read Replicas: Read Scaling, Not Automatic Failover

A read replica is a separate, queryable copy kept in sync via asynchronous replication — the opposite tradeoff from Multi-AZ's synchronous standby. Applications can point read-heavy queries at one or more replicas to offload the primary, but:

• Replication is asynchronous, so a replica can lag behind the primary by some (usually small) amount — reads from it are eventually consistent, not strongly consistent.
• A read replica does not automatically take over on primary failure; promoting one to a standalone writable instance is a manual (or scripted) action, and it breaks replication with any sibling replicas.
• Read replicas can even live in a different Region, unlike a Multi-AZ standby which is Region-local by definition.

4Multi-AZ vs. Read Replica — the Distinction That Actually Matters

A production database very often runs both: Multi-AZ for HA, plus one or more read replicas of the primary (or in newer RDS engines, of the Multi-AZ deployment itself) for read scaling — the two solve genuinely different problems and are not substitutes for each other.

5Automated Backups and Snapshots

RDS takes a daily automated backup within a configured backup window and continuously archives transaction logs, enabling point-in-time recovery to any second within the retention period (1-35 days). A manual snapshot is a backup you trigger yourself, retained until you explicitly delete it — independent of the automated retention window, useful before a risky schema migration.

6Network Placement

An RDS instance lives inside a DB subnet group — a set of private subnets spanning multiple AZs (from 02-vpc_subnets_route_tables), so Multi-AZ has somewhere to place the standby in a different AZ. By default, RDS instances are not publicly accessible: only resources inside the VPC (or connected via VPN/peering) can reach them, gated further by a security group (09-security_groups) that should allow the database port only from the application tier's security group, never from 0.0.0.0/0.

7Parameter Groups and Option Groups

A DB parameter group holds engine configuration (e.g. max_connections, work_mem) applied to an instance — changing a static parameter requires a reboot, a dynamic one applies immediately. An option group (MySQL/Oracle/SQL Server) enables optional engine features. Both exist so engine tuning is managed declaratively rather than by shelling into the instance — which RDS doesn't even give you OS-level access to.

⚠️ Common Pitfalls

1. Confusing Multi-AZ with read scaling. The standby cannot be queried — provisioning Multi-AZ alone does nothing for read-heavy load; that's what read replicas are for.
2. Assuming read replica data is always current. Asynchronous replication lag means a read immediately after a write can miss that write — a classic read-your-own-writes bug if routed carelessly.
3. Leaving an RDS instance publicly accessible ("just for debugging") — the default and correct posture is private-subnet-only, reached through the application tier's security group.
4. Forgetting that promoting a read replica breaks its replication link — it becomes an independent writable instance, not a drop-in Multi-AZ-style failover target.
5. Sizing storage/IOPS for today's data, not next year's — storage can be scaled up online, but under-provisioned IOPS silently caps query throughput long before disk space runs out.

📋 Quick Reference

aws rds describe-db-instances --db-instance-identifier app-db-prod
aws rds create-db-instance-read-replica --db-instance-identifier app-db-replica-1 --source-db-instance-identifier app-db-prod

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: aws_rds_theory.md · generated by tools/build_lessons.py