Landing Zones with Cloud Foundation Fabric / FAST

A landing zone is the opinionated baseline an org sits on top of — the resource hierarchy, the billing wiring, shared networking, IAM groups, centralized logging, and the org-policy guardrails that every new project inherits. Building it by hand from the raw primitives is months of work that most teams get partly wrong, and the parts they get wrong are the ones nobody notices until an audit or an incident.

Cloud Foundation Fabric is Google's open-source Terraform module library, and FAST — Fabric FAST — is its staged, end-to-end landing-zone blueprint. Adopting FAST greenfield gives the Hatch org a production hierarchy in days instead of months. The harder problem — wrapping FAST around an org that already exists — is a careful import-and-stage exercise, not a fresh apply, and getting that distinction wrong is how a stage tries to create what is already there.

What a Landing Zone Is

The landing zone is the org-level foundation, built once so every project lands into a governed environment. For Hatch that is the platform/apps/data folder structure, the billing-account wiring, the Shared VPC host project (hatch-net-host), the IAM groups like gcp-org-admins@hatch.io, the org policies that constrain what projects may do, and centralized logging. None of these are application infrastructure; they are the governed ground every application is then deployed onto.

Cloud Foundation Fabric

GoogleCloudPlatform/cloud-foundation-fabric is Google's maintained library of composable Terraform modules — a project factory, a Shared-VPC module, IAM helpers — plus reference end-to-end blueprints that wire them together. It is the successor in practice to the older Cloud Foundation Toolkit (CFT) modules, and it is where Google's own opinion about how a GCP org should be structured is actually encoded. You consume it; you do not reinvent it.

FAST — The Staged Bootstrap

Fabric FAST is a sequence of stages applied in order. Stage 0, org-setup, seeds the automation project, the Terraform state bucket, and the bootstrap identity, and also lays down the folder hierarchy and org policies. Then come networking (the Shared VPC baseline), security (KMS and central logging), and the project factory on top. The staging is not arbitrary: later stages depend on the IAM and the projects that earlier stages create, so the order is the dependency graph made explicit.

# Each stage consumes the outputs of the prior one — order is mandatory
0-org-setup/            # seed project, state bucket, identity, folders, org policies
2-networking/           # Shared VPC baseline (hatch-net-host)
2-security/             # KMS, central logging
2-project-factory/      # projects land here, governed

Greenfield Adoption

On a fresh org you run the FAST stages in order, feeding each stage the outputs of the prior one. The result is exactly the Hatch Layer B shape — the org, the folders, the host project, the groups, and hatch-tfstate — produced by reviewed Terraform instead of hand-clicking. The bootstrap stage is the one that creates the very state bucket the rest of the org will then use, which is why it runs first and why its own state needs the same protection every other stack relies on.

Brownfield Adoption of an Existing Org

Wrapping FAST around an org that already has projects and folders is the hard case. You import the existing folders, host project, and bindings into the FAST state stage by stage, run plan until each stage is a no-op, and only then let FAST manage forward. Done carelessly, an un-imported folder makes FAST try to create a folder that already exists, or an org-policy stage clobbers a live policy and locks people out. Brownfield is an import exercise wearing a landing-zone costume.

Config Connector as the KRM Alternative

For org management there is one real alternative. Config Connector — and Config Controller — expresses the same hierarchy and IAM as Kubernetes resources, reconciled continuously by an in-cluster controller that corrects drift on its own. Choose it when the org already lives in Kubernetes and wants drift corrected automatically. But Fabric/FAST is the Terraform-native answer and the form Google ships its reference landing zone in, so it is the default unless the org is genuinely Kubernetes-first.