DEV Community

Cover image for Multi-AZ by Default: When High Availability Costs More Than the Downtime It Prevents
Alok Ranjan Daftuar
Alok Ranjan Daftuar

Posted on • Originally published at aloknecessary.github.io

Multi-AZ by Default: When High Availability Costs More Than the Downtime It Prevents

#aws #cloud #architecture #devops

"Enable Multi-AZ for all production databases." It appears in every best-practice guide. Like "make everything private," it sounds unambiguously correct. More availability is better.

Multi-AZ for RDS doubles your database instance cost. Exactly doubles. A db.r8g.2xlarge at $700/month becomes $1,401/month. Ten such instances: $84,100/year in availability premium. That number needs a business case before it's treated as a default.

What Multi-AZ Actually Provides (and Doesn't)

Provides:

  • Synchronous standby in a different AZ (same region)
  • Automatic failover in 35–60 seconds
  • Zero data loss (RPO = 0)

Does NOT provide:

  • Protection against regional outages (standby is same region)
  • Read scalability (standard standby is not readable — sits idle)
  • Protection against data corruption or accidental deletion (replicated instantly)

When Multi-AZ Is Unnecessary

  • Dev/staging/QA — protecting against a problem that doesn't exist. No user impact from staging downtime.
  • Internal tooling — 50 users, business hours only. 30-minute restore is acceptable.
  • Batch processing — re-run the job when the database recovers. Retry logic is cheaper than 2x cost.
  • Stateless app tiers on Kubernetes — topology spread constraints provide multi-AZ resilience at zero cost.

When Multi-AZ IS Worth It

  • Customer-facing, revenue-generating workloads ($50K/hour revenue loss justifies the premium instantly)
  • Contractual SLA commitments (99.9%+ uptime)
  • Regulated industries (HIPAA, PCI-DSS, SOC 2)
  • Large databases with slow restore (5TB snapshot restore exceeds acceptable RTO)

The Decision Framework 

Step 1: What is the business cost of 1 hour of downtime?
Step 2: Multi-AZ annual premium vs expected annual downtime cost
Step 3: Can snapshot restore meet your RTO?
Step 4: Environment rule — dev/staging/QA = Single-AZ, always
Enter fullscreen mode Exit fullscreen mode

If the Multi-AZ premium exceeds the expected annual cost of downtime, Single-AZ with a tested restore procedure is the right answer.

The Environment Rule (No Exceptions) 

Production, customer-facing:   Evaluate with framework
Production, internal tooling:  Single-AZ unless justified
Staging:                       Single-AZ, always
Development:                   Single-AZ, always
Enter fullscreen mode Exit fullscreen mode

Disabling Multi-AZ on non-production environments alone saves $3,118/year per database.

Read the Full Article

This is a summary of the second post in the Cloud Defaults Reconsidered series. The full article includes detailed cost breakdowns, cross-AZ transfer calculations, Aurora comparison, automated restore alternatives, and a complete decision framework:

👉 Multi-AZ by Default — Full Article

The full article includes:

  • Exact RDS pricing comparison across instance types (Single-AZ vs Multi-AZ)
  • Cross-AZ data transfer cost calculations
  • Non-production environment savings breakdown
  • Common misconceptions debunked (99.99% uptime, data loss protection, backups)
  • Kubernetes topology spread constraint manifest for free multi-AZ resilience
  • Aurora vs RDS Multi-AZ cost comparison
  • Break-even calculation template
  • Practical recommendations table by workload type

Top comments (0)