GCP Landing Zone & Foundations

There are two versions of this problem and they cost about the same to fix. In the first, there is nothing: a Google Cloud organization with a billing account, one project someone created for a proof of concept, and a decision to move properly that nobody has structure for. In the second, there is too much: forty projects created over three years, no folder structure, IAM granted by whoever asked, and a network that grew by peering one VPC to another until the routing table became a genuine research problem.

Both end up in the same place. Nobody can answer where a new workload should go, what it should be allowed to reach, or who approves it. Every new project restarts an argument that was never resolved, and the arguments get resolved differently each time.

The expensive failure mode is starting workload migration before this exists. Machines land in whatever project was convenient, and eighteen months later the reorganization costs more than the original build would have.

What gets built

• +Organization hierarchy and folder structure that maps to how your business is actually run and how access is actually approved — usually by environment and business unit, sometimes by regulatory boundary, rarely by the org chart.
• +IAM and a least-privilege model. Group-based access rather than per-user bindings, custom roles where predefined ones are too broad, service accounts scoped to one workload each, and Workload Identity in place of downloaded keys.
• +Shared VPC design. Host and service project structure, subnet allocation with room to grow, firewall policy hierarchy, and private access to Google APIs so that traffic to managed services does not traverse the internet.
• +Hybrid connectivity. Cloud Interconnect or HA VPN, Cloud Router and BGP, on-premises routing, and DNS that resolves in both directions — the piece that most often derails these programmes.
• +Organization policy guardrails. Constraints that prevent the specific mistakes that matter to you: external IP restrictions, resource location constraints, service account key creation, and domain-restricted sharing.
• +Cloud KMS. Key rings and keys with rotation, separation between key administration and key use, and CMEK where your data classification requires it.
• +Logging and monitoring baseline. Organization-level log sinks to a dedicated project, audit log retention that survives a project deletion, and alerting on the events that indicate someone is doing something unusual.
• +A CI/CD pipeline that deploys the foundation itself, so the landing zone is changed by pull request rather than by console.

Why hybrid networking is inside the price

Because it is the piece that derails these programmes, and because pricing it separately gives the vendor a reason not to look at it closely until it is too late to matter.

The pattern is familiar. Connectivity is scoped as a line item on the assumption that Interconnect is a procurement task. Then the on-premises routing turns out to have overlapping RFC 1918 space with the proposed VPC ranges. Or DNS resolution works from cloud to on-premises but not back. Or the network team’s change window is monthly and the third attempt lands in week eleven. At that point the engagement is renegotiated, from a weak position, with a live dependency.

Including it means the design accounts for it from week one, and the price does not move when it turns out to be harder than the client assumed.

Delivered as modules, not as a configuration

The output is a set of reusable Terraform modules with a handover runbook, not a rendered configuration that only works once. The difference shows up the first time you add a business unit: with modules, that is a new invocation with different inputs. Without them, it is a manual repetition of the original build by someone reading a document.

The runbook covers what the modules do not: the approval path for a new project, what to do when a firewall rule needs an exception, how the Interconnect fails over and how to test that it does.

Where the boundary sits

Workload migration is a separate engagement. The landing zone is where machines land; moving them is its own programme with its own wave planning, and combining the two into a single fixed price hides risk in both.

Application refactoring is out of scope. If an application needs to change to run well on Google Cloud, that is application engineering.

Physical Interconnect procurement is yours. The design specifies what is needed, the configuration is delivered, and the cross-connect contract with the carrier or colocation facility is signed by you — vendor lead times sit outside anything a consultancy can commit to.

Deliverable. Reusable Terraform modules plus a handover runbook.