RDS (non-Aurora)

RDS gives you three deployment topologies, and they differ in more than an HA checkbox. Each one is really a choice of replication layer and node count.

Single-AZ is one instance with no standby behind it. There is no automated failover at all. If the instance fails, your only recovery path is restoring from a snapshot.

Multi-AZ Instance adds one passive standby in a second AZ. Its replication happens at the EBS block layer, underneath the database engine: a commit does not return until both AZs have the write on disk. The standby's engine sits idle, though. It does no work until promotion.

Multi-AZ DB Cluster goes further, and it exists only for MySQL and PostgreSQL. It gives you two active, readable standbys, using Raft-consensus semi-synchronous replication over local NVMe drives. A commit needs only one standby to acknowledge. And because both standbys run warm engines that continuously apply the replication stream, promotion skips crash recovery entirely.

RDS storage is not a single billing line. You pick a storage type and a volume size per instance, and the two storage families price IOPS in completely different ways.

gp3 is the default family. It bundles a free baseline of 3,000 IOPS and 125 MiB/s into the base storage rate, which is $0.115/GB-month on RDS. That is a distinct, higher rate than EBS gp3's $0.08/GB-month; RDS storage is a different service entirely. Above the baseline, gp3 charges $0.02 per additional provisioned IOPS-month.

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 of $0.125/GB-month.

Run the numbers at 10,000 IOPS on a 1TB volume. gp3 costs roughly $255/month: $115 for storage plus $140 for the 7,000 IOPS above its free baseline. io1 costs roughly $1,125/month: $125 for storage plus $1,000 for all 10,000 IOPS billed from zero. The identical IOPS number prices out about 4.4x apart, because io1 charges 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 it: "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 here. This differs from EBS's io2, which uses tiered per-IOPS pricing that doesn't apply to RDS.

On the open-source engines, scaling compute is just a bigger instance bill. On Oracle and SQL Server, the same resize is a licensing decision wearing a compute decision's clothes.

Oracle first. License Included — where AWS holds the license — is restricted to Standard Edition 2 only. Enterprise Edition requires Bring Your Own License, priced per physical core via Oracle's Core Factor Table. A vCPU count has to be translated back to physical cores before you know what you are actually licensing: a db.m5.xlarge's 4 vCPUs map to 2 physical cores.

SQL Server splits along the same seam. Enterprise Edition HA runs on Always On Availability Groups. Standard Edition is restricted to Basic Availability Groups or mirroring, which caps you out of multi-database configurations and secondary read access — no matter how much compute you throw at it.

Read replica capacity is not one RDS-wide number. Each engine has its own ceiling, and each ceiling exists because of the replication technology underneath it.

MySQL, MariaDB, and PostgreSQL support up to 15 read replicas, using the engines' native asynchronous replication (binlog or physical/logical streaming). Oracle and SQL Server cap at 5. Oracle replicates through Data Guard, SQL Server through Always On Distributed Availability Groups. Those are heavier, more tightly-coupled mechanisms, and they do not scale to the same replica count by design. The limit is the technology, not an arbitrary AWS quota.

SQL Server replicas carry one additional constraint: they require instance classes with at least 4 vCPUs, and they 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 when promotion starts.

The Multi-AZ Instance 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 the instance can serve traffic. That pushes observed failover out to 60–120 seconds.

The Multi-AZ DB Cluster standbys are different. They run warm engines that continuously apply the replication stream, so promotion skips crash recovery entirely and lands at under 35 seconds.

Steady-state replica lag has its own causes, and they are engine-specific. MySQL and MariaDB replicas apply the replication stream through a single-threaded applier. A write burst that the primary handles with many threads gets serialized into one thread on the replica. The bottleneck is architectural. Sizing does not fix it.

SQL Server's lag comes from a locking interaction. Read queries on a replica hold Schema Stability (Sch-S) locks. 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 long-running Sch-S holder will block that lock, and replication for that entire database stalls until the read query finishes.

RDS gives every instance a stable-looking DNS CNAME endpoint. The stability is an illusion, and it is maintained by two things: a 5-second TTL, and an assumption that clients actually re-resolve the name.

The mechanism matters here. Your application connects to a hostname, DNS resolves it to an IP, and traffic lands on whatever instance holds that IP. During failover, RDS updates the CNAME to point at the newly-promoted instance's IP. The client only picks that up if its DNS resolution path respects the 5-second TTL instead of caching the old answer indefinitely.

IAM Database Authentication is available only on MySQL, MariaDB, and PostgreSQL. On Oracle and SQL Server it does not exist at all.

Where it is available, it replaces the password in the connection handshake and nothing else. 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.

From there, nothing changes. 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.

A major version upgrade alters on-disk data structures and system catalogs. That is why it cannot be applied like a minor patch.

An inline major upgrade takes the instance offline for 15 minutes to several hours, depending on object count. 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. The idea: stand up a synced "Green" environment, then cut over via DNS at switchover. But the replication mechanism underneath differs by engine, and the differences create real, engine-specific prerequisites.

MySQL uses native binary log replication, with no primary-key requirement. PostgreSQL uses physical replication for minor-version Blue/Green and logical replication for major-version upgrades. PostgreSQL's logical replication has a hard requirement that MySQL's binlog replication doesn't.