Multi-region vs single-region for a 12-person B2B SaaS
Resilience ↔ Cost and complexity
Context
Answer an enterprise prospect asking whether we are "multi-region".
A big US prospect's security questionnaire asks: "Is the service deployed in multiple regions?" We run in one AWS region across three availability zones, with a 99.9% SLA.
Going multi-region means data replication, a second deployment pipeline, and roughly double the infrastructure bill. We are 12 people.
What's the honest answer, and what's the right investment?
Constraints
- Team
- 12 people, 4 on infrastructure part-time
- SLA offered
- 99.9%
- Customers
- Mostly EU; one large US prospect
Single region, multi-AZvsMulti-region
Community verdict
8 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Cost →
Trade-offs
Dimensions
- Resilience
- 3Single region, multi-AZ scores 3 of 55Multi-region scores 5 of 5
- Cost
- 5Single region, multi-AZ scores 5 of 52Multi-region scores 2 of 5
- Team effort
- 5Single region, multi-AZ scores 5 of 5
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentMulti-AZ already covers the outages you are likely to see. Region-wide outages are rare and usually partial.
If US users are coming, a US region is a latency and data-residency play as much as a resilience one. Start with a separate US stack per customer region rather than one global active-active system.
Region-per-customer-cell is so much simpler than global replication. No cross-region writes.
Ask what they actually need. Usually it's "can you survive a regional outage, and how fast?", which a documented disaster-recovery plan answers: encrypted backups replicated to a second region, infrastructure as code, and a restore you have actually rehearsed.
Quote your RTO/RPO. Most procurement teams accept that for a 99.9% SLA.
That reframing helps. We can write and rehearse a DR runbook in weeks, not quarters.