Active-Active DR Across Regions: A Terraform Tale Told in Data Bridges and Gatekeepers

Building the Data Bridge

Building on Netflix’s cross‑region mentality, the pattern starts with every environment pointing to its own backend while sharing a controlled data bridge to the primary region. The DR repository uses per‑environment backends so the DR state stays isolated, and a dedicated provider alias grants read‑only access to the primary region’s resources. In practice, this means the DR code imports primary VPC details via terraform_remote_state and consumes them as data, never creating or mutating primary resources. This keeps the primary region sacrosanct while enabling DR to function as a faithful copycat of the data bridge. Code patterns that help this sculpting include a per‑env backend block and a primary region provider alias: # Data bridge (DR repo) terraform { backend "s3" { bucket = "dr-terraform-state" key = "network/terraform.tfstate" region = "us-west-2" } } provider "aws" { alias = "primary" region = "us-east-1" } data "terraform_remote_state" "primary_vpc" { backend = "s3" config = { bucket = "primary-terraform-state" key = "network/terraform.tfstate" region = "us-east-1" } } # Read-only consumption of primary resources locals { primary_vpc_id = data.terraform_remote_state.primary_vpc.outputs.vpc_id primary_subnets = data.terraform_remote_state.primary_vpc.outputs.private_subnets } This approach is deliberate: the DR environment reads the essential data from the primary via a remote state bridge, while backends are isolated per region to prevent accidental cross‑region modifications 2 .

Reading the Primary State as Data

The next step is to ensure the DR repo’s resources only consume the primary data bridge and do not attempt to manage the primary region. The DR code should rely on the data bridge outputs (VPC IDs, subnets, routing IDs) to shape its own DR‑local resources, while the primary region remains untouched. In other words, DR resources are created only in the DR region, driven by values sourced from the remote state, not by direct writes to the primary region. Key idea: treat the remote state as a read‑only data source, and enforce region isolation through provider aliasing and separate backends. This separation is essential for true cross‑region DR where the DR site mirrors data but does not govern the primary infrastructure 3 4 .

Gating the Plan

A gatekeeping CI step ensures that no Terraform plan or apply touches the primary region. The gate runs a plan in a controlled context, dumps a JSON representation, and inspects the plan for any resources that would be created or modified in the primary region’s provider. If any such changes are detected, the gate blocks the run and surfaces the offending resources for remediation. This is the practical guardrail that preserves primary integrity while DR remains capable of provisioning autonomously in its own region. Here’s a representative gate script (adaptable to your CI system): #!/bin/bash # CI gate to prevent primary region modifications terraform plan -out=tfplan # Check if any resources would be created/modified in primary region if terraform show -json tfplan | jq -r '.planned_values.root_module.resources[] | select(.provider_name == "aws.primary") | .address' | grep -q .; then echo "ERROR: Plan contains changes in primary region (us-east-1)" echo "Changes found:" terraform show -json tfplan | jq -r '.planned_values.root_module.resources[] | select(.provider_name == "aws.primary") | "- (.address)"' exit 1 fi echo "✓ No primary region changes detected. Plan approved." terraform apply tfplan This pattern aligns with the broader lesson: cross‑region resiliency demands governance as code, not governance as hand waves 5 6 .

Counterintuitive Twist

The strongest DR patterns reveal that isolation does not mean ignorance. Isolation prevents cross‑region mutation, but a DR team still needs visibility into what the primary region contains and what would happen if a failover occurs. The twist is that the data bridge must be trustworthy and auditable, yet the DR environment should not become a shadow of the production environment in permanence—it's a controlled replica that can adapt quickly to failures. Moreover, relying solely on a CI gate is not enough; traffic routing and state coordination must be designed to handle failover gracefully while keeping data paths explicit and observable 7 .

Proof in Practice

Across the industry, leading patterns emphasize explicit data paths, isolation, and governance when enabling DR across regions. Netflix’s Isthmus approach demonstrated that cross‑region resiliency requires disciplined architectural choices—clear demarcations of where data lives, how it’s accessed, and how failures are contained to avoid cascading outages 1 . The broader literature reinforces that stateful cross‑region deployments benefit from dedicated backends per region and well‑defined data bridges, reducing the blast radius of outages and speeding recovery 8 9 . Real-World Case Study Netflix Netflix implemented an active‑active, multi‑regional resiliency pattern (Isthmus) to improve availability across regions, ultimately operating an active‑active deployment across the USA to withstand region outages. Key Takeaway: True cross‑region DR requires explicit architectural patterns for traffic routing, state coordination, and deployment governance; isolation and coordinated data paths across regions can unlock high availability but add cross‑region complexity that must be managed carefully.

System Flow

flowchart TD A[Primary Region (us-east-1): VPC resources] --> B[Terraform Remote State: primary_vpc] B --> C[Data Bridge (DR repo, us-west-2)] C --> D[DR Resources (us-west-2)] A -->|exports state| E[Remote State backend (per-region)] E --> D Did you know? Many developers discover that the biggest DR hurdle isn't the tech—it's the governance and the data paths that connect regions without turning DR into a secret shadow of production. Key Takeaways DR isolation across regions via per-env backends Read-only data bridge using terraform_remote_state Provider alias ensures correct regional targeting CI gate blocks any plan touching the primary region Separate state backends per region keep data hygienic References 1 Terraform AWS S3 Backend documentation 2 Creating an S3 Bucket (AWS) documentation 3 Disaster recovery article 4 The Terraform Project GitHub repo 5 jq – Lightweight and flexible command-line JSON processor GitHub repo 6 AWS Well-Architected Framework documentation 7 JSON documentation 8 Terraform (software) - Wikipedia article 9 RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Standard documentation 10 Kubernetes Architecture documentation Share This Ever wondered how Netflix keeps streaming alive when a region hiccups? A cross‑region DR tale unfolds. Cross‑region resilience starts with a data bridge that reads primary state without mutating it.,Per‑env backends + provider aliasing keep regions honest and isolated.,CI gates prevent any plan that would touch the primary region—guardrails that save fleets. Dive into the full story to see how data paths, governance, and architecture come together. #SoftwareEngineering #SystemDesign #Terraform #CloudComputing #DevOps #MultiRegion #DisasterRecovery #AWS undefined function copySnippet(btn) { const snippet = document.getElementById('shareSnippet').innerText; navigator.clipboard.writ

System Flow

Wrapping Up

The journey reveals that building true cross‑region resilience starts with explicit data bridges and strict boundaries. When regions are isolated by default and connected by auditable data, DR can behave like a safety valve—ready to take over, without tripping the main line. The key takeaway: design for auditable data flows, enforce region isolation, and govern changes with code‑driven gates. Tomorrow’s teams can apply these patterns to their own multi‑regional challenges and turn potential outages into manageable events.