Study guide
3.2 High Availability, Disaster Recovery Patterns & RTO/RPO
Google Professional Cloud Architect Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Strategy & Case Study Methodology
1.1 Exam Overview, Structure & Scoring Logistics 1.2 The Professional Cloud Architect Role & Exam Mindset 1.3 Deconstructing GCP Case Studies & Scenario Questions
2 Chapter 2: Designing for Business Requirements
2.1 Mapping Business Objectives, ROI & Total Cost of Ownership 2.2 Cost Optimization Strategies, Pricing Models & Trade-Offs 2.3 Business Continuity, Governance & Compliance Planning
3 Chapter 3: Designing for Technical Requirements & Availability
3.1 Scalability, Elasticity & Capacity Planning 3.2 High Availability, Disaster Recovery Patterns & RTO/RPO 3.3 Performance Optimization & Global Latency Reduction
4 Chapter 4: Compute Selection & Workload Architecture
4.1 Compute Engine Architecture, Sizing & Managed Instance Groups 4.2 Google Kubernetes Engine (GKE) Standard vs Autopilot & Microservices 4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
5 Chapter 5: Storage, Database & Data Warehouse Architecture
5.1 Cloud Storage Architecture, Storage Classes & Lifecycle Management 5.2 Relational Databases: Cloud SQL, AlloyDB & Cloud Spanner 5.3 NoSQL & Big Data Storage: Firestore, Bigtable & BigQuery
6 Chapter 6: Networking, Hybrid Connectivity & Traffic Routing
6.1 VPC Design, Subnets, Shared VPC & VPC Peering 6.2 Hybrid & Multicloud Connectivity: Cloud VPN & Cloud Interconnect 6.3 Cloud Load Balancing, Cloud CDN & Cloud DNS
7 Chapter 7: Identity, Access & Resource Governance
7.1 Cloud IAM Hierarchy, Custom Roles & Service Accounts 7.2 Workload Identity Federation, Service Account Impersonation & IAP 7.3 Organization Policies, Tags & Resource Governance
8 Chapter 8: Security Architecture, Data Protection & Compliance
8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM 8.2 Network Security: Cloud Armor, VPC Service Controls & Firewalls 8.3 Compliance Frameworks, Sensitive Data Protection & Security Command Center
9 Chapter 9: DevOps, Automation & Infrastructure as Code
9.1 Infrastructure as Code (IaC) with Terraform on Google Cloud 9.2 CI/CD Pipelines: Cloud Build, Artifact Registry & Cloud Deploy 9.3 Deployment Strategies (Blue/Green, Canary) & GitOps with Config Sync 9.4 Interacting with Google Cloud Programmatically: Cloud SDK, Cloud Shell & Emulators
10 Chapter 10: Site Reliability Engineering & Operations Excellence
10.1 SRE Fundamentals: SLIs, SLOs, SLAs & Error Budgets 10.2 Observability: Cloud Monitoring, Logging & Alert Policies 10.3 Diagnosing Performance: Cloud Trace, Profiler & Error Reporting
11 Chapter 11: Data Pipelines, Integration & Modernization
11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc 11.2 Stream and Batch Processing: Dataflow & Dataproc 11.3 API Management & Service Integration: Apigee & Cloud API Gateway 11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options
12 Chapter 12: Well-Architected Framework & Official Case Study Solutions
12.1 Google Cloud Well-Architected Framework & FinOps Governance 12.2 Comprehensive Case Studies: EHR Healthcare & Cymbal Retail 12.3 Comprehensive Case Studies: Altostrat Media & KnightMotives Automotive
13 Chapter 13: AI, Machine Learning & Generative AI Architecture
13.1 AI/ML Platform Architecture: Vertex AI, Gemini Enterprise Agent Platform & AI Hypercomputer 13.2 Prebuilt AI APIs, Model Garden, Gemini Cloud Assist & Securing AI
3.2 High Availability, Disaster Recovery Patterns & RTO/RPO
Key Takeaways Explain This Topic AI
High Availability (HA) maintains continuous operational uptime across component and zonal failures within a region, whereas Disaster Recovery (DR) provides the processes and secondary infrastructure to restore service after catastrophic regional outages or data loss.
The Disaster Recovery continuum spans four primary patterns—Backup & Restore, Cold Standby (Pilot Light), Warm Standby, and Hot Standby (Active-Active)—with cost and operational complexity scaling inversely with RTO and RPO targets.
Recovery Time Objective (RTO) dictates the maximum acceptable duration of service disruption, while Recovery Point Objective (RPO) dictates the maximum acceptable data loss measured in elapsed transaction time.
Synchronous data replication (e.g., Cloud Spanner Multi-Region) provides zero RPO and immediate cross-region consistency via Paxos consensus at the expense of higher write latency; asynchronous replication (e.g., Cloud SQL cross-region replicas) provides lower write latency but carries non-zero RPO risk equal to replication lag.
Global External Application Load Balancers leverage Google Anycast to execute instantaneous, sub-second failover between healthy backend regions, eliminating the client-side DNS caching delays inherent in traditional DNS-based failover.
Last updated: August 2026
High Availability (HA) vs. Disaster Recovery (DR)
In the Google Cloud Well-Architected Framework, High Availability and Disaster Recovery are complementary yet distinct engineering disciplines:
High Availability (HA) focuses on eliminating Single Points of Failure (SPOFs) within normal operating conditions, ensuring the system remains operational during localized hardware, rack, network, or single-zone disruptions.
Disaster Recovery (DR) focuses on business continuity during catastrophic, rare events that incapacitate an entire geographic region (e.g., major natural disasters, fiber cuts, regional grid failures) or widespread logical data corruption.
Quantifying Availability Metrics (The "Nines")
Availability is expressed mathematically as the percentage of operational uptime over a rolling calendar period: Availability = Total Uptime Total Uptime + Total Downtime × 100 % \text{Availability} = \frac{\text{Total Uptime}}{\text{Total Uptime} + \text{Total Downtime}} \times 100\% Availability = Total Uptime + Total Downtime Total Uptime × 100%
- Availability Target Maximum Downtime per Year Maximum Downtime per Month Architectural Requirement
- 99.9% (Three Nines) 8.76 hours 43.8 minutes Single-region, multi-zone deployment with automated zonal failover
99.99% (Four Nines) 52.56 minutes 4.38 minutes Multi-zone regional HA with automated database replication and health checks
99.999% (Five Nines) 5.26 minutes 26.3 seconds Multi-region Active-Active deployment with global Anycast load balancing
Fault Domains: Zonal vs. Regional Resilience
Google Cloud partitions global infrastructure into strict fault isolation boundaries: Google Cloud Global Backbone
- ├── Region: us-central1 (Iowa)
- │ ├── Zone: us-central1-a (Isolated power, cooling, compute fabric)
- │ ├── Zone: us-central1-b (Isolated power, cooling, compute fabric)
- │ └── Zone: us-central1-c (Isolated power, cooling, compute fabric)
- └── Region: europe-west1 (Belgium)
- ├── Zone: europe-west1-b
- ├── Zone: europe-west1-c
- └── Zone: europe-west1-d
- Zonal Resilience Patterns
Regional Managed Instance Groups (Regional MIGs) : Automatically spread instances evenly across three zones in a region. If us-central1-a fails, the regional MIG automatically provisions replacement instances in us-central1-b and us-central1-c without human intervention.
Regional Persistent Disks (Regional PD) : Synchronously replicate block storage data across two zones in the same region. If a database VM crashes along with its host zone, the standby VM in the second zone can immediately attach the Regional PD and resume service with zero storage data loss.
Regional Resilience Patterns
Cloud Storage Multi-Region / Dual-Region : Objects written to a Dual-Region bucket (e.g., nam4 for Iowa/South Carolina) are geo-redundantly stored across distinct regions separated by hundreds of miles. Google Cloud offers Turbo Replication , providing a 100% replication SLA within 15 minutes for dual-region buckets.
Cloud Spanner Multi-Region : Executes distributed transactions across multiple regions using atomic clock-synchronized TrueTime and Paxos consensus, providing 99.999% (Five Nines) availability with synchronous replication and zero RPO.
The Disaster Recovery Spectrum
Organizations select a DR topology based on the balance between financial cost and downtime tolerance. The DR continuum spans four canonical architectures: ◄ Lower Cost / Slower Recovery Higher Cost / Instant Recovery ►
- ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
- │ Backup & Restore│ │ Pilot Light │ │ Warm Standby │ │ Hot Standby │
- │ (Cold DR) │ │ (Cold Standby) │ │ (Scaled Mirror) │ │ (Active-Active) │
- │ │ │ │ │ │ │ │
- │ RTO: Hours/Days │ │ RTO: Tens of min│ │ RTO: Minutes │ │ RTO: Near-Zero │
- │ RPO: Hours │ │ RPO: Seconds/Min│ │ RPO: Seconds │ │ RPO: Zero (0) │
- └─────────────────┘ └─────────────────┘ └─────────────────┘ └─────────────────┘
- 1. Backup and Restore (Cold DR)
Architecture : Data and database dumps are backed up periodically (e.g., hourly snapshots or daily exports) and shipped to Cloud Storage in a secondary region. Compute resources in the recovery region are zero.
Failover Process : In a disaster, operations teams provision new VPC networks, spin up compute instances via Terraform, and restore database state from storage snapshots.
Trade-offs : Lowest cost; highest RTO (hours to days) and highest RPO (hours).
2. Cold Standby (Pilot Light)
Architecture : Core database data is continuously replicated asynchronously to a secondary region (e.g., a cross-region Cloud SQL read replica). Core compute and network infrastructure definitions (Terraform / Golden Machine Images) exist in the secondary region, but VM instances are turned off or kept at a count of zero.
Failover Process : When disaster strikes, automation scripts promote the database replica to become the standalone primary database, and the secondary Managed Instance Group scales from 0 to target capacity.
Trade-offs : Low continuous cost; RTO of 15 to 45 minutes; RPO of seconds to minutes.
3. Warm Standby
Architecture : A fully functional, scaled-down version of the production environment runs 24/7 in the secondary region. The secondary database is actively replicating, and the secondary MIG runs at minimal capacity (e.g., 20% of production traffic capacity).
Failover Process : The load balancer redirects traffic to the secondary region, and the secondary MIG autoscales out rapidly to 100% capacity.
Trade-offs : Medium-high cost; RTO of minutes; RPO of seconds.
4. Hot Standby / Multi-Region Active-Active
Architecture : Production traffic is simultaneously served by fully provisioned infrastructure in two or more regions. An External Application Load Balancer routes users to the nearest healthy region. Underlying databases leverage multi-region synchronous replication (Cloud Spanner) or active-active multi-master replication.
Failover Process : Completely automated and instantaneous. If Region A fails health checks, Anycast routing instantly sends 100% of global traffic to Region B.
Trade-offs : Highest infrastructure cost; RTO ≈ 0; RPO = 0.
DR Pattern Recovery Time (RTO) Data Loss (RPO) Relative Cost Failover Mechanism Primary Workload Type
Backup & Restore Hours to Days Hours $ Manual / Scripted rebuild Non-critical internal batch systems, dev environments
Pilot Light 15 - 60 Minutes Seconds - Minutes $$ Database promotion + MIG scale-up Core business systems with moderate RTO tolerance
Warm Standby 2 - 10 Minutes Seconds $$$ Rapid autoscaling + Traffic diversion Critical customer-facing e-commerce / SaaS APIs
Active-Active Hot Sub-second (Near 0) Zero (0) $$$$ Automated Anycast LB traffic shift Tier-0 financial transactions, real-time healthcare
- Calculating and Designing for RTO and RPO
- Two fundamental metrics govern Disaster Recovery engineering: DISASTER OCCURS
- │
- ◄── RPO Window ──────────────┼────────────── RTO Window ──►
- [Last Valid Data State] │ [Full Service Restored]
- ▼
- (Lost Transactions)
Recovery Point Objective (RPO) : The maximum acceptable data loss measured in time. It defines the delta between the last successfully committed/replicated transaction and the point of disaster. An RPO of 15 minutes means the business can tolerate losing up to 15 minutes of transactional data.
Recovery Time Objective (RTO) : The maximum acceptable duration of system downtime. It defines how quickly the system must be restored to full production operation after an outage begins. Total Outage Impact = RTO (Downtime Duration) + Data Reconstitution Time from RPO \text{Total Outage Impact} = \text{RTO (Downtime Duration)} + \text{Data Reconstitution Time from RPO} Total Outage Impact = RTO (Downtime Duration) + Data Reconstitution Time from RPO
Cross-Region Data Replication Trade-Offs
Designing data persistence across geographic regions involves an immutable physical trade-off between consistency, latency, and disaster resilience: Replication Spectrum:
- Synchronous (Paxos / TrueTime) Asynchronous (Log Shipping)
- ├────────────────────────────────────┼────────────────────────────────────┤
- RPO = 0 (Guaranteed Zero Data Loss) • RPO > 0 (Replication Lag Delta)
- Strong Consistency Globally • Eventual Consistency
- Higher Write Latency (50-150ms RTT) • Low Write Latency (<5ms Local Write)
- Cloud Spanner Multi-Region • Cloud SQL Cross-Region Replicas
- 1. Synchronous Replication
Services : Cloud Spanner Multi-Region, Cloud Storage Dual/Multi-Region.
Mechanism : A write transaction is not acknowledged to the client until a quorum of distributed voting replicas across distinct regions successfully commit the transaction via Paxos consensus.
Advantages : RPO = 0. In the event of a catastrophic regional failure, zero data is lost, and secondary regions can continue serving writes immediately without data reconciliation.
Trade-off : Elevated write latency due to cross-region network round-trip time (RTT) governed by the speed of light in fiber optics (typically 30-100ms).
2. Asynchronous Replication
Services : Cloud SQL Cross-Region Read Replicas, AlloyDB Secondary Clusters, Bigtable Multi-Cluster Routing.
Mechanism : Writes commit locally to the primary database instance with sub-5ms latency. Transaction write-ahead logs (WAL) are shipped asynchronously over the Google private network to read replicas in secondary regions.
Advantages : Extremely low local write latency; primary transactions are decoupled from remote network delays.
Trade-off : Non-zero RPO. Replication lag represents the real-time difference between the primary database and the secondary replica. If the primary region collapses abruptly, un-replicated transactions in flight are permanently lost upon replica promotion.
Important
Replica Promotion Rule : Promoting a Cloud SQL cross-region replica to become a primary standalone database is a one-way, irreversible operation . Once promoted, the replica severs replication ties with the original master. If the original primary region later recovers, architects must establish a brand-new replication stream to prevent split-brain data corruption.
Failover Orchestration and DNS Failover
When a primary region fails, redirecting user traffic to the secondary disaster recovery site requires deterministic traffic orchestration: Traffic Steering Approaches:
- 1. Global Load Balancing (Anycast VIP) ──> [Instant Sub-Second Rerouting]
- Client ──> 34.120.X.X ──[Google Edge Proxy]──> Healthy Surviving Region
- 2. Cloud DNS Health-Checked Failover ──> [Delayed by Client DNS TTL Caching]
- Client ──> Queries DNS ──[TTL Delay 60-300s]──> Updates to Secondary IP
- 1. Global External Load Balancer Anycast Failover (Recommended)
Google Cloud Global External Application Load Balancers advertise a single Anycast IP address from over 180+ global Edge Points of Presence.
The load balancer continuously evaluates regional backend health checks. If all backend VMs in us-central1 fail health checks, Google's edge infrastructure automatically reroutes traffic to backends in europe-west1 in under 5 seconds .
Architectural Advantage : Zero dependency on client-side DNS cache updates or TTL expirations.
2. Cloud DNS Routing Policies
Failover Policy : Primary and backup geo-targets configured with health checks. If the primary endpoint fails health checks, Cloud DNS automatically updates responses to return the backup IP.
Limitation : Client operating systems, ISP recursive resolvers, and intermediate proxy servers frequently ignore or cache DNS TTL values (e.g., retaining cached IPs for 300 to 3,600 seconds). DNS failover is inherently slower than Anycast load balancing and introduces delayed RTO.