Amazon RDS
Amazon RDS (Relational Database Service) runs ordinary relational databases for you. You bring the schema, queries, and data; AWS runs the server, patches it, takes backups, streams transaction logs for point-in-time recovery, and replaces failed hardware. Launched in 2009, it supports six engines — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2 — each running the real vendor software, so existing applications work unchanged.
From the application's view RDS is just a hostname. You keep responsibility for the schema, indexes, queries, network rules, IAM, the encryption choice, and version upgrades; AWS takes the operational chores off your plate. Aurora, the AWS-native engine in the same family, has its own page.
Instance Classes and Storage
Instance classes mirror EC2: T for dev and test, M for moderate general-purpose load, and R — the memory-heavy default for production OLTP. Storage is gp3 (the default), io1/io2 Provisioned IOPS for low, predictable latency, or legacy magnetic (avoid). Storage auto-scaling grows the volume to a cap you set, but it can never shrink.
High Availability with Multi-AZ
RDS offers two Multi-AZ shapes. The classic Multi-AZ DB instance keeps a synchronous standby in another AZ that is invisible until failover (60–120 seconds). The newer Multi-AZ DB cluster runs one writer and two readable standbys across three AZs, fails over in under 35 seconds, and is MySQL/PostgreSQL only.
Multi-AZ DB instanceclassic — broad engine supportMulti-AZ DB clusterMySQL / PostgreSQL onlyFailover works the same in both: AWS detects the failure, promotes a standby, and swings the endpoint's DNS to the new primary. Open connections drop during the swing, so the application needs basic retry logic.
Read Replicas
Read Replicas are a separate feature that scales reads, not availability. The primary asynchronously streams changes to up to fifteen replicas (MySQL/MariaDB/PostgreSQL), each its own instance with its own endpoint, optionally in another Region for DR or local reads.
Replica lag is real — usually milliseconds, but it grows under heavy writes — so a replica read can return slightly stale data. Do not use a replica for read-your-own-write flows. A replica can also be promoted to a standalone primary for migration or sharding.
Backups and Security
Automated backups plus continuous transaction logs give point-in-time recovery to any second in a 1–35-day window (default 7); manual snapshots live until you delete them and survive instance deletion. A restore always creates a new instance — RDS never overwrites in place.
Most security work is yours: put the instance in a private subnet, allow only the app's security group on the engine port, and turn on encryption at rest at creation (you cannot add it later without a snapshot-and-restore). Prefer IAM database authentication for MySQL/PostgreSQL and let RDS manage the master password rather than committing it to config.
Operational Features and Pricing
Performance Insights breaks load down by wait event and top SQL — the first stop when the database is slow, since most slow databases are not CPU-bound. RDS Proxy pools connections in front of the database, essential for Lambda traffic, and speeds failover. Blue/Green Deployments stage major version upgrades on a synced green copy before a seconds-long switch.
RDS bills per second of instance time plus storage, with only two pricing models: On-Demand and Reserved DB Instances (up to ~60% off) — no Spot, no Savings Plans. Multi-AZ roughly doubles instance cost (~3× for the cluster shape); budget for it in production, not dev.
Multi-AZ — high availability — a standby (or readable standbys in the cluster shape) that takes over on failure. Not primarily for read scaling.
Read Replicas — read scaling — asynchronous copies serving read-only queries. Not automatic failover, and replica reads can be stale.
Multi-AZ DB cluster — both at once on MySQL/PostgreSQL: readable standbys plus sub-35-second failover.
- Assuming the classic Multi-AZ standby serves reads — it is invisible until failover. Use a Multi-AZ cluster or Read Replicas for readable copies.
- Opening the database port to
0.0.0.0/0— put RDS in a private subnet and allow only the application's security group on the engine port. - Forgetting to enable encryption at rest at creation — you cannot turn it on later without snapshot, encrypted-copy, and restore.
- Reading from a Read Replica in a read-your-own-write flow — asynchronous lag means the user may not see their own change.
- Running Lambda against RDS without RDS Proxy — many short-lived connections eventually exhaust the database's connection limit.
- Upgrading a major engine version in place instead of using Blue/Green Deployments to test the green copy first.
- Run Multi-AZ in production; reserve single-AZ for dev and test.
- Encrypt at rest from day one and force TLS in transit via a parameter group.
- Let RDS manage the master password or store it in Secrets Manager — never commit it to config.
- Set backup retention to at least 7 days (35 for regulated data) and test a restore on a schedule.
- Put RDS Proxy in front of Lambda and other high-connection-churn clients.
- Watch Performance Insights wait events, not just CPU, when diagnosing slow queries.
Knowledge Check
In a classic RDS Multi-AZ DB instance deployment, what role does the standby play in normal operation?
- None visible — it is a synchronous standby that only takes over on failover; it does not serve reads
- It actively serves read-only queries to help scale out the read workload
- It runs a different database engine version on the standby so that you can test upcoming upgrades against it
- It accepts writes concurrently alongside the primary in an active-active pair
Why should a Read Replica not be used for a read-your-own-write flow?
- Replication is asynchronous, so the replica may not yet reflect the user's just-committed write
- Read Replicas deliberately reject any reads that come from the very same user who just wrote the data
- Read Replicas are write-only endpoints and never serve reads
- Read Replicas always lag the primary by exactly 35 seconds by design
A Lambda function under load keeps exhausting the RDS connection limit. What fixes this?
- RDS Proxy — it pools and shares connections in front of the database
- Switching the whole application database endpoint over to a Read Replica
- Enabling Multi-AZ for synchronous standby failover
- Increasing the automated backup retention window to its maximum
What is a constraint of RDS encryption at rest?
- It must be enabled at instance creation; adding it later requires snapshot, encrypted copy, and restore
- It can only ever be toggled on or off during the database's scheduled weekly maintenance window, never any sooner
- It is simply not supported on the PostgreSQL engine at all
- It forces the encrypted instance permanently into single-AZ mode
Which pricing models does RDS offer?
- On-Demand and Reserved DB Instances only — no Spot and no Savings Plans
- On-Demand instances, Spot instances, and Compute Savings Plans
- A single flat monthly subscription fee charged per database engine you run
- Strictly per-query billing measured by rows returned
You got correct