If your app goes down for an hour, your users won't wait — they'll find a competitor and never come back. This chapter is about making sure your application stays running, even when parts of the cloud have a catastrophe, so you can pass the Google Professional Cloud Developer (PCD) exam and build trust into your systems. You'll learn the difference between having a 'backup plan' (disaster recovery) and having an 'always-on, never-skip-a-beat' system (high availability).
Jump to a section
A simple way to picture Disaster Recovery and High Availability
Meet Priya, the head chef of a busy cloud kitchen chain that delivers food across a city. Her primary kitchen, the one with all the fancy ovens and fresh ingredients, is on the ground floor of a building downtown. She knows that a power cut, a burst pipe, or even a road closure could shut down that kitchen completely, stopping all deliveries. Priya wants to make sure her customers always get their lunch, so she sets up a second, identical kitchen on a completely different floor of a building in another part of town. This second kitchen is her 'disaster recovery' plan: she keeps it stocked with the same ingredients and connected to the same delivery app servers. If the first kitchen has a fire, she doesn't panic. She just flips a switch, and the second kitchen takes over all new orders immediately. Her customers might notice a tiny delay, but their food still arrives. This is 'failover': shifting the work from a broken system to a healthy one. Priya also uses 'high availability' by having both kitchens running at all times for high-demand lunch rushes, sharing the load so no single kitchen gets overwhelmed. If one kitchen's oven breaks, the other handles the extra pizzas without skipping a beat. For her, the IT concepts of disaster recovery and high availability are just smart backup plans that keep dinner — and revenue — flowing, no matter what.
Let's break down what 'Disaster Recovery' (DR) and 'High Availability' (HA) actually mean for your cloud application. Imagine you run a messaging app. If the building holding your main servers catches fire, your entire app stops working. That is a disaster. Disaster Recovery is your plan to get the app running again after that disaster. It's not about preventing the fire; it's about having a second building (a 'recovery site') ready, with a copy of your servers and data, so you can restart the app there. The key metrics are RTO (Recovery Time Objective) — how long you can afford to be down — and RPO (Recovery Point Objective) — how much data you can afford to lose. If your RTO is 4 hours, your DR plan must get the app back within 4 hours. If your RPO is 1 hour, you must backup your data at least every hour, so you only lose the last hour of messages.
High Availability (HA) is different. HA is about building your system so it never goes down in the first place, even if some parts fail. Think of a bridge with four lanes. If one lane is closed for repairs, the other three lanes still carry traffic. HA uses 'redundancy' — you have multiple copies of everything. You have multiple servers ('instances') running your app, spread across different 'availability zones' (separate data centres within a cloud region, each with its own power and cooling). If one server dies, your traffic automatically goes to the others. This automatic rerouting is called 'failover'. HA is like having a car with a spare tyre already bolted on — you keep driving. DR is like having a second car parked in your garage ready to use if the first gets wrecked.
Google Cloud offers several services to achieve this. For multi-region architecture, you deploy your app in two or more 'regions' (e.g., us-east1 in South Carolina and europe-west1 in Belgium). This protects against a disaster that wipes out an entire region, like a hurricane. Google's 'Cloud Load Balancing' distributes incoming traffic across your instances in multiple regions. 'Google Cloud DNS' routes users to the nearest healthy region. For databases, 'Cloud Spanner' gives you 'strong consistency' across regions — meaning every user sees the same data instantly — while 'Cloud Bigtable' or 'Cloud SQL' with 'Cross-Region Replication' provides eventual consistency, where data takes a few seconds to copy over. You choose your strategy based on your app's needs.
Why does this exist? Before cloud computing, companies had to build their own second data centre for DR, which was incredibly expensive. The cloud lets you spin up resources on demand, paying only for what you use during a disaster (a 'pilot light' setup, where you keep a small copy running and scale it up) or running a 'hot standby' (a full copy running all the time). It replaces the old 'backup tapes in a safe' approach with automated, geographically distributed copies. For the PCD exam, you must understand when to use what strategy, and how Google's tools help you implement them without breaking the bank.
Define Business Requirements
Meet with stakeholders to agree on RTO (how long can the app be down?) and RPO (how much data can we lose?). For example, a bank app might need RTO = 1 minute and RPO = 0 seconds. This step sets the budget and architecture choices.
Design High Availability Within a Region
Deploy your compute instances across at least two availability zones in a single region. Use a Cloud Load Balancer to distribute traffic and configure health checks to automatically remove unhealthy instances. This ensures a single server or zone failure doesn't take the app down.
Choose a Database Replication Strategy
Pick a database type (e.g., Cloud SQL, Cloud Spanner) and choose a replication mode. For multi-zone HA, use a primary and a standby in different zones. For multi-region DR, enable cross-region replication (asynchronous for Cloud SQL, synchronous for Spanner). This determines your actual RPO.
Deploy a Second Region for Disaster Recovery
Create identical infrastructure (compute, databases, networking) in another Google Cloud region that is geographically far from your primary region (e.g., one in Iowa, one in Belgium). This is your recovery site. Use Cloud DNS failover policy to route traffic to the DR region if health checks fail on the primary region.
Test and Automate Failover
Run a scheduled disaster recovery drill: manually trigger a simulated region outage and measure if your app comes back within the RTO. Automate the failover process using Cloud Run or Cloud Functions to reduce manual steps. Document every step and update the plan based on drill results.
An IT professional working at a retail company, let's call it 'ShopFast', is tasked with designing a system for an e-commerce app that must never go offline, especially during Black Friday sales. The senior engineer, Jamal, starts by identifying the critical components: the user-facing website, the product database, and the payment processing service. He knows the business can't tolerate more than 5 minutes of downtime (RTO = 5 minutes) and can afford to lose at most 1 second of transactions (RPO = 1 second).
Jamal's first step is to implement High Availability within a single region. He deploys the website on multiple 'Compute Engine' virtual machines (VMs) spread across three availability zones in 'us-central1' (Iowa). He puts a 'Cloud Load Balancer' in front of them. If one VM crashes, the load balancer automatically stops sending traffic to it and routes requests to the remaining healthy VMs. For the database, he uses 'Cloud SQL for PostgreSQL' with a 'high availability' configuration. This creates a 'primary' instance and a 'standby' instance in another zone. If the primary fails, Google automatically 'failovers' to the standby within about 60 seconds, preserving the data.
But Jamal also needs Disaster Recovery for a region-wide outage (e.g., a massive power grid failure in Iowa). He creates a second deployment in 'europe-west1' (Belgium). This is his DR region. He sets up 'Cross-Region Replication' for his Cloud SQL database. The primary database in Iowa continuously copies changes to a read-only replica in Belgium. He configures 'Cloud DNS' with a 'failover routing policy': if his health check (a tiny probe that pings the Iowa endpoints) fails for 30 seconds, DNS automatically starts resolving shopfast.com to the Belgian IP addresses instead. This is 'global server load balancing'.
Jamal periodically runs 'disaster recovery drills' — he literally turns off the Iowa region (with a test application version) to verify the failover works. He monitors everything with 'Cloud Monitoring' dashboards showing latency and error rates. He also uses 'Cloud Armor' to protect against DDoS attacks, which can bring down a region. By combining HA (multiple zones) and DR (multiple regions), Jamal ensures that even if a tornado hits Iowa, ShopFast keeps selling. The key actions he takes are:
Define RTO/RPO with business stakeholders.
Deploy across multiple zones for HA.
Deploy across multiple regions for DR.
Use managed services (Cloud SQL, Load Balancing) to automate failover.
Test the failover quarterly.
The Google Professional Cloud Developer exam tests your ability to choose the right disaster recovery and high availability design, not just memorise definitions. Expect multiple-choice and multiple-select questions that present a business scenario (e.g., 'Your app serves users globally and must have an RTO of 1 minute. Which architecture is most cost-effective?') and ask you to pick the best Google Cloud solution. The traps often involve confusing HA with DR, or choosing a single-region solution when multi-region is required.
Exam topics you must know:
RTO vs. RPO: You will be given a business requirement (e.g., 'We can lose 5 minutes of data') and you must select the corresponding RPO. RPO is about data loss, RTO is about downtime. Traps: swapping them.
Multi-region vs. multi-zone: Multi-zone (within one region) handles local failures (e.g., a rack fire). Multi-region handles regional failures (e.g., an earthquake). If the question says 'entire region outage', do NOT pick multi-zone only.
Failover strategies: 'Active-passive' (one region runs, the other is standby) vs. 'active-active' (both regions serve traffic). Active-passive is cheaper but has slower failover; active-active is more expensive but provides lower latency. The exam tests cost vs. performance trade-offs.
Google Cloud services: Cloud Load Balancing (HTTP/S for HTTPS traffic, internal for VPC), Cloud DNS (with routing policies like 'failover' or 'geo'), Cloud Spanner (for strong consistency across regions), Cloud SQL and Cloud Bigtable (for eventual consistency with replication). Traps: picking Spanner when eventual consistency is acceptable, or picking Cloud SQL for a globally distributed app expecting sub-second failover.
Disaster Recovery types: 'Backup and restore' (cheapest, slowest), 'Pilot light' (small copy scaled up on demand), 'Warm standby' (reduced-size copy running), 'Hot standby' (full copy running, fastest failover). The exam will ask which type matches a given cost and RTO.
Key definitions to memorise:
Availability zone: A distinct location within a region, isolated from other zones for power and cooling.
Region: A geographic area with multiple zones.
Failover: Automatically switching to a standby system on failure.
Health check: A probe that checks if a backend is responding correctly.
Common trap pattern: The question says 'The app must be highly available within a single region.' The wrong answer adds another region (too expensive and unnecessary). The correct answer uses multiple zones with a load balancer. Another trap: 'The database must have zero data loss across regions.' You need Spanner (strong consistency), not Cloud SQL (may lose last few writes during failover). Study the Google Cloud Architecture Framework under 'Reliability' — that is where these exam concepts live.
Disaster Recovery (DR) answers 'how do I restart after a catastrophe?' while High Availability (HA) answers 'how do I survive a single component failure without interruption?'
RTO (Recovery Time Objective) is the maximum acceptable downtime; RPO (Recovery Point Objective) is the maximum acceptable data loss — they are not the same.
Google Cloud requires you to deploy across at least two availability zones for HA and across two regions for DR; no automatic DR is provided for your custom code.
Active-passive DR (one region live, one standby) is cheaper but has slower failover than active-active DR (both regions live, load-balanced).
For zero data loss across regions, you must use a strongly consistent database like Cloud Spanner, not an eventually consistent one like Cloud SQL.
Always test your disaster recovery plan periodically with drills — a documented but untested plan is worthless.
These come up on the exam all the time. Here's how to tell them apart.
High Availability (HA)
Prevents downtime from single component failures like a server crash.
Operates within a single region, across multiple availability zones.
Aims for zero downtime; failover is instant or near-instant.
Disaster Recovery (DR)
Recovers the entire application after a catastrophic event like a region outage.
Spans across two or more geographic regions far apart.
Acceptable downtime (RTO) is planned, typically minutes to hours.
Active-Passive DR
Only one region serves live traffic; the other region is idle (standby).
Cheaper because standby resources are smaller or billed minimally.
Failover time is slower (minutes) because standby must be scaled up or promoted.
Active-Active DR
Both regions serve live traffic simultaneously, sharing the load.
More expensive because both regions run at full capacity.
Failover is nearly instantaneous (milliseconds) because both regions are already active.
RTO (Recovery Time Objective)
Measures the duration of downtime you can tolerate after a disaster.
Example: 'The app must be back online within 1 hour.'
Influences how quickly you must spin up DR resources and fail over.
RPO (Recovery Point Objective)
Measures the amount of data loss you can tolerate, measured in time.
Example: 'We can afford to lose at most 5 minutes of data.'
Influences how frequently you replicate data (e.g., every 5 minutes or synchronously).
Mistake
High Availability and Disaster Recovery are the same thing — both mean 'the app is always up.'
Correct
High Availability is about handling component failures within a system (e.g., a server crashing) without downtime. Disaster Recovery is about recovering from a catastrophic event (e.g., a region outage) that takes the whole system down, and it involves a planned downtime window (RTO).
People think both just mean 'no downtime,' but HA aims for zero downtime during expected failures, while DR accepts short downtime to recover from unexpected catastrophes.
Mistake
If I use Google Cloud, I don't need to worry about disaster recovery — Google handles all of it.
Correct
Google provides infrastructure and tools, but you as the developer must design your application and its data replication strategy. For example, you must configure Cloud SQL cross-region replication or use Spanner; Google does not automatically replicate your custom app data across regions.
Cloud providers market their 'highly available infrastructure,' leading beginners to believe the responsibility stops there. In reality, the shared responsibility model means you own the application-level DR plan.
Mistake
A multi-region deployment always guarantees zero data loss.
Correct
Multi-region replication, especially with eventually consistent databases like Cloud Bigtable or Cloud SQL, may lose the last few seconds of writes during a sudden failure (failover is asynchronous). Only 'strongly consistent' services like Cloud Spanner guarantee zero data loss across regions.
Beginners assume all replication is synchronous. In practice, synchronous replication across long distances is slow, so most services use asynchronous replication for multi-region setups.
Mistake
The cheapest disaster recovery option is a 'hot standby' because it runs all the time and is ready instantly.
Correct
A hot standby is the most expensive option because it involves running a full duplicate infrastructure at all times. The cheapest option is 'backup and restore' which stores backups in another region and spins up resources only during restoration.
People confuse 'always ready' with 'cheap.' Hot standby's cost from running idle resources surprises beginners who think DR is just about backup storage.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A zone is a single data centre within a region (like a building). A region is a geographic area with multiple zones (like a city). For High Availability, you deploy across zones. For Disaster Recovery, you deploy across regions.
Yes, but only with 'cross-region replication' which is asynchronous. This means you may lose the last few writes (up to a few seconds) during a failover. For zero data loss, use Cloud Spanner which supports synchronous replication across regions.
If you need fast failover and both regions serving traffic to reduce latency, choose active-active (more expensive). If you can tolerate a few minutes of failover time and want to save cost, choose active-passive where only one region serves traffic and the other is a standby.
A health check is a simple request (e.g., pinging a URL) that your load balancer sends to your instances to see if they are alive. It is important because without it, the load balancer will keep sending traffic to a broken server, causing errors for users.
No, not by default. You must explicitly configure replication for services like Cloud SQL, Cloud Storage (using multi-region buckets), or Cloud Spanner. Your custom application code and data are your responsibility.
During a failover, traffic is automatically rerouted from the failed region or zone to the healthy one. The load balancer stops sending new requests to the unhealthy backends, and DNS starts pointing users to the backup region. Any in-flight transactions may be lost depending on your database's replication mode.
You've finished Disaster Recovery and High Availability. Continue through the PCD study guide to build a complete picture of the exam.
Done with this chapter?