Multi-Region Disaster Recovery and RPO/RTO Optimization on GCP

When designing enterprise cloud landing zones, Disaster Recovery (DR) cannot be an afterthought. Cloud platform teams must define clear Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) backed by automated infrastructure.

1. RPO vs. RTO Defined

• RPO (Recovery Point Objective): Maximum acceptable data loss window measured in time. For AustinSS Blogs, RPO is 0 seconds for committed articles due to Firestore multi-zone synchronous replication.
• RTO (Recovery Time Objective): Maximum duration required to restore full service after a catastrophic regional outage. Target RTO is under 5 minutes.

2. Cold-Standby vs. Warm-Standby Architectures

AustinSS leverages Cloud Run v2 Warm Standby: secondary regional services configured in us-east1 with min_instances = 0. No computing costs are incurred until traffic is diverted.

3. Automated Failover via Cloud DNS Routing Policies

Using Google Cloud DNS Geolocation and Failover Routing Policies, health checks continuously probe the primary endpoint:

resource "google_dns_record_set" "failover" {
  name         = "blogs.austinss.com."
  managed_zone = "austinss-com-zone"
  type         = "A"
  ttl          = 60

  routing_policy {
    primary_backup {
      primary {
        internal_load_balancers {
          ip_address = google_compute_global_address.primary_lb.address
        }
      }
      backup_geo {
        location = "us-east1"
        rrdatas  = [google_compute_global_address.backup_lb.address]
      }
    }
  }
}