# A Pragmatic Multi-Region Strategy for Small Teams

URL: https://www.devopsness.com/blog/a-pragmatic-multi-region-strategy-for-small-teams
Author: Kiril Urbonas
Published: 2025-03-04
Updated: 2025-03-04
Categories: Cloud
Tags: AWS, Terraform, Monitoring

Summary: 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.