Your favourite streaming service going down on a Friday night, or your bank being inaccessible when you need to check your balance — these are the real-world consequences of not having a highly available and disaster-resilient network. When you design networks for the Google Cloud Professional Network Engineer exam, you need to know how to build systems that can handle failures without anyone noticing, and how to recover quickly when something huge goes wrong.
Jump to a section
A simple way to picture Network Design for High Availability and Disaster Recovery
A hospital emergency room charge nurse manages the flow of patients and resources in a city hospital. They have to make sure that if one part of the hospital fails, like the power in the main wing, the whole hospital doesn't shut down. This is their version of high availability. They have backup generators for power, backup staff on call, and a separate trauma wing that can take over if the main ER is overwhelmed. They also plan for disaster recovery. If a flood destroys the ground floor, they have a pre-agreed plan to move all critical patients to a sister hospital across town, and they have paper records ready because the computers might be down.
The hospital has two identical generator rooms on different floors. If one generator fails, the other automatically kicks in within seconds. This is like having two data centres in different geographic zones. The hospital also has a 'disaster kit' with printed patient charts, a list of nearby hospitals with available beds, and pre-installed phone lines to coordinate transfers. They run a drill every six months to practise this move, timing how quickly they can evacuate the ER. The goal is zero downtime for patient care, even if the building is compromised.
Network design for high availability and disaster recovery is about building your network so it doesn't break, and if it does break, you can fix it fast. Think of high availability as having backups ready to take over instantly so there's almost no interruption. Disaster recovery is your plan for getting everything back to normal after a major failure, like a fire or a natural disaster.
Let's start with some key terms. 'High availability' (often shortened to HA) means a system that stays running even when some parts fail. The goal is to keep your service 'up' close to 100% of the time. 'Disaster recovery' (or DR) is the process of getting your network and services back online after a catastrophic event. 'Redundancy' means having duplicate components so if one fails, another takes over. 'Failover' is the automatic switch from a failed component to a working backup.
In Google Cloud, you design for HA and DR using concepts like 'regions' and 'zones'. A region is a specific geographic location, like London or Tokyo. Each region has at least three zones, which are separate data centres with their own power and cooling. If one zone goes down, you can have your services running in another zone within the same region. This protects you from local failures. For true disaster recovery, you often deploy across multiple regions hundreds of miles apart so a regional outage doesn't take everything down.
'Load balancing' is another critical HA tool. It distributes incoming traffic across multiple servers or instances. If one server fails, the load balancer sends traffic to the healthy ones. Google Cloud's 'Cloud Load Balancing' is a global service that can direct users to the closest region, improving speed and availability.
For disaster recovery, you need a plan. Common strategies include: - 'Active-Passive': You run your primary site normally and keep a backup site on standby. During a disaster, you switch (fail over) to the backup site. - 'Active-Active': Both sites run live traffic simultaneously. If one fails, the other handles all traffic. This is more complex but gives near-instant failover.
To make failover work, you use 'DNS' (Domain Name System) to point users to the right site. Google Cloud's 'Cloud DNS' can use health checks to automatically route users away from a failing region. You also need to think about data. Replicate your databases across zones or regions using tools like 'Cloud SQL' for managed databases or 'Spanner' for global consistency.
'SLAs' (Service Level Agreements) are contracts that guarantee a certain level of uptime, usually expressed as a percentage like 99.99%. 'Nines' is IT slang for these percentages — 99.99% is 'four nines'. Designing for HA helps you meet these SLAs.
Finally, you should test your disaster recovery plan regularly. Google Cloud offers 'Disaster Recovery drills' to simulate failures and ensure your plan works. Without testing, you might find out during a real disaster that your backup is broken or your team doesn't know the procedures.
Identify Critical Components
List every part of your application that must stay running: web servers, databases, authentication services, etc. This prioritises where to invest in redundancy.
Choose High Availability Strategy
Decide if you need zone-level HA (multiple zones in one region) or region-level DR (multiple regions). For most production workloads, you use both: HA in the primary region and DR in a secondary region.
Configure Multi-Zone Deployment
Deploy your application across at least two zones in the primary region. Use a regional load balancer that can detect zone failures and route traffic to healthy zones.
Set Up Data Replication
Replicate your database to a secondary zone (for HA) and a secondary region (for DR). Google Cloud services like Cloud SQL or Spanner manage this replication automatically.
Implement Automated Failover
Configure health checks on your load balancer to automatically stop sending traffic to unhealthy instances. For DR, set up a second load balancer and DNS routing policy that switches regions when primary is down.
Document and Test the Disaster Recovery Plan
Write a runbook with step-by-step recovery procedures. Run quarterly drills to verify the plan works. Simulate a zone or region failure and measure recovery time.
A real IT professional at a mid-size e-commerce company is asked to design a network for their new cloud application. The company sells globally and cannot afford downtime during peak shopping seasons like Black Friday. The senior engineer starts by identifying critical components: the web servers, the database, and the checkout service. They decide to use two Google Cloud regions: one in Europe (for European customers) and one in the US (for North American customers).
Step by step, the engineer does the following:
Selects a primary region (us-central1) and a secondary region (europe-west1) for disaster recovery.
Deploys the application in two separate zones within the primary region for high availability against zone failures.
Configures a global load balancer that sends users to the closest healthy region. If us-central1 goes down, traffic automatically shifts to europe-west1.
Sets up a replicated Cloud SQL database across the two regions. The primary database is in us-central1; the read replica in europe-west1 can be promoted to primary if the main region fails.
Writes a disaster recovery runbook — a document that lists every step the team must take during a failure, including who to contact, how to promote the replica, and how to update DNS settings.
Automates failover using health checks. The load balancer pings the application every 5 seconds. If it gets no response, it marks that instance as unhealthy and stops sending traffic.
Schedules quarterly disaster recovery drills. The team simulates a regional outage by blocking traffic to us-central1. They time how long it takes to recover, aiming for under 5 minutes.
During a real incident — a major power outage in Iowa affecting us-central1 — the system automatically fails over to europe-west1 within 30 seconds. The company never goes fully offline; they just see a slight increase in latency for US users. The runbook is followed to promote the replica database, and a post-mortem identifies a need to add a third region for better resilience. This is what an IT professional actually does: they design, automate, test, and iterate to keep the business running.
The Google Cloud Professional Network Engineer exam tests your understanding of how to architect resilient networks on Google Cloud. Expect multiple-choice and multiple-select questions that require you to pick the correct configuration for a given scenario. They love to test the differences between zone-level and region-level redundancy, and when to use each.
Key concepts the exam tests include: - 'Multi-region vs. single-region designs': You need to know when to use multiple regions (for DR) versus multiple zones within one region (for HA). - 'Failover strategies': Active-passive vs. active-active. Questions often describe a use case and ask which pattern matches. - 'Cloud Load Balancing types': Global external HTTP(S) load balancer for cross-region failover, vs. regional internal load balancer for zone-level HA. - 'Cloud DNS routing policies': Geofencing, weighted round-robin, and failover policies. They test how to use DNS to direct traffic away from failed regions. - 'Data replication': Cloud SQL replicas, Spanner global distribution, and Cloud Storage cross-region replication. Know which service supports what consistency model. - 'Service Level Agreements (SLAs)': Understand how many 'nines' a design provides. If you deploy across two zones, you get 99.99% uptime for some services.
Common traps include:
Confusing a 'region' with a 'zone'. A region is a collection of zones. A zone failure is handled by deploying in multiple zones. A region failure requires a separate region.
Assuming that a DNS failover is instant. Real-world DNS changes propagate slowly (minutes to hours) due to caching, so true HA designs use load balancer health checks that don't rely on DNS switching.
Picking a single data centre (zone) for a critical service. The correct answer nearly always involves at least two zones.
Forgetting to replicate the database. A highly available front-end is useless if the database is a single point of failure.
To memorise: 'For HA, use two zones in the same region. For DR, use two regions with active-passive or active-active failover. For both, automate failover and test regularly.' Expect 3-4 questions on this topic. The correct answer pattern often includes the words 'Cloud Load Balancing', 'regional', 'multi-zone', and 'health check'.
High availability uses multiple zones within a single region to survive local data centre failures.
Disaster recovery uses multiple regions to survive a full region outage from a natural disaster or major outage.
Cloud Load Balancing with health checks is the primary tool for automatic failover across zones or regions.
Data replication across regions is essential for disaster recovery — without it, you can't restore service quickly.
Test your disaster recovery plan regularly with drills, or you may discover failures during a real disaster.
Active-passive DR is simpler and cheaper than active-active, but active-active provides faster failover.
DNS is not suitable for instant failover because of caching; use load balancer health checks for sub-minute switching.
These come up on the exam all the time. Here's how to tell them apart.
High Availability (HA)
Protects against local failures like a server crash or zone power outage
Uses multiple zones within one region
Automatically fails over via load balancer health checks in seconds
Disaster Recovery (DR)
Protects against catastrophic events like a regional natural disaster
Uses multiple regions separated by large distances
Requires manual or DNS-based failover that can take minutes to hours
Active-Passive DR
Secondary site sits idle or with minimal configuration
Simpler to manage and lower cost
Failover may have some downtime (minutes)
Active-Active DR
Both sites handle live traffic simultaneously
More complex with data consistency challenges
Failover is near-instant with no noticeable downtime
Zone-Level Redundancy
Protects against a single data centre failure
Lower latency as resources are in same city
Less expensive than multi-region
Region-Level Redundancy
Protects against a full region outage
Higher latency due to geographic distance
More expensive due to replicating across regions
Cloud Load Balancing (HTTP/S)
Health-check driven, fails over in seconds
Works within the same region or across regions
Requires a load balancer resource
DNS-based Failover
Relies on DNS TTL propagation, slow (minutes)
Simple to set up without a load balancer
Can route users to any external site
Mistake
High availability means 100% uptime with zero failures.
Correct
High availability aims for near-100% uptime (e.g., 99.99%), but no system is completely failure-proof. It's about minimising downtime, not eliminating all risk.
Beginners often expect perfection because of marketing terms like 'always on', but real systems can still fail due to bugs or rare cascading issues.
Mistake
If I use multiple zones in one region, I'm protected against any disaster.
Correct
Multiple zones protect against local failures (like a data center power outage), but not regional disasters (like a hurricane or earthquake that takes down the whole region). For full disaster recovery, you need multiple regions.
It's easy to assume 'redundancy' in one area is enough, but beginners don't think about the scale of a region-level event.
Mistake
Disaster recovery is just about backing up data.
Correct
DR includes backing up data, but also covers the entire process: having standby infrastructure, network configurations, DNS routing, failover procedures, and testing. A backup is useless if you can't restore it or bring up the application.
People come from a personal backup mindset (just copy files) and don't realise the complexity of restoring an entire live service.
Mistake
DNS failover happens instantly, so it's fine for high availability.
Correct
DNS changes propagate slowly due to caching by internet service providers and clients. True HA uses load balancer health checks and automated failover at the network layer, not DNS-dependent switching.
Most people think of DNS as instant because they type a new address and it works, but that's their local cache. Global DNS caches can take minutes to update.
Mistake
An active-active setup is always better than active-passive.
Correct
Active-active is more complex and expensive because you need to handle data consistency across locations. Active-passive can be simpler and cheaper while still meeting DR goals. The choice depends on your requirements.
Beginners assume 'more' is always 'better', without considering cost and operational overhead.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
High availability keeps your system running during small, local failures (like a server crash) by having backup components ready. Disaster recovery is the plan for restoring service after a major catastrophe (like a flood) that wipes out a whole data centre.
At least two regions, ideally hundreds of miles apart. This protects you from a regional event like a power grid failure or earthquake. One is your primary, the other is your secondary for failover.
A health check is a simple test (like a ping) that the load balancer sends to your servers every few seconds. If the server doesn't respond, the load balancer marks it unhealthy and stops sending traffic there.
DNS failover works but it's slow — it can take minutes to update because of caching. For sub-second failover, you should use a load balancer with automated health checks instead.
Active-passive means your primary site handles all traffic, and your secondary site sits idle (or with a minimal configuration). During a disaster, you manually or automatically switch all traffic to the secondary site.
Yes. Regular drills are crucial because they reveal issues like misconfigured backups, missing permissions, or stale documentation. Without testing, you risk finding failures during a real emergency.
You've finished Network Design for High Availability and Disaster Recovery. Continue through the PCNE study guide to build a complete picture of the exam.
Done with this chapter?