RDS Deployment Options¶

Single-AZ  →  Multi-AZ Instance  →  Multi-AZ Cluster  →  Aurora
 (Basic)        (HA only)           (HA + Read Scale)   (Max perf)

┌──────────────────────────┐
│       AZ-1               │
│  ┌─────────────────┐     │
│  │  DB Instance    │     │
│  │  Read + Write   │     │
│  └─────────────────┘     │
└──────────────────────────┘

┌─────────────────┐         ┌─────────────────┐
│      AZ-1       │         │      AZ-2        │
│                 │         │                  │
│ ┌─────────────┐ │ ──sync──→ ┌─────────────┐ │
│ │   Primary   │ │  repl.  │ │   Standby   │ │
│ │ Read+Write  │ │         │ │  PASSIVE ❌  │ │
│ └─────────────┘ │         │ └─────────────┘ │
└─────────────────┘         └─────────────────┘
         ↑
  Single endpoint (DNS)
  points here always

App writes → Primary receives → MUST sync to Standby → write acknowledged
(write blocked until Standby confirms receipt)
Typical additional write latency: 2–5ms
Benefit: zero data loss — Standby always has every committed transaction

Step 1: RDS detects Primary failure (AZ down, storage failure, OS crash…)
Step 2: Standby promoted to NEW Primary
Step 3: RDS updates DNS record → CNAME flips to new Primary's IP
Step 4: Your app reconnects using same endpoint string (no code change)
Step 5: Old Primary (if recoverable) becomes new Standby
        Old Primary does NOT come back as Primary
Failover time: 60–120 seconds [docs.aws.amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html)

# Test your application's failover handling without a real outage
aws rds reboot-db-instance \
  --db-instance-identifier my-prod-db \
  --force-failover
# → RDS fails over to standby, ~60-120s downtime
# → Use this in test environments regularly to validate app resilience

┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
│      AZ-1       │   │      AZ-2       │   │      AZ-3       │
│                 │   │                 │   │                 │
│ ┌─────────────┐ │   │ ┌─────────────┐ │   │ ┌─────────────┐ │
│ │   Writer    │─┼───┼→│  Reader-1   │ │   │ │  Reader-2   │ │
│ │ Read+Write  │ │   │ │  Readable ✅ │ │  │ │  Readable ✅ │ │
│ └─────────────┘ │   │ └─────────────┘ │   │ └─────────────┘ │
└─────────────────┘   └─────────────────┘   └─────────────────┘
         ↑                     ↑
  Writer endpoint        Reader endpoint
  (write traffic)        (load-balanced reads)

App writes → Writer → MUST acknowledge by at least 1 Reader → confirmed
(not all readers, but at least one must confirm → faster than full sync)
PostgreSQL cluster: reader with lowest lag is promoted on failover
MySQL cluster: both readers must apply outstanding transactions

Writer fails
  → RDS selects reader with least replication lag
  → Promotes it to new Writer
  → Reader endpoint automatically adjusts
  → Cluster endpoint points to new Writer

Failover time: < 35 seconds [docs.aws.amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts-failover.html)
(vs 60–120s for Multi-AZ Instance)

MySQL: BOTH remaining readers apply outstanding transactions → then promote
PostgreSQL: reader with LOWEST lag promoted → applies remaining transactions

The most common confusion:
  ❌ "My Multi-AZ standby can serve reads during peak traffic"
  ✅ Standby is invisible to your app — it only appears after a failover

  ❌ "Read Replica will automatically become primary if primary fails"
  ✅ Read Replica promotion is a MANUAL action you must trigger

RPO (Recovery Point Objective) = How much DATA can you lose?
  → Measured in time: "we can tolerate data loss up to X ago"

RTO (Recovery Time Objective) = How fast must you RECOVER?
  → Measured in time: "system must be back within X"

Single-AZ:
  RPO: last automated backup (up to 24h loss)
  RTO: 30 min – several hours (manual intervention)

Multi-AZ Instance:
  RPO: ~0 (synchronous — no committed data lost)
  RTO: 60–120s (DNS flip + reconnection) [docs.aws.amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html)

Multi-AZ Cluster:
  RPO: ~0 (semi-synchronous — at least 1 reader confirmed)
  RTO: < 35s [docs.aws.amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts-failover.html)

Aurora Multi-AZ:
  RPO: ~0 (6 copies across 3 AZs)
  RTO: ~25s (Aurora optimized failover)

Aurora Global Database:
  RPO: < 1s (storage-level replication)
  RTO: < 1 min (cross-region promotion)

1. TCP connections to old Primary IP → forcefully closed
2. In-flight transactions → rolled back
3. DNS cache → may still point to old IP for TTL duration

# 1. Always use the DNS endpoint (never hardcode IP)
DB_HOST = "my-db.cluster-xyz.us-east-1.rds.amazonaws.com"
# 2. Set short DNS TTL caching (Java JVM caches DNS by default = problem)
# Java fix:
networkaddress.cache.ttl=1  # in java.security
# 3. Implement retry logic with exponential backoff
import time
def connect_with_retry(max_attempts=5):
    for attempt in range(max_attempts):
        try:
            return db.connect(host=DB_HOST)
        except OperationalError:
            wait = 2 ** attempt  # 1, 2, 4, 8, 16 seconds
            time.sleep(wait)
# 4. Use RDS Proxy — handles reconnection transparently
# App → RDS Proxy (maintains pool) → new Primary
# App sees no connection disruption during failover ✅

Start here:
  Is this dev/test with no downtime requirements?
  → Single-AZ (cheapest)

  Is downtime of 1-2 minutes acceptable?
  → Multi-AZ Instance (HA, no read scaling)

  Need read scaling + < 35s failover?
  → Multi-AZ Cluster

  Need max performance + < 25s failover + auto storage scaling + serverless?
  → Aurora Multi-AZ (MySQL or PostgreSQL compatible)

  Need < 1s RPO globally across multiple regions?
  → Aurora Global Database