Episode 3. RDS and Aurora. Day 3. Protect this day. This is your highest return on investment, because the engines are PostgreSQL and MySQL. You already know the engines.

Key facts. RDS Multi AZ uses a standby in another zone, synchronously replicated. The standby is not readable. Read replicas scale reads with asynchronous replication. Aurora separates storage from compute: six copies of data across three AZs, quorum writes of four of six, quorum reads of three of six. Aurora endpoints: cluster writer plus reader, with failover typically under thirty seconds.

Connectivity is where most cases live. Options: VPC subnets and security groups, IAM database authentication, Kerberos, SSL modes, RDS Proxy, and parameter groups. Memorize this checklist order: I A M, then security group routing, then Proxy, then S S L, then connection limits, then pool math.

Scenario 1. The highest probability prompt in your interview. Our RDS PostgreSQL instance was fine yesterday. Today the app is timing out and queries are ten times slower. Nothing changed on our side. Help.

Understand. Ask: all app tiers or one service? All queries or a subset? Exact onset time, to the minute. Any deploys, traffic change, or AWS maintenance, even if the customer says nothing changed? Full outage or degradation? Is an SLO at risk?

Prepare. Say the data in order. Instance configuration. CPU, memory, connections versus max connections, disk I O. Performance Insights top SQL. pg_stat_statements. EXPLAIN with ANALYZE and BUFFERS on the worst query. CloudWatch logs and Enhanced Monitoring for failover or errors. Recent maintenance events.

Say your translation line: Same instinct as AWR and ASH: top SQL, waits, contention, different telemetry.

Identify. Rank the hypotheses. One: connection saturation or pooling failure. Two: one bad query, a missing index, statistics drift, or autovacuum lag causing bloat. Three: resource saturation from traffic or a batch job. Four: a recent failover or maintenance changing the primary or parameters. If the customer is down, mitigate first: shed load, kill the runaway query, adjust the pool carefully. Root cause in parallel.

Support. Success: p95 latency and timeout rate back to baseline for twenty four hours, connection headroom above twenty percent, and an alert on connections and top query latency.

Scenario 2: too many connections after a migration. Do the math first. Replicas times pool size, compared to max connections. Ten pods with a pool of fifty each is five hundred connections. If max connections is four hundred, the math is the bug. Say: I'd do the connection math first, replicas times pool size against max connections, before recommending a bigger instance. Fix with RDS Proxy, correct idle and lifetime settings, and only then consider a larger class.

Replica lag on Aurora: check the AuroraReplicaLag metric, the ReplicaLag on MySQL, plus long running transactions blocking replay on the reader.

Your Day 3 lab: create a small PostgreSQL instance, connect two ways, force a failover, run pgbench, and read Performance Insights. Delete the instance the same day.

Tomorrow, Episode 4: Aurora DSQL and Limitless. Distributed SQL, the hardest topic on the loop. Pause and say it. Understand. Prepare. Identify. Support.