How to build a disaster-recovery architecture across AWS and GCP

The Strategic Imperative: Why Cross-Cloud DR?

Relying on a single cloud provider creates a single point of failure. Though rare, history has shown us that DNS outages, localized natural disasters, or cascading software bugs can take down entire regions (e.g., us-east-1) for hours.

A Multi-Cloud DR architecture offers:

1. Sovereignty: You own your uptime, independent of AWS’s status page.

2. Leverage: It forces you to maintain portable code (containers/Terraform), preventing vendor lock-in.

3. Compliance: Many financial and healthcare regulations now mandate “exit strategies” or multi-vendor redundancy.

Phase 1: The Network Foundation (The “Pipe”)

You cannot replicate terabytes of database changes over the public internet securely or reliably. You need a dedicated, encrypted tunnel.

Option A: HA VPN (The Standard Choice)

For most enterprises, a High-Availability (HA) Cloud VPN is sufficient.

• AWS Side: Deploy a Virtual Private Gateway (VGW) attached to your VPC.

• GCP Side: Deploy a Cloud VPN Gateway with dynamic routing (BGP).

• The Glue: Use BGP (Border Gateway Protocol) to exchange routes. When you add a subnet in AWS, GCP automatically “sees” it.

Option B: Cross-Cloud Interconnect (The Pro Choice)

For data-intensive workloads (10TB+), use Google Cross-Cloud Interconnect.

• How it works: Google provisions a physical fiber connection directly to your AWS Direct Connect location.

• Benefit: You get dedicated bandwidth (10Gbps or 100Gbps) with a lower egress fee than standard internet traffic, ensuring your database replication doesn’t lag.

Phase 2: The Data Layer (The Hard Part)

Stateless applications are easy to move. State (data) is heavy, sticky, and hard to sync. This is where your DR strategy lives or dies.

Relational Database Strategy: The “Read Replica” Pattern

Since AWS RDS and Google Cloud SQL are proprietary managed services, they don’t natively replicate to each other. We must drop down to the engine level.

Scenario: PostgreSQL (AWS RDS) to PostgreSQL (GCP Cloud SQL)

1. The Source (AWS): Configure your RDS instance to allow logical replication (rds.logical_replication = 1). Ensure your security groups allow traffic from the GCP VPC CIDR.

2. The Transport: Use pglogical (a logical replication extension).

3. The Destination (GCP): Spin up a minimal Cloud SQL instance. Configure it as a subscriber to the AWS publisher.

4. The Cutover: During a disaster, you “promote” the GCP replica to be a standalone primary writer.

Object Storage: S3 to GCS

We need every invoice, profile picture, and log file in S3 to appear in Google Cloud Storage (GCS).

• Solution: GCP Storage Transfer Service (Event-Driven).

• Workflow:

  1. User uploads file to S3.

  2. S3 triggers an SQS notification.

  3. GCP Storage Transfer Service polls the queue.

  4. The file is pulled over the private link into a GCS bucket.

  • Result: Near-synchronous replication with no custom code.

Phase 3: The “Pilot Light” Compute Strategy

We will use a Pilot Light strategy. This means the infrastructure on GCP is “on” but running at minimum capacity (the pilot light).

• AWS (Primary): EKS Cluster with 50 nodes.

• GCP (DR): GKE Cluster with 1 node (just enough to run system pods and keep the connection alive).

• Deployment: Your CI/CD pipeline (Jenkins/GitLab) must apply the same Docker images and Helm charts to both clusters simultaneously. The GCP cluster just has the replica count set to 0 for the application pods.

Real-Time Use Case: “FinTech Global” Survives Black Friday

Let’s look at a concrete example to prove this works.

The Company: FinTech Global, a payment processor handling $5M/hour. The Setup:

• Primary: AWS us-east-1 (Virginia).

• Secondary: GCP us-central1 (Iowa).

• Database: 2TB PostgreSQL DB.

• RTO Goal: < 15 Minutes.

• RPO Goal: < 1 Minute (max data loss).

The Event: 10:00 AM Black Friday

A massive network partition hits AWS us-east-1. The console is unreachable. API latency spikes to 10s, then timeouts.

The Failover Procedure (The “Runbook”)

Minute 0-2: Detection & Decision

• Datadog alerts trigger: “AWS Health Check Failed.”

• Decision: The CTO declares “Code Red.” The DR procedure is initiated.

Minute 2-5: The Database Flip

• Action: Operations team runs the promote_gcp_db.sh script.

• Technical Detail: This script connects to the GCP Cloud SQL instance, stops the replication subscription (severing the link to the dead AWS RDS), and executes SELECT pg_promote().

• Result: The GCP database is now a writable primary.

Minute 5-10: The Scale Up

• Action: Terraform Apply triggered for GCP.

• Technical Detail: The script updates the GKE Horizontal Pod Autoscaler (HPA) minimum replicas from 0 to 20.

• Result: GKE requests 20 nodes from GCP Compute Engine. Within 3 minutes, pods are pulling images and starting up.

Minute 10-12: The DNS Switch

• Action: DNS Failover.

• Technical Detail: The team updates the Cloudflare Global Traffic Manager to point api.fintechglobal.com from the AWS Load Balancer IP to the GCP External Load Balancer IP.

• Result: Traffic begins flowing to GCP.

Minute 14: Recovery Confirmed

• Traffic is processing. The database is accepting writes. The company is back online.

The Result

• RTO: 14 minutes.

• RPO: 45 seconds (The amount of data in flight during the crash).

• Cost: They paid for a “Pilot Light” (approx. 10% of full cost) to save millions in potential lost revenue.

Component Comparison: AWS vs. GCP for DR

Understanding the equivalent services is crucial for translation.

Infrastructure as Code: The Automator

You cannot rely on manual clicks during a panic. Use Terraform.

Example: Defining the Multi-Cloud Provider

# main.tf

# Configure AWS (Primary)
provider “aws” {
region = “us-east-1”
alias = “primary”
}

# Configure GCP (Secondary)
provider “google” {
project = “fintech-dr-project”
region = “us-central1”
alias = “secondary”
}

# The AWS VPC
resource “aws_vpc” “production” {
provider = “aws.primary”
cidr_block = “10.0.0.0/16”
# … configuration
}

# The GCP VPC (Must not overlap!)
resource “google_compute_network” “disaster_recovery” {
provider = “google.secondary”
name = “dr-network”
auto_create_subnetworks = false
}

resource “google_compute_subnetwork” “dr_subnet” {
provider = “google.secondary”
name = “dr-subnet-us-central1”
ip_cidr_range = “10.1.0.0/16” # Non-overlapping
region = “us-central1”
network = google_compute_network.disaster_recovery.id
}

Cost Optimization (FinOps for DR)

Running two clouds can double your bill if you aren’t careful. Here is how to minimize the “insurance premium”:

1. Spot Instances for DR: Since the GCP cluster is stateless until the moment of disaster, configure the GKE node pools to use Spot VMs (Preemptible). If a disaster hits, you can quickly swap to standard instances, but for daily testing/idle time, Spot is 60-90% cheaper.

2. Lifecycle Policies: In the DR storage bucket (GCS), set aggressive lifecycle policies. You might only need the last 7 days of backups for immediate recovery, not 7 years.

3. Minimum Viable Product (MVP): Your DR site doesn’t need to run everything. It only needs the critical path (Checkout, Login). Analytics, reporting, and internal tools can stay down until the primary region recovers.

Conclusion and Next Steps

Building a cross-cloud disaster recovery architecture between AWS and GCP is a non-trivial engineering feat, but it is the ultimate maturity milestone for cloud-native organizations. It requires a shift in mindset from “cloud-native” to “cloud-agnostic.”

By leveraging Terraform for consistent infrastructure, Containerization for application portability, and standardized replication protocols for data, you build a system that is resilient to the worst-case scenarios.

Official References (Do Follow)

• Google Cross-Cloud Interconnect: https://cloud.google.com/network-connectivity/docs/interconnect/concepts/cross-cloud-interconnect-overview

• GCP Storage Transfer Service: https://cloud.google.com/storage-transfer/docs/overview

• pglogical Documentation: https://github.com/2ndQuadrant/pglogical

• Terraform Google Provider: https://registry.terraform.io/providers/hashicorp/google/latest/docs