AWS RDS Multi-AZ doubles one instance's price for failover

The workload

Adding Multi-AZ to an RDS database is a configuration choice, not a build task: one setting during creation, after which AWS manages a standby instance automatically. The work that remains is reading AWS's own Multi-AZ documentation, retrieved 16 September 2026, to see which of the two shapes — one standby or two — the application needs, since they carry different failover behavior and cost.

What the documents show

AWS's Multi-AZ documentation states, verified, that a 'Multi-AZ DB instance deployment has one standby DB instance that provides failover support, but doesn't serve read traffic,' while a DB cluster deployment provisions two standbys that 'can also serve read traffic.' Its single-standby page adds, verified, that 'the high availability option isn't a scaling solution for read-only scenarios' — the one-standby shape is for failover, not for spreading read load. On failover speed, AWS's own Multi-AZ feature page states, verified, that the instance shape fails over 'as quickly as 60 seconds,' while the cluster shape fails over 'typically under 35 seconds,' both with zero data loss per AWS's wording — a stated feature claim, not a contractual guarantee, since no uptime percentage is cited here from AWS's separate SLA document. On price, AWS's own rate data behind its RDS for PostgreSQL pricing page prices a db.t3.micro PostgreSQL instance in US East (N. Virginia) at $0.018 per instance-hour Single-AZ versus $0.036 Multi-AZ, verified: exactly double, for that instance class, engine, and region, as retrieved 16 September 2026.

The operating cost

For the db.t3.micro example above, running Multi-AZ instead of Single-AZ for a full month adds, as an editorial estimate applying AWS's per-hour rates across a 730-hour month, roughly $13.14 in added compute cost (the $0.018 hourly difference times 730 hours) before storage or backup charges. AWS's pricing page states the billing components — instance hours, storage, data transfer — but does not publish a universal 'Multi-AZ costs double' rule in prose; the 2x figure comes from one instance class and should not be assumed to hold at every size.

The stop condition

The documentation distinguishes Multi-AZ, an availability feature, from the automated-backup and point-in-time-recovery feature this site has already documented: Multi-AZ protects against an Availability Zone failure interrupting service, while backups protect against data loss, and paying for one does not substitute for the other. The editorial stop condition for the Multi-AZ premium: if brief downtime during failover is tolerable and read replicas are not needed, the one-standby shape's roughly 60-second failover may not justify the cost over backups alone for a low-traffic application; if read scaling matters too, the two-standby cluster shape's faster failover does double duty.

• Would a 60-second failover interruption actually affect this application's users, or does it fail gracefully?
• Does the workload need read replicas badly enough to justify the cluster shape over the single-standby shape?
• Has the exact per-hour rate for this workload's instance class and region been checked, rather than assumed?

Multi-AZ's failover timing is AWS's own stated feature claim; this entry does not restate it as a guaranteed uptime percentage, since that number would come from AWS's separate SLA document, not the pages cited here.