The Cloud Foundation Toolkit

The Cloud Foundation Toolkit, or CFT, is a library of production-grade Terraform modules that Google itself writes, publishes, and maintains under the terraform-google-modules namespace on the Registry — project-factory, network, kubernetes-engine, cloud-storage, and dozens more. You consume them through the registry source from the previous topic, and they mean you rarely write a VPC or a project bootstrap from scratch.

That Google's own recommended answer for standing up GCP at scale is a set of Terraform modules is the loudest possible signal of where the platform points its customers. Google's native Deployment Manager is deprecated; its blueprints, its landing-zone guidance, and its reference architectures are CFT modules. When the cloud vendor ships its best practices as Terraform you can terraform apply, the question of which IaC tool to standardize on has already been answered for you.

What CFT Is

CFT is the terraform-google-modules GitHub organization and the matching Registry namespace: opinionated, tested, versioned Terraform modules that encode Google's recommended patterns for projects, networks, IAM, GKE, and storage. Instead of assembling those resources yourself and re-deriving the rules each cloud team learns the hard way, you call a reviewed module that already has them baked in. The modules are open source, carry their own test suites, and version independently of each other.

The Modules You Will Actually Use

Four modules cover most of the scaffolding around the Hatch pipeline. project-factory creates a project with its APIs enabled, billing linked, and a default service account wired up. network builds a VPC with subnets, secondary ranges, and routes. kubernetes-engine stands up a hardened GKE cluster. cloud-storage creates buckets with sane defaults. These are the undifferentiated plumbing — the project, the VPC, the storage scaffolding — while the ingest-pipeline module, the part that is Hatch, stays yours.

module "project" {
  source  = "terraform-google-modules/project-factory/google"
  version = "~> 17.0"
  name            = "hatch-pipeline-prod"
  org_id          = var.org_id
  billing_account = var.billing_account
  activate_apis   = ["run.googleapis.com", "pubsub.googleapis.com", "bigquery.googleapis.com"]
}

module "network" {
  source  = "terraform-google-modules/network/google"
  version = "~> 9.0"
  project_id   = module.project.project_id
  network_name = "hatch-vpc"
  # subnets, secondary ranges, routes — all in one reviewed module
}

module "ingest_pipeline" {       # the part that IS Hatch — stays your own module
  source     = "./modules/ingest-pipeline"
  project_id = module.project.project_id
  event_name = "clickstream"
}

Why Google Publishes It

A project-factory module bakes in the parts every team otherwise gets subtly wrong: the API-enablement ordering, the default-service-account handling, and the label conventions. Enabling an API and creating a resource that needs it in the same apply is a classic ordering bug; CFT has the dependency wired so it just works. Google ships the patterns as code so the ecosystem stops re-deriving them — and so that "how do I do X on GCP" has a concrete Terraform answer instead of a doc page you translate by hand.

Evaluating a Public Module Before Adopting

Adopting any public module is a supply-chain decision, and CFT does not exempt you from the diligence. Check the last release date and the commit cadence, the open-issue count, whether the module pins its own provider versions, and whether it ships an examples/ directory you can run. Above all, check the namespace: a module under terraform-google-modules is Google-maintained, while one from a random author may be abandoned and pin an old google provider that blocks your next upgrade.

Being Google-published makes a module trustworthy, not magic. CFT defaults are sane, not automatically least-privilege or right for your org. Run a plan and read what project-factory actually grants and what network actually opens before the first apply — the defaults are a good starting point, not a substitute for reading what lands in your project.

Submodules Within CFT

Many CFT modules ship submodules you reference by the double-slash path. The network module has subnets, routes, and firewall-rules as submodules, so you can compose just the piece you need — terraform-google-modules/network/google//modules/firewall-rules — rather than pulling in the whole VPC module for one rule set. Reaching for the submodule keeps you from inheriting inputs and defaults for resources you never wanted, and is the difference between using CFT precisely and dragging in a heavyweight dependency for a small need.