Google Cloud zonal deployment archetype

Last reviewed 2024-11-20 UTC

This section of the Google Cloud deployment archetypes guide describes the zonal deployment archetype.

In a cloud architecture that uses the basic zonal deployment archetype, the application runs in a single Google Cloud zone, as shown in the following diagram:

To be able to recover from zone outages, you can use a dual-zone architecture where a passive replica of the application stack is provisioned in a second (failover) zone, as shown in the following diagram:

If an outage occurs in the primary zone, you can promote the standby database to be the primary (write) database and update the load balancer to send traffic to the frontend in the failover zone.

Note: The Mexico, Montreal, and Osaka regions have three zones within one or two physical data centers. These regions are in the process of expanding to at least three physical data centers. For more information, see Cloud locations and Google Cloud Platform SLAs. To help improve the reliability of your workloads, consider a multi-regional deployment.

Use cases

The following are examples of use cases for which the zonal deployment archetype is an appropriate choice:

• Cloud development and test environments: You can use the zonal deployment archetype to build a low-cost environment for development and testing.
• Applications that don't need high availability: The zonal deployment archetype might be sufficient for applications that can tolerate downtime.
• Low-latency networking between application components: A single-zone architecture might be well suited for applications such as batch computing that need low-latency and high-bandwidth network connections among the compute nodes.
• Migration of commodity workloads: The zonal deployment archetype provides a cloud migration path for commodity on-premises apps for which you have no control over the code or that can't support architectures beyond a basic active-passive topology.
• Running license-restricted software: The zonal deployment archetype might be well suited for license-restricted systems where running more than one instance at a time is either too expensive or isn't permitted.

Design considerations

When you build an architecture that's based on the zonal deployment archetype, consider the potential downtime during zone and region outages.

Zone outages

If the application runs in a single zone with no failover zone, then when a zone outage occurs, the application can't serve requests. To prevent this situation, you must maintain a passive replica of the infrastructure stack in another (failover) zone in the same region. If an outage occurs in the primary zone, you can promote the database in the failover zone to be the primary database, and ensure that incoming traffic is routed to the frontend in the failover zone. After Google resolves the outage, you can choose to either fail back to the primary zone or make it the new failover zone.

Note: The Mexico, Montreal, and Osaka regions have three zones within one or two physical data centers. These regions are in the process of expanding to at least three physical data centers. For more information, see Cloud locations and Google Cloud Platform SLAs. To help improve the reliability of your workloads, consider a multi-regional deployment.

Region outages

If a region outage occurs, you must wait for Google to resolve the outage and then verify that the application works as expected. If you need robustness against region outages, consider using the multi-regional deployment archetype.

Reference architecture

For a reference architecture that you can use to design a zonal deployment on Compute Engine VMs, see Single-zone deployment on Compute Engine.