RDS (non-Aurora)

RDS deployment topology isn't an HA toggle — it's a choice of replication layer and node count. Single-AZ has no automated failover at all (restore from snapshot is the only recovery path). Multi-AZ Instance adds one passive standby, replicated synchronously at the EBS block layer — a commit doesn't return until both AZs have the write on disk, but the standby's database engine sits idle until promoted. Multi-AZ DB Cluster (MySQL/PostgreSQL only) adds two active readable standbys using Raft-consensus semi-synchronous replication over local NVMe — a commit needs only one standby to acknowledge, and because both standbys run warm engines continuously applying the replication stream, promotion skips crash recovery entirely.

RDS storage isn't one billing line — it's a provisioning curve you pick per volume, and the two families price IOPS completely differently. gp3 bundles a free baseline of 3,000 IOPS and 125 MiB/s into the base storage rate ($0.115/GB-month on RDS — a distinct, higher rate than EBS gp3's $0.08/GB-month, which is a different service entirely), then charges $0.02 per additional provisioned IOPS-month above that baseline. Provisioned IOPS io1 has no free baseline at all — every IOPS is billed from zero, at $0.10/IOPS-month, on top of a higher base storage rate ($0.125/GB-month). At 10,000 IOPS on a 1TB volume: gp3 costs roughly $255/month ($115 storage + $140 for 7,000 additional IOPS above baseline), while io1 costs roughly $1,125/month ($125 storage + $1,000 for 10,000 IOPS billed from zero) — io1 runs about 4.4x more expensive for the identical IOPS number, because you're paying for every IOPS instead of just the ones above the free tier. io2 Block Express bills at the identical flat rate to io1 on RDS — AWS's own launch announcement confirms "io1 volumes and io2 Block Express storage volumes are billed at the same rate" — so io2's extra durability and latency come at no per-IOPS premium over io1; this differs from EBS's io2, which uses tiered per-IOPS pricing that doesn't apply here.

On open-source engines, scaling compute is just a bigger instance bill. On Oracle and SQL Server, it's a licensing decision wearing a compute decision's clothes. Oracle License Included is restricted to Standard Edition 2 only — Enterprise Edition requires Bring Your Own License, priced per physical core via Oracle's Core Factor Table, which means a vCPU count has to be translated back to physical cores (a db.m5.xlarge's 4 vCPUs map to 2 physical cores) before you know what you're actually licensing. SQL Server splits similarly: Enterprise Edition HA runs on Always On Availability Groups, while Standard Edition is restricted to Basic Availability Groups or mirroring — which caps you out of multi-database configurations and secondary read access regardless of how much compute you throw at it.

Read replica capacity isn't one RDS number — it's a per-engine ceiling tied to a completely different replication technology underneath. MySQL, MariaDB, and PostgreSQL support up to 15 read replicas using native asynchronous replication (binlog or physical/logical streaming). Oracle and SQL Server cap at 5, using Data Guard and Always On Distributed Availability Groups respectively — heavier, more tightly-coupled replication mechanisms that don't scale to the same replica count by design, not by an arbitrary AWS quota. SQL Server replicas carry an additional constraint: they require instance classes with at least 4 vCPUs and cap at 100 databases per instance, regardless of how much headroom the instance otherwise has.

Multi-AZ Instance failover and Multi-AZ DB Cluster failover differ by exactly one thing: whether the standby's database engine is already running. Multi-AZ Instance's standby replicates at the storage layer only — its engine is inactive until promotion, so promotion means a full crash recovery (replaying write-ahead logs, rolling back uncommitted operations) before it can serve traffic, pushing observed failover to 60–120 seconds. Multi-AZ DB Cluster's standbys run warm engines continuously applying the replication stream, so promotion skips crash recovery entirely, landing at under 35 seconds. Separately from failover, steady-state replica lag has its own engine-specific cause: MySQL/MariaDB replicas apply the replication stream through a single-threaded applier, so a write burst that the primary handles with many threads gets serialized into one thread on the replica — the bottleneck is architectural, not a sizing problem. SQL Server's lag cause is a locking interaction: read queries on a replica hold Schema Stability (Sch-S) locks, and when a DDL statement runs on the primary, the replica's redo thread needs a Schema Modification (Sch-M) lock on the same table to apply it — a lock that a long-running Sch-S holder will block, stalling replication for that entire database until the read query finishes.

RDS gives every instance a stable-looking DNS CNAME endpoint, but the stability is an illusion maintained by a 5-second TTL and an assumption that clients actually re-resolve it. During failover, RDS updates the CNAME to point at the newly-promoted instance's IP — but the client only picks that up if its DNS resolution path actually respects the 5-second TTL rather than caching indefinitely.

IAM Database Authentication is available only on MySQL, MariaDB, and PostgreSQL — it doesn't exist on Oracle or SQL Server on RDS. Where it is available, it replaces the password in the connection handshake, not the authorization model behind it. The client requests a signed IAM (SigV4) token — valid for 15 minutes — via rds:generate-db-auth-token or the SDK, and passes that token as the password on a standard TCP connection. The database engine's IAM auth plugin validates the token's signature against IAM policy, but from there, every SQL grant, role, and privilege is still enforced natively by the database engine exactly as before. IAM auth changes how you prove who you are; it does not change what you're allowed to do once you're in.

Major version upgrades alter on-disk data structures and system catalogs, which is why they can't be applied like a minor patch — an inline major upgrade takes the instance offline for 15 minutes to several hours depending on object count, and there is no automatic rollback if post-upgrade verification fails; reverting means restoring a pre-upgrade snapshot and losing every write since. AWS Blue/Green Deployments exist specifically to avoid this downtime by standing up a synced "Green" environment and cutting over via DNS at switchover — but the replication mechanism underneath differs by engine in ways that create real, engine-specific prerequisites: MySQL uses native binary log replication with no primary-key requirement, while PostgreSQL uses physical replication for minor-version Blue/Green and logical replication for major-version upgrades — and PostgreSQL's logical replication has a hard requirement that MySQL's binlog replication doesn't.