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 /healthz endpoint.
• 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.