Skip to main content
A Pragmatic Multi-Region Strategy for Small Teams

A Pragmatic Multi-Region Strategy for Small Teams

KU
• 2 min read•1,044 views

How a small team moved from single-region risk to a simple active/passive multi-region setup without doubling complexity.

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.

Explore topics:AWSTerraformCloud
React
Share this post
KU

Kiril Urbonas

AI Engineer

555 articles
View all articles by Kiril Urbonas

You might have missed

Evergreen posts worth revisiting.