GCP Landing Zone Design Best Practices

A GCP landing zone is the governed foundation — organization, folders, projects, networking, identity and policy — established before workloads arrive rather than reconstructed around them afterwards.

This guide covers the hierarchy design, the networking model that actually scales, the org policy constraints worth applying first, and how to choose between the available deployment toolkits.

What Is a GCP Landing Zone?

A landing zone is not a product. It is a set of foundational decisions, implemented consistently, that every project created afterwards inherits.

What distinguishes it from a collection of projects:

• An organization resource tied to a verified domain, with a deliberate folder hierarchy beneath it
• Centralised identity through Cloud Identity or Google Workspace, with IAM granted to groups
• Centralised logging and billing export into projects nobody can write to
• Organization policy constraints applied at folder level rather than project by project
• A network foundation with allocated address space and a Shared VPC model
• Automated project provisioning, so project fifty is identical to project five

Signals you need one

When you do not need one

One team, one product, three projects. That needs organization-level logging, MFA enforced, a budget alert and Terraform. Building a full enterprise foundation for that adds friction without adding safety.

The threshold in practice: build when the cost of inconsistency exceeds the cost of the platform — usually somewhere between ten and twenty projects, sooner if regulated.

Resource Hierarchy: Organization, Folders, and Projects

Three levels, and inheritance flows down

Google Cloud's hierarchy is organization → folders → projects → resources. IAM bindings and organization policies inherit downward, which makes folder placement the primary governance decision.

The organization resource is created once, tied to a verified domain via Cloud Identity or Google Workspace. Everything else hangs beneath it.

Environment first, team second

This is the decision people get wrong most often, and the one that is most annoying to unwind.

The hierarchy that holds up:

Organization
├── bootstrap/          seed project, Terraform state, CI/CD identities
├── common/             logging, billing export, DNS, interconnect, SCC, KMS
├── prod/
│   ├── team-payments/  → projects
│   └── team-search/    → projects
├── nonprod/
│   ├── team-payments/
│   └── team-search/
├── dev/
└── sandbox/

Environment at the top level, team below it. The reason is simple: production and non-production need genuinely different policy, and teams reorganise. A hierarchy built team-first means every reorg is a folder migration, and every environment-specific policy has to be applied N times, once per team.

Group by the controls that apply, not by the reporting line.

Project design

A project in Google Cloud is the unit of billing, quota, IAM and API enablement. It is a much harder boundary than a Kubernetes namespace and a softer one than an AWS account.

Split when:

• The environment differs — production and non-production always separate projects
• Quota pressure exists — quotas are per project per region
• Compliance scope differs — keep regulated workloads isolated
• Cost ownership differs — projects are how billing attributes cleanly
• Blast radius tolerance differs

Do not split because a new team appeared. A team with three services in one environment can share a project with IAM scoped per resource, at least initially.

Rules worth treating as fixed

• Never grant IAM to individual users. Bind roles to Google Groups. The group is what your joiner-mover-leaver process already manages.
• Nothing runs in the bootstrap folder beyond the seed project and state. It is the only thing created by hand; everything after is code.
• Keep folder depth to three or four. Google supports up to ten levels, but policy evaluation across deep hierarchies becomes impossible to reason about during an incident.
• Labels at creation, not later. Cost centre, environment and owner applied by the provisioning process. Labels added retrospectively never reach full coverage.
• A sandbox folder with real fences. No Shared VPC attachment, hard budget cap, no production data, deleted on a schedule.

Project Vending

Once the hierarchy exists, creating projects by hand defeats the purpose. A project factory — Fabric FAST ships one — should produce a project that already has the right folder placement, IAM from groups, billing account linked, a Shared VPC attachment (or deliberately none), required APIs enabled, log sinks configured, budget alerts set and labels applied.

Track two numbers:

Networking: Shared VPC and VPC Service Controls

Shared VPC is the default model

Shared VPC lets one host project own the network — VPCs, subnets, routes, firewall rules — while service projects attach to it and run workloads using its subnets.

This produces exactly the separation you want. The platform team owns connectivity. Workload teams get subnets, never networks. No team can create an overlapping range because they cannot create a network at all.

The standard shape is one Shared VPC host project per environment, living in that environment's folder:

prod/       → host project: prod-shared-vpc
nonprod/    → host project: nonprod-shared-vpc
dev/        → host project: dev-shared-vpc

Separate host projects per environment mean a mistake in development cannot route to production, and each can carry different firewall policy.

For connecting multiple VPCs — across environments, regions or into on-premises — Network Connectivity Center provides hub-and-spoke transit without building a peering mesh by hand. VPC Network Peering remains fine for a handful of connections, but it is non-transitive and does not scale past a small number.

Address space, before the first subnet

This is the decision with the worst reversal cost in the entire design. Re-IPing a live VPC means downtime.

Allocate the whole range first, then subdivide by environment and region:

10.0.0.0/8              Organisation total
  10.0.0.0/12           Production
    10.0.0.0/16         us-central1
    10.1.0.0/16         europe-west1
  10.16.0.0/12          Non-production
  10.32.0.0/12          Development
  Reserved              GKE secondary ranges, VPN, acquisitions

Two points teams learn late:

• GKE consumes far more address space than expected. VPC-native clusters use secondary ranges for pods and services, and pod IPs are allocated per node. Size these ranges generously — expanding them on a live cluster is difficult.
• Leave gaps deliberately. A second region, a partner connection, an acquisition. Gaps cost nothing; filling them later costs a migration.

VPC Service Controls: the data exfiltration control

This is the piece with no clean equivalent on other clouds, and it is worth understanding properly.

VPC Service Controls creates a service perimeter around a set of projects. Google-managed APIs inside the perimeter — Cloud Storage, BigQuery, Cloud SQL and others — can only be reached from within it. Even a caller with valid credentials and correct IAM permissions is blocked if they are outside.

The threat it addresses: an insider or compromised credential copying a BigQuery dataset to a personal project. IAM alone does not prevent that, because the credentials are legitimate.

Getting it right in practice:

• Start in dry-run mode. Perimeters support dry-run, which logs what would have been blocked without blocking it. Run for weeks. You will find legitimate access paths nobody documented.
• Perimeter around data, not around everything. Wrapping every project produces constant friction and teaches people to request exceptions.
• Plan ingress and egress rules carefully. CI/CD pipelines, monitoring agents and support tooling all need explicit paths in.
• Use access levels to permit specific corporate networks or device postures.
• Expect it to break something. It is designed to break things — that is the point. Dry-run is how you find out which things before your users do.

Firewall and DNS

Hierarchical firewall policies apply at the organization or folder level and evaluate before project-level rules. Deny-by-default egress belongs here, not repeated in every project.

Cloud DNS private zones belong in the host project, shared to attached service projects. Per-project DNS configuration produces resolution failures that are genuinely hard to diagnose.

Organization Policy Constraints as Governance Guardrails

Organization policies are the preventive controls that make a landing zone more than a diagram. They are evaluated at resource creation and inherit down the hierarchy.

The constraints worth applying on day one

Of these, iam.allowedPolicyMemberDomains and iam.disableServiceAccountKeyCreation deliver the most security value per unit of friction. Service account keys are long-lived credentials that end up in repositories; Workload Identity Federation removes the need for them entirely.

Custom constraints

Beyond the predefined list, custom organization policy constraints let you express rules specific to your estate — a required label, a prohibited machine type, a naming convention. They use CEL expressions against resource fields and are evaluated at creation.

Use them sparingly. Each one is something the platform team maintains, and an over-constrained environment generates exception requests rather than compliance.

Roll out with dry-run, always

The pattern that avoids self-inflicted outages:

1. Apply the constraint in dry-run mode at organization or folder level.
2. Watch the logs for what it would have blocked. Run for at least a sprint.
3. Remediate the legitimate non-compliant resources.
4. Switch to enforcement.
5. Handle genuine exceptions with a narrower policy at a lower folder, not by removing the parent policy.

Going straight to enforcement on a live organization breaks deployments in ways nobody can attribute, because the error surfaces as a generic permission failure at creation time.

Apply at the right level

Policies inherit, so assign at the highest folder where the rule genuinely applies. A resourceLocations restriction that applies everywhere belongs at the organization. One that only applies to regulated workloads belongs on that folder.

Note that some constraints merge with parent policies while others replace them. Test the interaction in a non-production folder before assuming the behaviour.

Deployment Options: Fabric FAST and Cloud Foundation Toolkit

The options

Fabric FAST, in practice

Cloud Foundation Fabric contains three things: a large library of composable Terraform modules, end-to-end blueprints, and FAST — a production-ready landing zone implementation organised into stages.

The stages run in sequence, with dependencies passed automatically between them rather than by copying IDs by hand:

• Bootstrap — organization setup, IAM, org policies, Terraform state
• Resource hierarchy — folders and their policy
• Security — KMS, Security Command Center
• Networking — VPCs, subnets, firewall, DNS
• Project factory — workload project provisioning from configuration files
• VPC Service Controls — service perimeters
• Data platform — optional, for analytics estates

Two characteristics make it work at scale. It is factory-centric — project and tenant factories let teams request resources by submitting a configuration file rather than writing Terraform. And it is modular — you can adopt individual stages rather than all of them.

The honest trade-off: FAST is opinionated. If your requirements differ substantially from its design, you will spend time fighting it. For most enterprises the opinions are reasonable ones, arrived at by people who have done this repeatedly.

Choosing

Use Fabric FAST for a greenfield enterprise build, or where you want a battle-tested default rather than a design exercise. It is the current recommended path for most organisations.

Use CFT modules directly if you have a mature platform team, specific requirements FAST cannot express, and the capacity to own the composition permanently.

Use the console only for proofs of concept. Anything that reaches production should be in version control.

One note on what you will read elsewhere: the older Terraform Example Foundation is still findable and still referenced in tutorials, but FAST supersedes it for most new builds and is considerably less manual to operate. Check what a guide is based on before following it.

GCP Landing Zone Security and Governance Best Practices

Identity

• Cloud Identity or Google Workspace as the identity source, federated to your existing IdP where one exists
• Groups for all IAM, never individual users. Establish the admin groups — organization admins, network admins, security admins, billing admins — before the first project
• Predefined roles over primitive roles. Owner, Editor and Viewer at organization or folder scope are far too broad
• Workload Identity Federation instead of service account keys, for both CI/CD and cross-cloud workloads
• Short-lived credentials and service account impersonation rather than long-lived keys

Logging and monitoring

Aggregated log sinks at organization level, exporting to a dedicated project in the common folder that nobody else can write to. Two destinations serve different purposes: Cloud Storage for long-term retention at low cost, BigQuery for querying during an investigation.

Set retention to match your compliance obligation and enable bucket lock where immutability is required. Getting this right from the start matters — you cannot retroactively collect logs you did not capture, a point that applies equally to any monitoring and observability design.

Security Command Center provides the posture view — misconfigurations, vulnerabilities, threat detection. Enable it at organization level; project-by-project enablement leaves gaps exactly where you would not notice them.

Data protection

• Customer-managed encryption keys in Cloud KMS where compliance requires control over key material
• Separate key projects in the common folder, with key administration split from data access
• Assured Workloads where regulatory regimes demand data residency and personnel controls
• VPC Service Controls around the projects holding sensitive data, as above

Cost governance

Budgets per project with alerts at 50%, 80% and 100%. Billing export to BigQuery from day one, because historical billing data cannot be backfilled. Labels enforced at creation so attribution works without a reconciliation exercise — the root of most cloud cost management difficulties.

Committed use discounts come later. Optimise usage first, then commit.

How to Plan a Scalable GCP Landing Zone

Sequence the decisions

Some choices constrain everything after them. In order:

1. Identity and organization. Cloud Identity or Workspace, domain verification, admin groups.
2. Folder hierarchy. Environment-first, three or four levels, agreed across business units.
3. Address space allocation. Before any VPC exists. This is the irreversible one.
4. Shared VPC model. One host project per environment; which subnets go where.
5. Organization policy baseline. Applied in dry-run first.
6. Logging and billing export. Before workloads generate data you wish you had captured.
7. Project factory. Automated before the requests start arriving.

A realistic build order

• Week 1–2: Organization, Cloud Identity, admin groups, bootstrap project and Terraform state
• Week 2–4: Folder hierarchy, org policies in dry-run, logging and billing export
• Week 3–6: Shared VPC host projects, address allocation, firewall policies, DNS
• Week 5–8: Security tooling — SCC, KMS, VPC-SC perimeters in dry-run
• Week 6–10: Project factory and CI/CD, then first workload projects
• Ongoing: Move org policies and perimeters from dry-run to enforcement as remediation completes

The deployment itself is fast — FAST will stand up a hierarchy in a day. The time goes into the decisions. Agreeing the folder structure across three business units takes longer than deploying it.

Common mistakes

• Deploying before agreeing the hierarchy. Easy to run, and someone has to live with the result.
• Allocating IP space after projects exist. Overlap surfaces when two VPCs first need to talk, months later.
• Team-first folder structure. Every reorg becomes a migration, and every environment policy is applied N times.
• Enforcing org policies without dry-run. Breaks deployments in ways that cannot be traced to a cause.
• IAM granted to users. Unmanageable within a year of the first few departures.
• Treating it as a project. Without an owning team and a change process, it drifts within two quarters.

Bringing existing projects in

Moving a project between folders is straightforward — policy re-evaluates and applies. The difficulty is what is already inside: overlapping address space, IAM granted directly to users, resources in unapproved regions, service account keys in circulation.

The workable approach: build the hierarchy, place new projects into it, then migrate existing projects one at a time starting with the least critical. A transitional folder with relaxed policy gives you somewhere to park projects while you remediate them.

If this runs alongside a migration programme, sequence matters: landing zone first, then migration waves. Doing both at once is how workloads get migrated twice.

If you are building a foundation, inherited one that has drifted, or need existing projects brought under governance without disrupting production, our cloud migration services and Terraform consulting cover exactly this GCP landing zone work — hierarchy design, Shared VPC and address planning, org policy rollout and project vending. Related reading: our AWS landing zone guide and Azure landing zone architecture guide cover the same problem on the other two clouds.

Talk to our team → We will start with your project inventory and your address space, because that is where the expensive surprises live.