This section of theGoogle Cloud deployment archetypes guide compares the deployment archetypes in terms of availability, robustnessagainst outages, cost, and operational complexity.

The following table summarizes the comparative analysis for the basic deploymentarchetypes: zonal, regional, multi-regional, and global. For the hybrid andmulticloud topologies, the deployment archetype that's used for theGoogle Cloud part of the topology influences the availability, robustnessagainst outages, cost, and operational complexity.

The following sections describe the comparative analysis that's summarizedin the preceding table.

Infrastructure availability

The following sections describe the differences in infrastructure availabilitybetween the deployment archetypes.

Zonal, regional, multi-regional, and global deployment archetypes

Google Cloud infrastructure is built to support a target availability of99.9% for your workload when you use the zonal deployment archetype, 99.99% forregional deployments, and 99.999% for multi-regional and global deployments.These availability numbers are targets for the platform-level infrastructure.

The availability that you can expect from an application that's deployed inGoogle Cloud depends on the following factors besides the deploymentarchetype:

• Design of the application
• Number of interdependent tiers in the application stack
• UptimeService Level Agreements (SLAs) for the Google Cloud services used
• Amount of redundant resources
• Location scopes of the resources

For more information, seeBuilding blocks of reliability in Google Cloud.

Hybrid and multicloud deployment archetypes

For a hybrid or multicloud topology, the overall availability depends on theinfrastructure in each environment and the interdependencies between theenvironments.

• If critical interdependencies exist between components in Google Cloudand components outside Google Cloud, the overall availability is lowerthan the availability of the component that provides the least availabilityacross all the environments.
• If every component of the application is deployed redundantly acrossGoogle Cloud and on-premises or in other cloud platforms, theredundancy ensures high availability.

Robustness of infrastructure against zone and region outages

The following sections describe the differences between the deploymentarchetypes in terms of the ability of the infrastructure to continue to supportyour workloads in the event of Google Cloud zone and region outages.

Zonal deployment archetype

An architecture that uses the basic single-zone deployment archetype isn'trobust against zone outages. You must plan for recovering from zone outagesbased on your recovery point objective (RPO) and recovery time objective (RTO).For example, you can maintain a passive or scaled-down replica of theinfrastructure in another (failover) zone. If an outage occurs in the primaryzone, you can promote the database in the failover zone to be the primarydatabase and update the load balancer to send traffic to the frontend in thefailover zone.

Regional deployment archetype

An architecture that uses the regional deployment archetype is robust againstzone outages. A failure in one zone is unlikely to affect infrastructure inother zones. The RTO is near zero if data is replicated synchronously. However,when an outage affects an entire Google Cloud region, the applicationbecomes unavailable. Plan for recovering from outages according to your RPO andRTO for the application. For example, you can provision a passive replica of theinfrastructure in a different region, and activate the replica during regionoutages.

Multi-regional and global deployment archetypes

An architecture that uses the multi-regional or global deployment archetype isrobust against zone and region outages. The RTO is near zero if data isreplicated synchronously. An architecture where the application runs as aglobally distributed location-unaware stack provides the highest level ofrobustness against region outages.

Hybrid and multicloud deployment archetypes

The robustness of a hybrid and multicloud architecture depends on the robustnessof each environment (Google Cloud, on-premises, and other cloudplatforms), and the interdependencies between the environments.

For example, if every component of an application runs redundantlyacross both Google Cloud and another environment (on-premises oranother cloud platform), then the application is robust againstanyGoogle Cloud outages. If critical interdependencies exist betweencomponents in Google Cloud and components that are deployed on-premises oron other cloud platforms, the robustness against Google Cloud outagesdepends on the robustness of the deployment archetype that you use for theGoogle Cloud part of the architecture.

Cost of Google Cloud resources

The cost of the Google Cloud resources that are required for anapplication depends on the Google Cloud services that you use, the numberof resources that you provision, the period for which you retain or useresources, and the deployment archetype that you choose. To estimate the cost ofGoogle Cloud resources in an architecture based on any deploymentarchetype, you can use theGoogle Cloud Pricing Calculator.

The following sections describe the differences in the cost of theGoogle Cloud resources between the various deployment archetypes.

Zonal versus regional and multi-regional deployment archetypes

When compared with an architecture that uses the zonal deployment archetype, anarchitecture that uses the multi-regional deployment archetype might incur extracosts for redundant storage. Also, for any network traffic that crosses regionboundaries, you need to consider the cross-region data transfer costs.

Global deployment archetype

With this archetype, you have the opportunity to use highly available globalresources, like a global load balancer. The cost of setting up and operating thecloud resources can be lower than a multi-regional deployment where youprovision and configure multiple instances of regional resources. However,global resources might entail higher costs in some cases. For example, theglobal load balancer requiresPremium Tier networking, but for regional load balancers, you can chooseStandard Tier.

Hybrid and multicloud deployment archetypes

In a hybrid or multicloud deployment architecture, you need to consideradditional costs along with the cost of the resources that you provision. Forexample, consider costs like hybrid or cross-cloud networking, and the cost ofmonitoring and managing the resources across multiple environments.

Considerations for all the deployment archetypes

When you assess the cost of running a cloud workload, you need to consideradditional costs along with the cost of the Google Cloud resources thatyou provision. For example, consider personnel expenses and the overhead coststo design, build, and maintain your cloud deployment.

To compare the cost of Google Cloud resources across the deploymentarchetypes, also consider the cost perunit of work that the applicationperforms. Identify units of work that reflect the business drivers of theapplication, like the number of users the application serves or the number ofrequests processed.

By carefully managing the utilization of your Google Cloud resources andadopting Google-recommended best practices, you can optimize the cost of yourcloud deployments. For more information, seeGoogle Cloud Well-Architected Framework: Cost optimization.

Operational complexity

This following sections describe the differences in operational complexitybetween the deployment archetypes, which depends on the number of infrastructureresources, features, and application stacks that you need to operate.

Zonal versus regional and multi-regional deployment archetypes

An architecture that's based on the zonal deployment archetype is easier to setup and operate when compared with the other deployment architectures. Anapplication that runs redundantly in multiple zones or regions requires higheroperational effort, due to the following reasons:

• The status of the application stacks in multiple locations mustbe monitored, both at the stack level and for each component of the application.
• If a component becomes unavailable in any location, in-processrequests must be handled gracefully.
• Application changes must be rolled out carefully.
• The databases must be synchronized across all the locations.

Global deployment archetype

The global deployment archetype lets you use highly available global resourceslike a global load balancer and a global database. The effort to set up andoperate cloud resources can be lower than a multi-regional deployment where youneed to manage multiple instances of regional resources. However, you mustcarefullymanage changes to global resources.

The effort to operate an architecture that uses the global deployment archetypealso depends on whether you deploy a distributed location-unaware stack ormultiple regionally isolated stacks:

• A distributed, location-unaware application can be expanded andscaled with greater flexibility. For example, if certain componentshave critical end-user latency requirements in only specific locations,you can deploy these components in the required locations and operatethe remainder of the stack in other locations.
• An application that's deployed as multiple regionally isolatedstacks requires higher effort to operate and maintain, due to the followingfactors:
  • The status of the application stacks in multiple locations must bemonitored, both at the stack level and for each component.
  • If a component becomes unavailable in any location, in-process requestsmust be handled gracefully.
  • Application changes must be rolled out carefully.
  • The databases must be synchronized across all the locations.

Hybrid and multicloud deployment archetypes

Hybrid or multicloud topologies require more effort to set up and operate thanan architecture that uses only Google Cloud.

• Resources must be managed consistently across the on-premises andGoogle Cloud topologies.
• You need a way to efficiently provision and manage resources across multipleplatforms. Tools like Terraform can help to reduce the provisioning effort.
• Security features and tools aren't standard across cloud platforms. Yoursecurity administrators need to acquire skills and expertise to manage thesecurity of resources distributed across all the cloud platforms that youuse.