High availability databases: what the second node really buys

Quick answer

High availability roughly doubles the database bill on every major managed service: RDS Multi-AZ doubles compute and storage, Cloud SQL HA doubles compute and storage, and Azure Flexible Server zone-redundant HA doubles compute. A db.r6g.xlarge with 1 TB of gp3 goes from about $493 to $986 per month. The decision is an expected-value calculation: HA typically converts a 30 to 90 minute unplanned recovery into a 60 to 120 second failover. If an hour of downtime costs your business $20,000 and you expect 1.5 incidents per year, HA avoids about $30,000 of expected annual loss for $5,900 of annual cost. If an hour costs $200, as in most internal tools, the arithmetic reverses completely.

Every architecture review has the moment where someone asks whether this database needs Multi-AZ, and the conversation resolves on instinct rather than numbers. That is a shame, because it is one of the few infrastructure decisions with a clean expected-value framing.

What HA costs

Configuration	Single	HA	Delta
RDS db.t3.medium, 100 GB	about $61	about $122	$61
RDS db.m6g.large, 500 GB	about $172	about $344	$172
RDS db.r6g.xlarge, 1 TB	about $493	about $986	$493
RDS db.r6g.4xlarge, 4 TB	about $1,972	about $3,944	$1,972
Cloud SQL 4 vCPU / 32 GB, 1 TB	about $454	about $908	$454

There is one additional line people forget: Multi-AZ replication crosses availability zones, and while AWS does not charge for RDS Multi-AZ synchronous replication traffic itself, application traffic reaching a database in another AZ after a failover does incur cross-AZ transfer at $0.01 per GB each way. For a chatty application that is real money during an extended failover state.

What HA actually buys

Be precise about the failure modes HA covers, because it covers fewer than people assume. It covers: host failure, AZ failure, storage failure, and planned maintenance, converting what would be a restore-from-backup event into an automatic failover of roughly 60 to 120 seconds on RDS Multi-AZ, and under 35 seconds on Multi-AZ DB clusters. It does not cover: application bugs that corrupt data (the corruption replicates), accidental table drops (also replicates), region-wide outages, bad schema migrations, credential problems, or a query that takes the database down through resource exhaustion. Those are handled by backups, PITR, and testing, not by a standby node.

Meanwhile, without HA, a failed database instance means restoring from the most recent automated backup and replaying logs, which on a 1 TB database realistically takes 30 to 90 minutes and loses whatever was written after the last usable log position. So the honest framing is: HA converts an occasional 30-to-90-minute outage with possible data loss into an occasional 1-to-2-minute blip.

The expected value calculation

You need three numbers: cost of an hour of downtime, expected frequency of the failures HA covers, and the annual cost of HA.

System	Downtime cost/hr	Incidents/yr	Expected loss avoided	HA cost/yr
Payments API	$20,000	1.5	about $30,000	$5,916
Customer-facing app	$3,000	1.5	about $4,500	$2,064
Internal admin tool	$200	1.5	about $300	$2,064
Staging environment	$0	1.5	$0	$732

The payments API case is not close: HA returns five times its cost. The customer-facing app returns roughly twice its cost, which is a clear yes. The internal admin tool loses money on HA by a factor of seven, and staging is pure waste. A fleet that applies HA uniformly is overspending on the bottom two rows and possibly under-investing elsewhere.

The incident frequency figure deserves scrutiny. Managed database instance failures are genuinely rare; an annualized rate of 1 to 2 events including AWS-initiated maintenance is a reasonable planning number for a single instance, and most of those are maintenance windows that HA makes invisible rather than hardware failures. If your main benefit is avoiding maintenance-window downtime, weigh that against the option of simply scheduling maintenance at 3am on a Sunday.

The middle options

HA is not binary. Several intermediate positions cost less than a full standby:

Option	Cost vs single-AZ	Recovery time
Single-AZ with tested restore runbook	1.0x	30 to 90 minutes
Single-AZ plus a small read replica to promote	1.3x to 1.6x	5 to 15 minutes
Multi-AZ instance	2.0x	60 to 120 seconds
Multi-AZ DB cluster (two readable standbys)	about 2.5x	under 35 seconds

The read-replica route is underrated for tier-two systems: a db.r6g.large replica of a db.r6g.xlarge primary costs $189 rather than $493, gives you read offload in normal operation, and can be promoted in minutes. That is a 38 percent premium instead of 100 percent, and the replica earns part of its keep every day.

Do this per environment

The single highest-value action here is turning HA off in non-production. A fleet of twelve staging and development databases on db.m6g.large with Multi-AZ wastes roughly $2,064 per month for resilience nobody will ever exercise. Put that decision in your Terraform module as an environment-driven variable so it cannot be copied forward by accident.

Price the HA flag before you merge, because it is a boolean with a doubling consequence. Compare configurations against the resource catalog, and see Multi-AZ pricing in detail for the RDS specifics.

FAQ

How much does database high availability cost?

Roughly double. RDS Multi-AZ doubles compute and storage, Cloud SQL HA doubles compute and storage, and Azure zone-redundant HA doubles compute. A db.r6g.xlarge with 1 TB of gp3 goes from about $493 to $986 per month, a db.m6g.large with 500 GB from about $172 to $344, and a db.r6g.4xlarge with 4 TB from about $1,972 to $3,944.

What failures does Multi-AZ actually protect against?

Host failure, availability zone failure, storage failure, and planned maintenance, converting a restore-from-backup event into a 60 to 120 second automatic failover. It does not protect against application bugs that corrupt data, accidental table drops, bad schema migrations, credential problems, or resource-exhaustion outages, because all of those replicate to the standby. Those need backups, PITR, and testing.

When is HA not worth the cost?

When the expected loss avoided is below the HA cost. An internal admin tool at $200 per hour of downtime with 1.5 expected incidents per year avoids about $300 of loss against roughly $2,064 of annual HA cost, losing money by a factor of seven. Staging and development environments are pure waste. A payments API at $20,000 per hour avoids about $30,000 against $5,916, returning five times its cost.

Is there a middle ground between single-AZ and Multi-AZ?

Yes. A single-AZ primary with a smaller read replica you can promote costs roughly 1.3x to 1.6x single-AZ rather than 2.0x, recovers in 5 to 15 minutes instead of 30 to 90, and offloads reads every day in normal operation. A db.r6g.large replica of a db.r6g.xlarge primary is $189 against $493 for a full standby, a 38 percent premium instead of 100 percent.

How often do managed database instances actually fail?

Genuine hardware failures are rare. A planning figure of 1 to 2 disruptive events per year per instance is reasonable, and most of those are provider-initiated maintenance windows rather than failures. If avoiding maintenance downtime is the main benefit you are buying, weigh that against simply scheduling the maintenance window at 3am on a Sunday, which costs nothing.

How does C3X help with the HA cost decision?

C3X prices the HA flag from Terraform before you merge, which matters because multi_az is a boolean with a doubling consequence that is trivially copied from a production module into a staging one. Making the environment-driven difference visible in the pull request stops a fleet of non-production databases from quietly carrying production-grade redundancy.

What to do next

Make HA an expected-value decision, not a default. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.