Google Cloud Landing Zone Architecture: Governance, Identity and Network Design

Google describes a landing zone, or cloud foundation, as a modular and scalable configuration that enables enterprise use of Google Cloud. That definition is deliberately broader than a network or resource hierarchy. The foundation includes identity, policy, security, connectivity, operations, billing and the automation used to change them.

The design should make safe delivery easier. If the platform provides strong controls but teams cannot obtain a project or deploy a service without extended manual coordination, they will either wait or find an unmanaged path. If it provides unlimited autonomy without common evidence and guardrails, the organization inherits security and financial risk.

A successful landing zone creates controlled autonomy and remains adaptable as workloads and regulations change.

Define the operating model before the hierarchy

The resource model should express responsibility. Platform engineering may own the organization, folder structure, shared connectivity, policy and central security services. Workload teams may own application projects, service deployments, reliability and incidents. Finance may govern billing access and allocation. Security may define controls while platform and workload teams implement them.

These responsibilities should be documented as service contracts. A team requesting a project needs to know the available project types, expected lead time, default controls, network options, support model and exception process. The platform team needs clear ownership information and a supported mechanism for changing the foundation.

The operating model determines whether an environment oriented, product oriented or subsidiary oriented hierarchy is appropriate. Google advises organizations not to copy the corporate org chart automatically. Reporting lines change frequently and may not represent durable policy or access boundaries.

Design the resource hierarchy for inheritance and accountability

The organization is the root. Folders group projects and provide scopes for policy and access. Projects contain most service resources and serve as important boundaries for APIs, quotas, billing and IAM.

Inheritance makes hierarchy design consequential. Organization policies apply through descendants subject to their evaluation rules. IAM allow policies at lower levels are generally additive, while deny policies can supersede allow. Aggregated log sinks and hierarchical firewall policies can also operate at organization or folder scope.

The hierarchy should remain understandable enough that an engineer can predict the policy and access a project receives. Shared infrastructure and bootstrap automation often deserve clear placement. Production and development may need different policy and network boundaries. Subsidiaries or regulated workloads may require separation when their legal or control requirements genuinely differ.

Projects should have a deliberate lifecycle. Use separate projects when ownership, environment, policy, quota, billing or network attachment requires isolation. Avoid a single large project that obscures accountability. Also avoid excessive fragmentation that creates thousands of administrative units with no meaningful difference.

Project vending should capture the owner, environment, billing account, data classification, support tier, required APIs and connectivity pattern. Automation can then place the project, attach labels, apply policy, configure logging and establish deployment identity before handover.

Engineer IAM as a set of explicit trust relationships

Human access should normally flow through Cloud Identity or Google Workspace groups. Predefined roles are preferable to broad basic roles. Custom roles are appropriate when a stable permission requirement cannot be met safely with predefined roles.

Hierarchy level access has a wide blast radius. A role granted at the organization can affect all descendants. Platform functions may require broad authority, but those grants should be limited, monitored and separated from ordinary workload administration.

Service accounts represent workloads and automation. They should have narrow purposes and should not be shared across unrelated systems. Workload Identity Federation can allow external pipelines and workloads to obtain short lived access without service account keys. For GKE, Workload Identity Federation provides a direct way to grant Kubernetes workloads access to specific Google Cloud APIs.

Deployment and runtime identities should be separate. A pipeline that creates resources may need permissions an application should never hold. Conversely, a runtime service may need data access the deployment process does not require.

Deny policies and principal access boundaries can strengthen control but also increase complexity. Their introduction should include testing, operational ownership and a recovery process.

Use Organization Policy as an enforceable design standard

Organization Policy constrains resource configuration across the hierarchy. Common uses include limiting locations, controlling external addresses, restricting service account keys and governing public access.

Controls should be introduced through a managed lifecycle. Assess the existing estate, test the policy, understand remediation, provide a compliant path and define exceptions. A rule without an exception owner often becomes permanent technical debt. A deny rule applied without testing can interrupt legitimate workloads at scale.

The enterprise foundations blueprint describes a layered security model that combines architecture controls, policy controls and detective controls. This is a useful distinction. Policy can prevent certain configurations. Architecture can reduce exposure through network and resource design. Detective services such as Security Command Center identify behavior that preventive controls cannot eliminate.

The blueprint is a starting point, not a substitute for requirements. It should be tailored to the organization's threat model, regulatory obligations and operating capacity.

Select network architecture according to control requirements

Google's landing zone guidance presents several common network models. A Shared VPC for each environment is recommended for many organizations because it provides central network management and separation between production and development. Other designs are valid when teams need more autonomy, centralized inspection appliances are required or service producer and consumer patterns fit better.

The decision should address centralized versus delegated routing and firewall control, hybrid connectivity, scale and inspection. Shared VPC simplifies consistent routing and address management but concentrates operational responsibility in the host project. A hub model with inspection adds control and cost. Project local networks provide autonomy but increase duplication.

Private Service Connect, Private Google Access, Cloud NAT, Cloud Interconnect, Cloud VPN and Cross Cloud Interconnect solve different connectivity requirements. The architecture should specify ingress, egress, DNS, IP management and failure behavior rather than listing products without a traffic model.

Test the paths a workload will use. Connectivity to dependencies, DNS resolution, audit logging and incident access should be verified with representative services. A network deployment that exists is not necessarily a network service that teams can operate.

Make security and observability operational

Centralized audit and security evidence can use aggregated log sinks at organization or folder scope. Retention, access and export should reflect investigation and regulatory requirements. Security Command Center, Cloud Asset Inventory and Organization Policy reporting can provide important evidence, but each finding needs ownership and response.

Application teams still need service observability. Central collection should not prevent them from diagnosing customer impact. Platform dashboards and application dashboards answer different questions and should have different owners.

Backup and recovery also belong in the foundation where common capability is useful. The platform may provide approved services and policy, while workload owners define recovery objectives and prove restoration. A successful backup job is not equivalent to a successful recovery test.

Integrate financial governance with project lifecycle

Billing accounts attach to projects, but billing is not directly represented by the folder hierarchy. Financial governance should therefore combine project placement, labels and Cloud Billing data.

Project vending should establish billing access, ownership metadata, budgets and export coverage. Shared network, security and observability projects need an allocation method. Inactive projects should have a review and retirement process. Because label and hierarchy changes are not applied retroactively to historical billing export, early ownership is materially better than later cleanup.

The Google Cloud cost optimization operating model describes the management process built on this foundation.

Operate the foundation through a controlled supply chain

Google's enterprise foundations blueprint includes deployable Terraform assets and a Git based automation model. The principle is more important than the exact repository. Foundation changes should be declarative, reviewed, tested and traceable.

The supply chain should generate plans, validate policy, separate environments and detect drift. Organization, IAM and network changes require particularly careful review because they can affect many projects. Emergency procedures should exist, but emergency changes must be reconciled back into the authoritative configuration.

Treat the landing zone as a product. Maintain a roadmap, service ownership, support expectations and adoption measures. Repeated exceptions may reveal a missing platform capability. Long project provisioning times may indicate that automation or decision rights are incomplete.

Evaluate readiness with real evidence

CloudForge provides cloud migration consulting, DevOps platform engineering and FinOps consulting for Google Cloud environments. The Google Cloud migration framework explains how to validate the foundation through workload waves.

Sources

1. Google Cloud landing zone design
2. Resource hierarchy design for Google Cloud landing zones
3. Network design for Google Cloud landing zones
4. Google Cloud enterprise foundations blueprint