Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
A Business Continuity Plan starts by setting two key goals. The Recovery Time Objective (RTO) is the maximum time you can afford to be offline after a failure. The Recovery Point Objective (RPO) is the maximum amount of data, measured in time, that you can afford to lose. These numbers guide the choice of a recovery pattern that balances cost with the need to keep your application running.
A Cold Standby pattern is the most cost-effective option. In normal times, no backup infrastructure is running. When a disaster happens, you must create resources like virtual machines from scratch, often using saved snapshots or images. This saves money but results in a higher RTO because the setup takes time, and a higher RPO because data is only as fresh as the last backup.
A Warm Standby pattern keeps a scaled-down, minimal version of your system running in a backup region. This "pilot light" approach means core services are always on, allowing for a faster recovery than a cold standby. If the primary site fails, you can quickly scale up the backup using Managed Instance Groups to handle full production traffic, offering a good balance of cost and speed.
A Hot Standby (or active-active) pattern provides the highest resilience for mission-critical systems. Traffic is distributed across multiple regions at the same time using Cloud Load Balancing, so there is no single point of failure. Data is replicated synchronously, giving you the lowest possible RTO and RPO. This pattern is designed for maximum uptime, keeping services available even if an entire region fails.
Choosing the right pattern means weighing the cost of the solution against the financial impact of downtime. You should use Regional and Multi-region Resources to protect against localized failures. It is crucial to regularly test your disaster recovery plan to ensure your chosen pattern will actually work and meet your RTO and RPO goals during a real emergency.
Data Resiliency ensures your information is safe and available during a disaster. The main strategy is to use managed, multi-regional storage services like Cloud Storage, Firestore, and Spanner. These services automatically copy and distribute your data across different geographic areas to survive a regional outage. This contrasts with regional resources, which can be protected by taking snapshots and copying them to another location.
Cloud Storage provides extremely high durability. For the best availability, you can choose Dual-region or Multi-region buckets, which store data in at least two separate geographic places. An optional feature called Turbo replication for dual-regions guarantees a Recovery Point Objective (RPO) of 15 minutes. You can also set up cross-bucket replication to asynchronously copy data between independent buckets, which is useful for meeting data sovereignty rules.
Managed databases have built-in features for cross-region replication. Cloud SQL supports Cross-region Replicas that can be promoted to become the primary database if the main region fails. Spanner and Bigtable also provide automatic replication to keep data synchronized across zones or regions. For high availability, services often use a primary instance in one zone and a standby in another, with some (like Spanner) using a witness region to help agree on data updates.
To protect against accidental deletion or corruption, you use automated snapshot management and Point-in-Time Recovery (PITR). PITR lets you restore a database to its exact state at any specific minute within a recent window (like the last seven days). Scheduled backups provide longer-term retention. These tools, along with defined retention policies, ensure you can meet both your recovery objectives and any legal requirements for keeping data.
A complete disaster recovery strategy must balance the Recovery Time Objective (RTO) and the Recovery Point Objective (RPO). While multi-regional storage services protect the data, your compute resources (like Compute Engine virtual machines) must also be configured to start up or failover in a healthy region. The most reliable approach is an active-active architecture, where workloads run in parallel across two locations, providing the fastest recovery and least data loss.
Traffic management and failover mechanisms are how you keep services online during an outage. Using automated failover helps meet your Recovery Time Objectives (RTO) by reducing the need for manual steps. Google Cloud combines several services to make different zones or regions work together to handle traffic when one part fails.
Global Cloud Load Balancing is the main tool for directing user traffic. It sends users to the nearest healthy backend resource. It relies on continuous health checks—automated tests that monitor if instances are working. If a check fails in one zone or region, the load balancer automatically reroutes traffic to a healthy location, providing seamless failover.
Cloud DNS adds another layer of control with routing policies. These policies can be set up to redirect traffic seamlessly if a region goes down. For example, failover routing automatically switches users to a backup IP address when the primary destination is unhealthy. Other policies, like geolocation routing or weighted round robin, help distribute traffic intelligently across your global resources.
Managed Instance Groups (MIGs) help with automated recovery at the zonal level. A MIG maintains a set number of virtual machines across zones using a blueprint called an instance template. If a VM fails, the MIG automatically recreates it. This autohealing capability, combined with data stored on regional persistent disks (which survive a zone failure), provides a strong foundation for recovering from problems in a single zone.
For the highest availability, you need a multi-region architecture. This protects against large-scale disasters affecting an entire geographic area. The strategy involves data replication—copying data between regions—to ensure data is available and consistent. By spreading resources globally and using the traffic management tools above, you can achieve very high availability and significantly reduce the risk of total service loss.
Prepare and test your skills
Prepare and test your skills
The Recovery Time Objective (RTO) is the maximum time you can afford to be offline after a failure, while the Recovery Point Objective (RPO) is the maximum amount of data, measured in time, that you can afford to lose. These two goals guide the choice of a recovery pattern that balances cost with the need to keep your application running.
You should use a Cold Standby pattern when you want the most cost-effective option, because no backup infrastructure is running during normal times and you create resources from scratch after a disaster. However, this pattern results in a higher Recovery Time Objective (RTO) and a higher Recovery Point Objective (RPO) compared to Warm Standby or Hot Standby patterns, which offer faster recovery and lower data loss at greater cost.
Global Cloud Load Balancing directs user traffic to the nearest healthy backend resource by relying on continuous health checks that monitor if instances are working. If a health check fails in one zone or region, the load balancer automatically reroutes traffic to a healthy location, providing seamless failover without manual steps.
Implement a Hot Standby (Active-Active) pattern with equal 100% compute capacity provisioned across both regions, serving live traffic concurrently through an external Application Load Balancer.
Implement a Zonal High Availability pattern using synchronous database replication across multiple zones within the primary region and auto-scaling instance groups.
Implement a Warm Standby (Active/Passive) pattern using asynchronous cross-region database replication and a minimal, scaled-down Compute Engine managed instance group in the secondary region ready to scale up upon failover.
Implement a Cold Standby pattern that exports database backups and snapshots to a multi-region Cloud Storage bucket every 6 hours, and provisions compute instances using automated scripts after a disaster is declared.
An enterprise is designing a business continuity and disaster recovery (DR) strategy on Google Cloud for a mission-critical web application. The application consists of a stateless web/application tier and a transactional database backend.
The business continuity plan establishes the following operational criteria:
Which architectural pattern should you select to meet these requirements?