The landscape of Google Cloud Platform adoption shifted dramatically in May 2024. Organisations creating new GCP accounts now receive automatic security baseline enforcement: a paradigm change that elevated landing zones from “nice to have” to foundational infrastructure. For cloud architects tasked with building scalable, secure cloud environments, understanding landing zone implementation has become essential.
This guide provides a comprehensive roadmap for establishing GCP landing zones across organisations of all sizes, from agile startups to complex enterprises managing thousands of projects.
Understanding the Modern GCP Landing Zone
A landing zone represents far more than initial cloud configuration. It establishes the foundational architecture enabling secure, compliant, and operationally efficient cloud adoption. Think of it as the constitutional framework for cloud infrastructure: setting governance boundaries, security baselines, and operational patterns before deploying the first production workload.
The term “landing zone” and “cloud foundation” are used interchangeably within GCP contexts. Both describe organisational structure and foundational configurations, distinct from geographic availability zones or regional resources.
The Business Value Proposition
Modern landing zones deliver four critical outcomes that directly impact organisational success:
Security foundation implements defence-in-depth architecture from inception. Organisations implementing comprehensive landing zones before workload migration consistently report 25% lower security and compliance costs compared to retrofitting governance later.
Centralised governance ensures policy consistency across potentially thousands of resources. Automated policy enforcement prevents configuration drift and reduces manual oversight requirements.
Operational efficiency stems from standardisation and automation. Infrastructure-as-code patterns enable repeatable deployments, reducing provisioning time from weeks to days.
Cost control emerges through proper resource hierarchy and attribution. Granular labelling and billing structures provide visibility into spending patterns, enabling informed optimisation decisions.
Architectural Foundations: The Five Pillars
1. Resource Hierarchy Design
The resource hierarchy forms the backbone of GCP organisation. The structure flows from Organisation to Folders to Projects to Resources, with policies inheriting additively down the hierarchy.
Flat structures (projects sitting directly under organisations without intermediate folders) create scaling nightmares. Resource sprawl becomes unmanageable, access controls tangle into incomprehensible webs, and policy application becomes inconsistent. The folder layer provides crucial organisational capabilities.
Two primary folder patterns dominate production deployments:
Environment-based structures organise by deployment stages: Production, Staging, Development, and Sandpit. This pattern aligns naturally with security policy requirements, as production environments demand stricter controls than development sandboxes.
Business unit structures mirror corporate organisation: Engineering, Marketing, Finance, Operations. This approach supports departmental autonomy and enables precise cost allocation for chargeback models.
Hybrid models combining both dimensions offer maximum flexibility but require disciplined planning. A typical hybrid structure might implement Business Units at the first folder level, with Environment subfolders beneath each unit.
Critical design principle: limit folder depth to 3-4 levels maximum. Deeper hierarchies become cognitively overwhelming and operationally unmanageable.
2. Identity and Access Management
IAM integration bridges GCP with organisational identity systems. Two primary patterns emerge:
Google as primary IdP simplifies management for organisations without existing identity infrastructure or those building greenfield operations. Cloud Identity provides full-featured identity management without additional licensing costs.
Federation with external IdP leverages existing identity systems (Active Directory, Okta, Azure AD) maintaining single source of truth for user identities. This pattern suits enterprises with established identity governance.
Group-based access management proves essential at scale. Individual user assignments create maintenance nightmares as team composition changes. Establish groups like gcp-network-admins, gcp-developers-prod, and gcp-security-admins before assigning permissions.
Workload Identity Federation eliminates long-lived service account keys: a frequent security vulnerability. By enabling workloads to authenticate using short-lived tokens, organisations dramatically reduce credential exposure risk.
3. Network Architecture Patterns
Network design profoundly impacts security posture, operational complexity, and long-term flexibility. Google recommends four primary patterns, each optimised for specific requirements:
Shared VPC per environment (recommended for most organisations) deploys separate networks for development, staging, and production. Central network management occurs in host projects, whilst service projects attach for resource deployment. This pattern provides complete environment isolation with simplified hybrid connectivity.
Hub-and-spoke with centralised appliances suits organisations requiring Layer 7 inspection between workloads. The central hub hosts network security appliances (next-generation firewalls) with spoke VPCs connecting via VPC Peering. Critical limitation: VPC Peering connections cap at approximately 25 spokes.
Hub-and-spoke without appliances enables workload isolation without centralised inspection. Teams manage spoke networks independently, suitable for autonomous teams requiring network control. The non-transitive nature of VPC Peering prevents inter-spoke communication without explicit configuration.
Private Service Connect implements a consumer-producer model where workloads communicate exclusively through defined endpoints. Complete network independence between workloads provides maximum isolation but requires TCP/UDP protocols.
4. Security Controls and Guardrails
Organisation policies translate security requirements into programmatic constraints enforced across the hierarchy. Essential policies include:
- Disabling service account key creation prevents the most common credential vulnerability
- Restricting external IP creation enforces private-first networking
- Requiring OS Login standardises SSH access patterns
- Limiting IAM member domains prevents accidental external access grants
VPC Service Controls create security perimeters preventing data exfiltration even by users with valid credentials. This defence-in-depth approach protects sensitive data through network-level controls independent of IAM permissions.
Security Command Center provides centralised security posture management with continuous asset discovery, vulnerability detection, and threat monitoring. Organisations implementing SCC report significantly faster security incident response times.
5. Logging, Monitoring, and Observability
Centralised audit logging captures all administrative actions and data access organisation-wide. Three log types provide comprehensive visibility:
Admin Activity logs (enabled by default) capture all administrative actions: resource creation, deletion, and configuration changes.
Data Access logs (requiring explicit enablement) record access to data stored in resources like Cloud Storage buckets and BigQuery datasets. These logs prove essential for compliance frameworks requiring data access audit trails.
System Event logs capture service-initiated actions, providing visibility into platform operations.
Organisation-level log sinks route audit data to long-term storage: Cloud Storage for cost-effective archival, BigQuery for SQL-based analysis, or Pub/Sub for real-time processing and SIEM integration.
The Five-Phase Implementation Roadmap
Phase 1: Foundation and Organisation Setup (Week 1)
Begin by establishing the organisation resource. Create a Cloud Identity or Google Workspace account, verify domain ownership via DNS TXT record, and confirm organisation auto-creation.
Design folder structure before creation. Document the rationale for structural decisions: future stakeholders will thank you. Implement consistent naming conventions: use prefixes (org-, folder-, proj-), include environment indicators (-prod, -stage, -dev), and follow formats like proj-app-team-prod-us-central1.
Create essential IAM groups in Cloud Identity before assigning any permissions. Group-based management scales infinitely better than individual assignments.
Establish core foundational projects: network host project for Shared VPC management, security project for security tooling, logging aggregation project for centralised log sinks, and initial service projects for application teams.
Apply resource labels immediately. Labels enable cost attribution from day one: retrofitting labels to thousands of existing resources proves tedious and error-prone.
Phase 2: Network Architecture Deployment (Week 1-2)
Enable Shared VPC on the network host project and create custom mode VPC networks. Delete default VPCs across all projects: never use default networks in production environments.
Create subnets with secondary ranges for GKE pods and services, enable Private Google Access for API connectivity without external IPs, enable VPC Flow Logs for network visibility, and configure appropriately sized IP ranges anticipating growth.
Attach service projects to the Shared VPC host and grant Network User role at subnet level. This delegation enables teams to deploy resources using shared network infrastructure whilst maintaining central network control.
Configure Cloud NAT for outbound internet access without external IPs. This security best practice limits public IP exposure whilst maintaining necessary internet connectivity.
Implement firewall rules with defence-in-depth: allow internal traffic between subnets, allow SSH from Identity-Aware Proxy, allow health check traffic from Google load balancers, and restrict egress to necessary destinations only.
Establish hybrid connectivity if required. Cloud VPN provides encrypted tunnels for up to 3 Gbps per tunnel, whilst Cloud Interconnect delivers dedicated connections from 10 Gbps to 200 Gbps.
Phase 3: Security Controls and Guardrails (Week 2-3)
Apply organisation policies at appropriate hierarchy levels. Organisation level for universal constraints, folder level for environment-specific policies, and project level only for specific exceptions requiring explicit justification.
Create VPC Service Controls perimeters around sensitive resources. Production perimeters typically include restricted services like Storage, BigQuery, Cloud SQL, and Pub/Sub.
Enable Security Command Center at organisation level. Activate Container Threat Detection and Web Security Scanner, configure automated notifications for high-severity findings, and integrate with existing SIEM systems.
Enable Binary Authorization for GKE to enforce deployment policies requiring attested container images. This prevents deployment of unapproved or vulnerable containers.
Phase 4: Logging, Monitoring, and Observability (Week 3-4)
Enable Cloud Audit Logs at organisation level for all log types. Create organisation-level log sinks routing audit logs to Cloud Storage buckets for cost-effective archival, BigQuery datasets for SQL analysis, and Pub/Sub topics for real-time processing.
Configure log-based metrics for security monitoring: failed authentication attempts, IAM policy modifications, organisation policy violations, and unusual API call patterns.
Deploy Cloud Monitoring with centralised dashboards showing resource health, performance metrics, cost trends, and security posture. Create alert policies for critical conditions with appropriate notification channels.
Phase 5: Cost Management and Billing (Week 4+)
Structure billing accounts to support cost allocation models. Single billing account with project-level tracking suits most organisations, whilst multiple billing accounts enable departmental autonomy.
Create comprehensive budget alerts at billing account, folder, or project scope. Configure multiple threshold rules with incremental escalation.
Implement consistent labelling strategy across all resources using three mandatory labels: app_name, team, and env. Additional optional labels include cost_center for chargeback and compliance_scope for regulatory requirements.
Enable BigQuery billing export immediately: historical data cannot be recovered retroactively. Daily billing export provides granular cost visibility enabling detailed analysis.
Infrastructure-as-Code: The Modern Standard
All production landing zones require Infrastructure as Code for repeatability, version control, and change management. Manual console configuration creates inconsistency and lacks audit trails.
Cloud Foundation Fabric FAST: The Current Standard
Cloud Foundation Fabric with Foundation Architecture Setup and Templates (FAST) represents Google’s recommended approach as of 2024-2025. Developed by Google Cloud Professional Services, FAST provides battle-tested patterns for organisations from startups to Fortune 500 enterprises.
FAST implements four core stages:
Stage 0-bootstrap establishes automation projects, billing structure, logging aggregation, service accounts for Terraform, and Workload Identity Federation for secure authentication.
Stage 1-resman creates resource hierarchy with folders, applies organisation policies, and establishes shared resource structure.
Stage 2-networking deploys chosen network topology with DNS, NAT, and hybrid connectivity.
Stage 2-security configures Security Command Center, KMS for encryption key management, Secret Manager, and VPC Service Controls.
The factory-centric design enables self-service with guardrails: teams request resources via YAML files triggering automated provisioning within security boundaries.
Implementation timeline: 1-2 days for basic bootstrap, 1-2 weeks for complete landing zone with networking and security, with ongoing iteration as requirements evolve.
Alternative Approaches
Cloud Foundation Toolkit individual modules provide standalone components for specific needs. These Terraform modules published on Terraform Registry offer flexibility for incremental adoption.
Cloud Setup Checklist provides wizard-based landing zone creation through the GCP Console, ideal for small organisations or rapid prototyping. The wizard generates Terraform code providing a starting point for future IaC adoption.
Pulumi enables infrastructure definition using general-purpose programming languages rather than HCL. Strong typing prevents configuration errors, though no official Google landing zone templates exist.
Avoiding Common Pitfalls
Understanding failure patterns prevents costly mistakes and rework.
The Seven Critical Anti-Patterns
Not utilising folders creates flat project structures that don’t scale. Implement 3-4 level folder hierarchy before creating projects.
Single project for all workloads makes cost tracking impossible and increases security blast radius. One project per workload enables clear ownership and security isolation.
Underutilising tags and labels prevents cost allocation and eliminates granular insights. Define three mandatory labels from day one and enforce through policies.
Shared projects between teams eliminate privacy and complicate cost allocation. Separate projects per team with clear ownership boundaries.
Running workloads in management projects prevents proper policy application. Reserve management projects exclusively for platform services.
Lack of automation in security policies proves error-prone and inconsistent at scale. Implement policy-as-code using organisation policies.
Overlooking organisational-level policies creates regulatory risk and security exposure. Establish comprehensive policies before deploying production workloads.
Technical Pitfalls with Severe Consequences
Using default VPC for production workloads creates migration challenges. Delete default VPCs immediately, forcing intentional network design.
Over-permissioning IAM roles violates least privilege. Use predefined and custom roles with minimal permissions, implement group-based access exclusively, and audit permissions quarterly.
Not planning for multi-tenancy early makes retrofitting resource isolation extremely difficult. Separate customers or business units require distinct folder hierarchies.
Inadequate logging and monitoring includes not enabling Cloud Audit Logs from start. Enable data access logs and implement centralised log export immediately.
Poor service account key management creates persistent credential vulnerabilities. Restrict key creation via organisation policies and use Workload Identity Federation wherever possible.
Migration from Existing Environments
Most organisations implement landing zones in brownfield scenarios with existing resources requiring careful migration.
Understanding Constraints
Critical limitation: most GCP resources cannot move between projects. Compute Engine instances, Cloud SQL databases, and Cloud Storage buckets tie to project infrastructure. Moving workloads requires recreation via snapshot, export/import, or backup/restore patterns.
Projects attached to Shared VPC cannot migrate between organisations until detaching from the host project, breaking network connectivity temporarily.
IAM permissions don’t transfer during project migration. Only policies directly attached to projects move: inherited permissions from parent folders and organisations are lost.
Three Migration Strategies
Duplicate and migrate (safest for production) creates new landing zone structure in parallel, deploys new projects in proper hierarchy, migrates data and applications, tests thoroughly, and cuts over traffic when validated. Minimal risk but higher temporary cost.
In-place project migration moves projects to proper folders within organisation and adjusts IAM policies. Faster and lower cost but limited rollback options.
Hybrid approach migrates low-risk projects in-place whilst recreating critical workloads. This pragmatic strategy balances risk and cost.
Sizing Recommendations by Organisation Type
Startup (1-50 employees)
Simplified 2-level hierarchy, essential security controls only, single environment or dev/prod split, simple Shared VPC design, and manual user management. Implementation in hours using Cloud Setup Checklist.
Mid-size Organisation (50-500 employees)
3-level folder hierarchy, VPC Service Controls for sensitive data, centralised log aggregation, Security Command Center Standard tier, and federation with corporate identity provider. Implementation over 1-2 weeks with 3-10 people.
Enterprise (500+ employees)
4+ level folder hierarchy, hub-and-spoke networking possibly with next-generation firewalls, dedicated Interconnect, customer-managed encryption keys, Security Command Center Premium, and full CI/CD pipelines. Dedicated platform team deploying over 4-8 weeks.
Looking Forward: 2024-2025 Evolution
The landing zone landscape continues evolving. Security-by-default enforcement represents fundamental shift in Google’s approach. Cloud Foundation Fabric FAST emerges as the clear implementation choice with active community development.
AI and machine learning infrastructure requirements influence landing zone design. Organisations planning AI initiatives should provision quota for TPU v5p or Nvidia Blackwell platforms in dedicated ML projects.
Cloud WAN announced April 2025 makes Google’s global private network available to all customers: revolutionary networking simplifying global deployments significantly.
Platform engineering drives landing zone evolution toward internal developer platforms. 75% of large enterprises are building self-service platforms by 2025, enabled through project and tenant factories.
Practical Next Steps
The investment in proper landing zone architecture (typically 4-12 weeks initial deployment with ongoing evolution) pays dividends throughout an organisation’s cloud journey. Start with clear requirements gathering, select appropriate implementation approach based on organisational size and maturity, begin with bootstrap stage establishing automation foundation, and enable self-service through project factories as the organisation matures.
Landing zones have evolved from optional to essential. The paradigm shift to security-by-default reflects this reality, but proper implementation extends far beyond basic security: encompassing governance, cost management, operational efficiency, and platform engineering capabilities supporting thousands of developers and millions of workloads.
Useful Resources for Deep Diving
- Google Cloud Landing Zone Design Guide – Official Google documentation covering landing zone concepts and decision frameworks
- Cloud Foundation Fabric FAST GitHub – Open-source repository with complete FAST implementation and 100+ Terraform modules
- GCP Security Best Practices – Comprehensive security guidance for landing zone implementation
- Shared VPC Documentation – Technical details on implementing Shared VPC architecture
- Organization Policy Constraints – Complete reference for available organisation policies and their enforcement
- Cloud Foundation Toolkit Modules – Terraform Registry listing all CFT modules for modular implementation
- VPC Service Controls Overview – Guide to implementing data exfiltration prevention
- Enterprise Foundations Blueprint – Reference architecture for enterprise-grade security foundations
- Project Migration Guide – Official guidance for migrating projects between organisations
- Resource Hierarchy Best Practices – Detailed explanation of GCP’s resource hierarchy model
