A Pragmatic Multi-Region Strategy for Small Teams
How a small team moved from single-region risk to a simple active/passive multi-region setup without doubling complexity.
Key takeaways
How a small team moved from single-region risk to a simple active/passive multi-region setup without doubling complexity.
A Pragmatic Multi-Region Strategy for Small Teams#
Multi-region can easily become a science project. This is what worked for a five-person platform team supporting a SaaS product.
Starting Point: Single Region, Shared VPC#
We began with everything in one AWS region: RDS, EKS, S3, and a shared VPC.
- RTO/RPO were theoretical.
- Failover docs existed, but no one had run them end-to-end.
Step 1: Read Replicas and S3 Replication#
- Added a read replica of RDS in a second region.
- Enabled S3 cross-region replication for critical buckets.
- Agreed on an RPO of 15 minutes.
Step 2: Terraform Modules for Two Regions#
Instead of cloning the entire stack, we:
- Created a region-aware module for shared resources.
- Used workspaces to differentiate primary vs secondary.
```hcl module "vpc" { source = "./modules/vpc" region = var.region primary = var.is_primary } ```
Step 3: DNS and Runbooks#
- Used Route53 failover records with health checks on a lightweight
/healthzendpoint. - Wrote an explicit runbook:
- who can declare a disaster,
- which Terraform workspaces to apply,
- how to flip DNS and confirm.
We didn’t solve every theoretical edge case, but we can now lose a region and recover in under an hour with a plan the team has actually rehearsed.
Get the DevOps Troubleshooting Cheat Sheet
Subscribe and get our free one-page reference for the errors that eat an afternoon — CrashLoopBackOff, OOMKilled, Terraform state locks, and more — plus new guides as we publish them.
What We Learned Running Weekly Game Days on Our CI/CD Pipeline
Practical game day scenarios for CI/CD: broken rollbacks, permission issues, and slow feedback loops—and how we fixed them.
Systemd Tricks We Use to Keep Services Boring
Concrete systemd unit patterns that reduced flakiness: restart policies, resource limits, and structured logs.
More from Cloud
Explore more articles in this category
Azure OpenAI's Sweden Central Outage: A Health Check Postmortem
A slow database made a backend service look dead, and the health check that was supposed to protect it killed it faster. The lesson has nothing to do with AI.
GKE Pod Snapshots: Cold Starts Drop 89%, If Your Nodes Match
Google's benchmarks show a 70B model restoring in 37 seconds instead of minutes. The catch is a hash and a hardware match that silently refuses to restore when either is off.
AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery
AWS says it cannot restore data held only in Bahrain (me-south-1) or in one UAE zone. Multi-AZ gave availability, not recovery, and only cross-region copies survived.
You might have missed
Evergreen posts worth revisiting.