Databases — RDS

The core vocabulary, Multi-AZ vs read replicas, connections and monitoring, and failover-aware design

Automated backups vs manual snapshotscontinuous window vs a deliberate, independently-retained copy
Multi-AZ = availability, replicas = read scalinga single-standby Multi-AZ standby never serves reads
Connection limits ≠ slow queriestwo different problems, two different fixes
Reconnect via hostname, retry with backoffnever cache the resolved IP across a failover

1.RDS Core Vocabulary

RDS runs a managed relational database (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, Db2) — AWS handles patching, backups, and failure detection/recovery, while you own query tuning and schema design. A DB instance class sets compute/memory; storage is separate, EBS-backed. Automated backups happen continuously (point-in-time recovery); a snapshot is a manually-triggered, durable point-in-time copy you control the lifecycle of.

Key features

DB engine: MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, or Db2 — each with its own supported feature set
DB instance class: sets compute/memory (general purpose, memory-optimized, compute-optimized, burstable) — separate from storage
Automated backups: continuous, enable point-in-time recovery within a retention window
Manual snapshots: durable point-in-time copies you trigger and control the retention of, independent of the automated backup window
Parameter groups control engine behavior (e.g. max_connections); option groups add engine-specific features — both apply across instances using the group
AWS is responsible for backups, patching, and failure detection/recovery; query tuning and schema design remain the customer's responsibility

What RDS manages vs what stays yours

Your responsibility

query tuning, schema design, indexes

DB instance

engine + instance class + storage

AWS-managed

patching, backups, failure detection/recovery

Signature

Automated backups (continuous, windowed) vs manual snapshot (deliberate, independent)

RDS manages patching, backups, and failure detection/recovery; query tuning and schema design stay yours. Automated backups give continuous point-in-time recovery within a retention window; a manual snapshot is a deliberately-triggered, independently-retained point-in-time copy — take one before risky changes.

2.Multi-AZ vs Read Replicas

Multi-AZ is for availability — a synchronous standby RDS automatically fails over to. Read replicas are for read scaling — asynchronous copies you query directly to offload read traffic. A Multi-AZ **DB instance** deployment (one standby) does NOT serve reads at all; a Multi-AZ **DB cluster** deployment (two standbys, a newer option) can serve reads from its readers.

Key features

Multi-AZ DB instance deployment (one standby): synchronous replication, automatic failover — standby does NOT serve read traffic
Multi-AZ DB cluster deployment (two standbys, newer): synchronous replication, automatic failover, AND readers CAN serve read traffic
Read replicas: asynchronous replication, built specifically for read scaling — you query them directly
A read replica is not automatically part of failover — promoting one to primary is a separate, manual (or scripted) action
Read replicas can be cross-Region, useful for both read-latency reduction and disaster-recovery patterns

Multi-AZ DB instance vs read replica

Multi-AZ (single standby)

Synchronous replication
Automatic failover target
Standby does NOT serve reads
Purpose: availability

Read replica

Asynchronous replication
Not an automatic failover target
Serves read queries directly
Purpose: read scaling

Signature

Multi-AZ (availability) vs read replicas (read scaling)

Multi-AZ (single standby) = availability only, standby never serves reads. Multi-AZ DB cluster (two standbys, newer) CAN serve reads. Read replicas = read scaling via asynchronous copies, not an automatic failover target — promotion is a separate action.

3.Connections, Pooling, and Database Monitoring

A DB instance has a hard connection limit tied to its instance class — an app opening a new connection per request (rather than pooling) can exhaust it under load, unrelated to any query performance problem. RDS Performance Insights and Enhanced Monitoring surface slow queries and OS-level metrics AWS does not expose by default; query tuning and index design remain the customer's job.

Key features

Each DB instance class has a maximum connection count, exposed as a tunable parameter but ultimately bounded by instance memory
Connection pooling reuses a bounded set of connections across requests instead of opening one per request
RDS Performance Insights surfaces database load and top queries by wait time — a query-level diagnostic tool
Enhanced Monitoring exposes real-time OS-level metrics (CPU, memory, disk, processes) that CloudWatch's standard RDS metrics do not
Index design, query tuning, and schema decisions remain the customer's responsibility under the RDS shared responsibility model — RDS manages the infrastructure, not the SQL

Command

text

Connection exhaustion: too many open connections, unrelated to query speed
Slow query: query itself is expensive — needs an index/rewrite, not more connections

Connection exhaustion (too many open connections) and slow queries (an expensive query itself) are different problems with different fixes — pooling for the former, indexing/query tuning (informed by Performance Insights) for the latter. RDS manages the infrastructure; query tuning stays the customer's job.

4.Designing for Failover and Maintenance

A Multi-AZ failover (automatic or maintenance-triggered) changes which endpoint IP the DB instance's DNS name resolves to — the application must reconnect rather than hold a single cached connection or IP forever. A maintenance window is when RDS applies patches that may require a brief outage or failover; scheduling it deliberately, and retrying transient connection failures, is what keeps it a non-event.

Key features

Failover changes which underlying IP the DB endpoint hostname resolves to — applications must not cache the resolved IP indefinitely
A maintenance window is a configurable weekly time slot when RDS applies pending patches, which can involve a brief outage or failover
Connection retry logic with backoff is what turns a failover from an outage into a brief, invisible blip for the application
Multi-AZ specifically reduces (but does not eliminate) the length of a maintenance-triggered outage, since patching can often happen on the standby first

Command

text

Application: use the DB endpoint hostname, retry transient connection errors with backoff — never cache the resolved IP indefinitely

Failover repoints the DB endpoint's DNS to a new IP — never cache that IP indefinitely. Retry transient connection failures with backoff so a brief, expected failover (or maintenance-window patch) stays invisible to users instead of becoming an outage.

Spotted a mistake on this page? Tell us.

Read Sheet