A VP Engineering pushed back on me last month:
"We have to go multi-region. Our enterprise clients demand it."
I asked: "Does the contract specify RTO and RPO? Or just the word 'multi-region'?"
"Just the word."
That's almost always the case. Let me explain the actual tradeoffs.
Multi-AZ deployment:
→ 99.95% SLA from AWS (the actual SLA, not marketing)
→ Cross-AZ latency: 1-2ms
→ Cost overhead: ~15-20% over single-AZ for databases and stateful services
→ Implementation: RDS Multi-AZ flag, ELB cross-zone, EKS nodes across 3 AZs
→ Testing: kill a node, verify failover — done in 1 sprint
Multi-region deployment:
→ 99.99% SLA (0.04 percentage points better)
→ Cross-region latency: 40-200ms (Mumbai-Singapore ~50ms, Mumbai-Virginia 200ms)
→ Cost overhead: 60-120% over single-region. Every stateful service replicated. Cross-region egress bill.
→ Implementation: DNS failover, active-active database replication, CQRS, eventual consistency in every app code path
→ Testing: nobody actually tests real region failover. Ever. Including the companies with "best practices" decks.
The 0.04% uptime delta costs the average Series B team ₹40-80L/year in ongoing infrastructure + 2-3 engineer-quarters in implementation. And it's usually not tested, meaning it won't save you in the one scenario it's supposed to.
When multi-region is actually worth it:
→ Regulatory: data residency requires specific region for specific users
→ Latency: real-time interactive app with users in multiple continents
→ Scale: >$500M ARR where 0.04% downtime = real revenue loss
→ A contract that specifies RTO < 5 min on region-wide failure AND pays you enough to afford it
Most companies don't qualify. They build multi-region for RFP-checkbox reasons and then never touch the standby cluster.
If your architect is writing a multi-region migration doc right now, repost. Help them have the honest conversation.
Top comments (0)