Skip to main content

> amazon_rds_multi-az_deployment_vs_read_replica_replication_economics

Amazon RDS Multi-AZ Deployment vs Read Replica Replication Economics

How do RDS Multi-AZ Instance deployments differ financially from Multi-AZ DB Clusters with readable standbys, and how do cross-AZ replication fees accumulate?

Senior (L5)

THE SHORT ANSWER

Standard Amazon RDS Multi-AZ Deployments provision a synchronous standby instance in a second Availability Zone, exactly doubling the compute and storage cost (+100% price increase) solely for disaster recovery failover, while the standby remains completely inactive and unreadable. Amazon RDS Multi-AZ DB Clusters provision two readable standby instances (1 primary writer + 2 readable standbys across 3 AZs, costing 2x compute + storage) but allow read queries to be offloaded to both standbys with sub-second commit latency via local NVMe transaction logs. For read-heavy workloads requiring high availability, Multi-AZ DB Clusters deliver double the read throughput for the same aggregate hardware cost while eliminating external read replica replication lag and cross-AZ replication fees.

Engineering Handbook & Failure Dynamics

1. Underlying Mechanism

In standard RDS Multi-AZ (1 primary + 1 synchronous standby), storage volume replication is managed at the block level (DRBD/EBS replication). Replication data transfer between the primary and synchronous standby is included in the Multi-AZ instance hourly price (zero additional data transfer fees). However, standalone external Read Replicas incur standard instance costs PLUS $0.01/GB cross-AZ replication transfer fees. In RDS Multi-AZ DB Clusters (PostgreSQL/MySQL), transaction logs commit synchronously to at least one standby using Paxos-like quorum on local NVMe SSDs, delivering 2x faster commit latency than standard Multi-AZ while making both standbys directly queryable via a reader endpoint.

2. Appropriate Use Context

Production transactional databases (PostgreSQL/MySQL) with strict RTO/RPO requirements and heavy concurrent read queries (reporting, user profile fetching, search).

3. Production Failure Modes

Running standard Multi-AZ RDS (+100% cost) and separately provisioning 2 external Read Replicas for reporting, paying for 4 database instances total when a single 3-node Multi-AZ DB Cluster would satisfy both HA and read capacity for the cost of 2 instances; enabling Multi-AZ on staging/dev databases.

4. Diagnostic Signals & Telemetry

AWS Cost Explorer showing high `RDS:Multi-AZ-Usage` combined with `RDS:ReadReplica-Usage` and `AWS Data Transfer - InterZone-Out` for database engines; primary database CPU hitting 90% while the Multi-AZ standby sits at 0% utilization.

5. Prevention & Safeguards

Audit all RDS instances with Terraform; enforce Single-AZ on development/staging; evaluate migrating standard Multi-AZ + Read Replica setups to RDS Multi-AZ DB Clusters (or Amazon Aurora) to consolidate read capacity; leverage Reserved Instances covering cluster instance tiers.

6. Architectural Trade-offs

Multi-AZ DB Clusters provide readable standbys and faster commits, but require modern instance families (e.g. `db.m6gd`, `db.r6gd` with local NVMe SSDs) and are only supported on MySQL and PostgreSQL.

Case Study (TinyCTO In-Field Example)

An analytics application ran a standard Multi-AZ `db.r6g.2xlarge` PostgreSQL database ($1,100/mo * 2 = $2,200/mo) and two external Read Replicas in different AZs ($1,100 * 2 = $2,200/mo + $450 data transfer), costing $4,850/month across 4 instances. Migrating to an RDS Multi-AZ DB Cluster (1 writer + 2 readable standbys on `db.r6gd.2xlarge`) cost $2,950/month total, eliminating external replication data transfer fees and saving $1,900/month ($22,800/year) while cutting write commit latency in half.

Interactive Concept Drills

2 Cards
Q1

What is the key functional limitation of a standard AWS RDS Multi-AZ standby instance?

It is completely inactive and unreadable; it cannot serve read queries and only activates during failover.
Q2

How do RDS Multi-AZ DB Clusters differ from standard Multi-AZ instances?

They deploy 1 writer and 2 readable standbys across 3 AZs, allowing read traffic to be offloaded to both standbys.

Amazon RDS Multi-AZ Deployment vs Read Replica Replication Economics — Technical FAQ

Are replication data transfers charged between the primary and standby in standard RDS Multi-AZ?

No. Synchronous replication data transfer between the primary and standby within a Multi-AZ deployment is included in the hourly Multi-AZ instance pricing.

Should development and staging RDS databases use Multi-AZ?

No. Non-production environments should almost always use Single-AZ to avoid paying the 100% compute and storage duplication premium.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸Standard RDS Multi-AZ adds a 100% price premium for an unreadable failover standby.
  • ▸RDS Multi-AZ DB Clusters provide 2 readable standbys across 3 AZs for read offloading.
  • ▸External read replicas incur cross-AZ data transfer fees ($0.01/GB); Multi-AZ clusters do not.
  • ▸Single-AZ should be strictly enforced on non-production database tiers.

Common Misconceptions

  • ✗Misconception: You can point read queries to a standard Multi-AZ standby (False: Standard standbys accept zero connections; only Multi-AZ DB Clusters or Aurora support readable standbys).
  • ✗Misconception: Multi-AZ eliminates the need for database backups (False: Multi-AZ protects against hardware/AZ failures, not accidental data deletion or corruption).

Decision & Governance Guidance

Enforce Single-AZ on all staging, development, and QA database instances. Evaluate RDS Multi-AZ DB Clusters or Aurora PostgreSQL for read-heavy production workloads.

Authoritative Sources & Standards