Google Cloud Landing Zone Comparison

When researching how to set up your Landing Zone in GCP you come across different options provided by Google. In this blog post, we compare several key aspects of the different solutions. We had a deep look into these solutions and rolled them out in a GCP Test Organization to evaluate how they perform. After reading this blog post you will understand what the different options are, which features they provide, how easy it is to use them and which option fits best to your use-case.

Your Options to Create Google Landing Zones

Google Cloud setup checklist

In the GCP web console, you can easily set up a basic cloud foundation via a wizard called “Set up your Foundation”. It is based on the Cloud setup checklist by Google. It covers the most relevant topics that should be considered for a secure and scalable cloud foundation.

It does not apply most of the configuration directly via the web console but generates Terraform Modules. So the wizard is a nice and handy frontend for configuring some Terraform. You are guided very well through the different things that will be applied and how they are configured.

Cloud Foundation Toolkit – Example Foundation

Based on the Cloud Foundation Toolkit, Google provides a Terraform Example Foundation. It can be used as a basis and customized to individual needs. It already applies best practices and reasonable defaults that should fit many companies.

Terraform Modules are structured into different stages (bootstrap, org & resource hierarchy, environments, networking, projects, and app infrastructure). After bootstrapping the basic structure and projects by executing Terraform, it provides the option to roll out the remaining stages via CICD. Google Cloud Build and Jenkins are supported for this. But you still have to prepare the different stages by executing several commands manually before the deployment is triggered via CICD. For execution via CICD, it uses a Google Cloud Git repository per stage.

Do you need support building your Landing Zone? Book a free expert call here, to learn more about modular Landing Zone Best-Practices.

💡 We did not complete rolling out the Example Foundation as we ran into permission issues we couldn’t figure out. As we came to the conclusion that Fabric FAST is the more mature and future-proof approach, we decided not to dig deeper into rolling out the example foundation. Details about this can be found in the next sections.

Cloud Foundation Fabric FAST

Cloud Foundation Fabric is the latest approach by Google to provide a landing zone solution based on the Cloud Foundation Toolkit that is easier to apply, extend and roll out than the Terraform Example Foundation mentioned before. The result of this is the production-ready blueprint for a secure organization called Fabric FAST. It is a set of Terraform modules structured into stages (bootstrap, cicd, resource hierarchy, security, network, project factory, data platform).

Fabric FAST comes from engineers in Google Cloud’s Professional Services Organization, with a combined experience of decades solving the typical technical problems faced by GCP customers.

Beyond setting up and configuring a secure Organization and Resource Hierarchy it also provides a Project Factory which enables a GitOps Workflow to provision new projects.

Initially, you need a Super Admin for Google Workspace to set up some groups and assign people to these groups. Afterward, everything is done via Terraform.

Comparing GCP Landing Zone Options

For this comparison, we assign 1 to 3 ⭐ for different aspects that we look at for the three options. If a certain aspect is not covered at all we assign a ❌. Additionally, you can find some details about why we rated an aspect. These details also provide a deeper insight into how these aspects are covered within the options.

GCP Landing Zone Feature Comparison

The feature comparison is based on the Cloud Foundation Maturity Model (CFMM). You can read details of what these blocks mean on the CFMM Website. You can also follow the links in every row that redirect you directly to the details of the according CFMM block.

	Checklist	Fabric FAST	Example Foundation
Resource Hierarchy	⭐⭐ You can pick from 4 different hierarchies, which makes it quite easy to find a hierarchy that matches your needs. Using even more custom ones is also possible by adapting the generated Terraform code in the end.	⭐⭐ A hierarchy that fits many companies is applied by default. It is divided into common branches like networking or security. A “Teams” branch contains all end-user projects. It can be easily customized via input variables (also see Tenant Provisioning below). Applying a completely different structure requires adaption to the Terraform files. For other hierarchy structures, you can also use blueprints provided outside the context of fast stages, see “example foundations”.	⭐ The example foundation only rolls out one specific resource hierarchy, which is separated by environment (dev, non-prod, prod). Using custom hierarchies has to be implemented on your own.
Resource Policies	⭐ 3 basic policies can be applied manually via an optional step in the wizard, they are not part of the generated Terraform code.	⭐⭐⭐ Reasonable defaults are set and additional helpful policies are proposed via code comments in the terraform files. They can be enabled on demand.	⭐⭐⭐ A good amount of reasonable default policies are rolled out via Terraform. They match the best practices provided by GCPs Cloud Foundation Toolkit.
Centralized Audit Logs	⭐⭐ Basic centralized logging is configured by default. You have to follow manual steps to push logs to BigQuery, SIEM, etc.	⭐⭐⭐ By default, it captures logs from GCP’s Cloud Audit and VPC Service Control violations. It can be further customized to capture even more logs by configuring what is so-called log sinks. That way you can i.e. push logs to BigQuery or a SIEM solution.	⭐⭐⭐ Centralized Audit Logs are applied and you can configure exports to BigQuery, pub/sub systems, and more.
Cloud Tenant Tagging	❌	⭐⭐ Tenants can be tagged via the project’s YAML file of the project factory. Defaults that shall be applied to all projects can also be defined. Tags cannot be defined at the Team level yet.	⭐ It sets some default labels like environment, security contact, etc for all projects. But adding any custom tags requires modification of the terraform files.
Tenant Provisioning/Deprovisioning	❌	⭐⭐ With the project factory, GitOps-based tenant provisioning can be applied. As the project configs should better be reviewed by a cloud foundation member, it is not full self-service for the end users. When removing the project definition again, the tenant will be deprovisioned by terraform.	⭐ With stage 4-projects you can define projects, but you have to touch Terraform files to create or change projects. This feels more like coding instead of configuring it as it is done with Fabric FAST. So this approach of modifying Terraform does not seem to result in the best GitOps flow for managing projects.
Playground/Sandbox Environments	❌	⭐⭐ It provides a dedicated folder for Sandbox environments. This folder has different and softer org policies applied. That allows for quicker evaluation as more complex, but secure policies don’t have to be applied here. Sandbox projects can be created via the Project Factory just like normal projects. They are just put into the Sandbox folder. Automatic expiration of Sandbox environments is not part of Fabric FAST. It has to be implemented in the GitOps flow around it.	❌You could consider adding “Sandbox” as an additional environment with some special policies applied, but the example foundation does not provide any guidance for this.
Privileged Access Management (PAM)	⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning only necessary roles for each group.	⭐⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning only necessary roles for each group. Furthermore, service accounts are created for automation that can be impersonated by selected groups.	⭐⭐⭐ Leverages the use of groups instead of directly assigning roles to users. The principle of least privileged is applied by assigning necessary roles for each group. Furthermore, service accounts are created for automation that can be impersonated by selected groups.
Service Account Management	❌	⭐⭐⭐ With the project factory, project configuration can also include service accounts provisioning alongside their permissions. By default, iam.disableServiceAccountKeyCreation organization policy is enforced on organization-level. This is a best practice that makes use of Workload Identity Federation (WIF) as an alternative to key creation.	⭐ I couldn’t find out for sure, but one service account seems to be created per project. This SA can then be impersonated by the Cloud Build SA to perform CI/CD tasks within the project. By default, iam.disableServiceAccountKeyCreation organization policy is enforced on organization-level. This is a best practice that makes use of Workload Identity Federation (WIF) as an alternative to key creation.
Virtual Networks	⭐ Separate networks per environment are created and some basic firewall rules are applied. That way you can have the connectivity within one environment (e.g. all production services can talk to each other securely via a VPC). Advanced options like configuring peering or VPN approaches are not provided.	⭐⭐⭐ Offers sophisticated virtual network setups based on the “hub and spoke” design. One can choose the type of connectivity between the hub and spokes, which are: VPC Peering, Network Virtual Appliances (NVA), or VPN	⭐⭐⭐ Offers sophisticated virtual network setups. One can choose the type of connectivity between Dual SVPC or Hub & Spoke.
On-Prem Connect	❌	⭐⭐⭐ On-prem VPN is offered with all 3 setups of the networking stages.	⭐⭐⭐ On-Prem connectivity is provided in 3 different ways for all network setups mentioned above.
Cloud Interconnect	❌	⭐ Network Documentation only mentions that Cloud Interconnects should be done similar to the HA VPN setup. So it seems like the basis is there, but no specific support for setting up a concrete inter-connect.	⭐⭐⭐ It supports Direct and Partner Interconnect.
Managed Key Vault	❌	⭐⭐⭐ A Cloud KMS is rolled out to every environment so e.g. all production services have a way to reliably and securely share secret keys.	❌ One of the sample projects creates a KMS, but only within the project.
Automation in CI/CD	❌	⭐⭐ Supports automation with GitHub Actions, GitLab, and Source Repo. An in-depth look into the terraform code might be needed to get it to work. While it provides a great benefit, it could use more directed documentation. You can add this automation whenever you like. Even if you applied Terraform manually for some time, you can still add CI/CD later on.	⭐ Cloud Build or Jenkins can be used to roll out the Foundation. Additionally, Google Cloud Build seems to be set up for all end-user projects, so they can also quickly start with CI/CD. With Cloud Build and Jenkins, only 2 established CI/CD solutions are provided. Modern CI/CD tools such as GitHub Actions or GitLab are not supported.Documentation for rolling out the modules is heavily centered around using a CI/CD tool. So you are triggered to use it right from the beginning instead of growing your solution to using CI/CD over time to keep complexity as low as possible at the beginning.

GCP Landing Zone Non-Functional Comparison

	Checklist	Fabric FAST	Example Foundation
Extensibility/Modularity/Scalability	⭐ The checklist generates Terraform code to roll out the resource hierarchy, networking, audit logging, and a basic IAM approach. Sadly org policies are not applied via Terraform. In general, you can extend those easy-to-understand templates with whatever you need. But they don’t provide any sophisticated structure or approaches that help you scale your foundation to something big.	⭐⭐⭐ It contains several ready-made terraform modules that the different stages utilize. Each stage has outputs that are used as input variables for the next stage. It can therefore be extendable as long as a “contract” regarding input and output variables is followed. tfvars files are created and uploaded to GCP buckets that can be accessed by different stages.	⭐⭐ Terraform code is structured into different stages. So this Terraform Module structure supports scaling. The generated default projects might be a bit cumbersome to be replaced by the projects you really want to have. In general, the example foundation is not as configurable as Fabric FAST and e.g. relies quite heavily on a folder structure based on the different environments.
Terraform	⭐ Terraform is actually generated for most of the configs, but e.g. org policies are not part of that terraform code but have to be applied manually in a guided dialog in the GCP web console. Additionally, the Terraform modules are very basic and don’t provide a structure that is ready for scaling them to way more modules in the future.	⭐⭐⭐ A sophisticated structure for the Terraform modules is applied. Especially structuring them into different stages makes it scalable. Additionally transferring input from one module to the next is handled in a reasonable way. Using TerraGrunt might enhance this transfer even more.	⭐⭐ It’s a structured and sophisticated Terraform structure. But transferring data between the steps must be done completely manually. A more automated approach like TerraGrunt is not being used here.
Learning Curve	⭐⭐⭐ The learning curve is very low. You simply follow the wizard and everything you need to know is explained to a sufficient degree on the wizard pages. That way you can easily and quickly understand what it does and how to configure it.	⭐ Documentation guides through the stages, but several questions and details remain open and you have to look into the TF modules to understand details or how to customize certain areas. Especially the way IAM and PAM are handled is not documented well and is not easy to understand. Also, parameter documentation is very basic and is therefore not always helpful.	⭐ Documentation in the READMEs for the different stages is rather short and only explains the most important things. Details have to be read up in the general Google CFT docs. But it is also quite hard to understand what the modules are doing while applying them, as the steps you have to do manually are not providing you insight into the modules. It’s just some git, copy, etc commands you have to execute step by step for every stage.
Community	⭐ As the checklist is well guided by the wizard and in general it creates easily understandable Terraform modules there is not really a need for a community around it.	⭐ it is really hard to currently find resources on Fabric FAST besides the documentation by Google. Looking at the contributors and the activity on the Repo it is quite active. There are around 70 internal and external contributors to that repository. We expect the community to grow in the future.	⭐⭐ It seems to be the most commonly used solution for GCP at the moment. You can find several blog posts about it and more.
Time To Success	⭐⭐⭐ If you have a user who is Super Admin and Org Admin at hand you can really quickly set up your landing zone. Within a few hours you have everything configured and applied and you understand what it does.	⭐⭐ Considering the quite big scope of Fabric FAST, you can also rather quickly achieve your goal of a landing zone. It most likely will take you 1-2 days to go through all stages and apply them according to your needs and to roughly understand what is deployed. For understanding the Landing Zone you built here more deeply requires a few more days.	⭐⭐ Google says you can set up your foundation within a day. Looking at the problems we had when trying to roll it out, I think it takes longer. The process is also quite error-prone as you have to execute that many commands manually. Understanding more deeply how the Landing Zone you applied here behaves exactly requires additional effort.

Which GCP Landing Zone Should I Pick?

The Terraform Example Foundation from the CFT should not be used anymore as Fabric FAST supersedes it and provides a way cleaner and usable approach. With the Example Foundation you have to execute >20 commands per stage manually (there are 6 stages in total). We also heard from one of the Google Consultants, that Fabric Fast is the direction they want to go to in future. As we tried to roll out the Example Foundation, we noticed that it is way more painful to use than Fabric FAST and it feels way more hacky.

The Google Cloud Setup Checklist is a nice and small solution that fits well for smaller companies or companies just wanting to get started quickly with their Cloud Journey in a reasonably secure environment. It also allows growing your foundation step-by-step by extending the generated Terraform modules to your needs.

But, if you have a really big cloud foundation in mind, the Terraform Modules provided by the Cloud Setup Checklist might not suffice to scale them to something large. It also doesn’t contain solutions for advanced problems many companies face. If you want to grow your Cloud Foundation Landing Zone, you should better consider starting with Fabric FAST right from the beginning as it applies a sophisticated IAM and PAM concept and a scalable structure to organize your Terraform modules with those stages. It also provides more features that make sense for many companies.

Starting with the Google Cloud Setup Checklist first, and adopting Fabric FAST later on is also a feasible option. Both use the same user groups and adopting the resource hierarchy, networking, and audit logging should also be possible as they don’t differ drastically.

Did this blog post help you decide which Landing Zone Solution you will apply to our GCP Org? Did you already gather your own insights to building a GCP Landing Zone and want to back up, add or discuss insights from this blog post, please do so and leave a comment! We look forward to hearing about your experience.