VAF·SA — Google Cloud Reference

← Cloud Reference Layer

VAF·SA — Cloud Reference · Google Cloud Platform

VENDOR REFERENCE
VAFSA-CRL-GCP · v1.0

GOOGLE
CLOUD

Architecture Framework · Cloud Adoption Framework · Landing Zone · Org Hierarchy · Security Command Center

Google Cloud Architecture Framework Cloud Adoption Landing Zone

Overview

Google Cloud Architecture Guidance

How Google structures its architecture and adoption guidance for enterprise customers.

Google Cloud's architecture and adoption guidance centres on two frameworks. The Google Cloud Architecture Framework addresses workload design quality across six pillars. The Google Cloud Adoption Framework addresses the readiness and maturity of an organisation's cloud adoption journey across four themes. The Landing Zone design (also referred to as Cloud Foundation) establishes the resource hierarchy, governance baseline, and network architecture for a governed Google Cloud environment.

Google Cloud's resource hierarchy — Organisation → Folders → Projects — is the foundation of its governance model. Identity and access management (IAM) policies, Org Policies, and billing accounts are applied at different points in this hierarchy. Understanding the intended hierarchy before designing workload placement is a prerequisite for sound architecture.

Google Cloud engagements frequently surface unclear ownership of the Organisation node and the Billing account. Module 01 (Orientation) establishes who controls these resources and what governance decisions have already been made — before any workload placement or landing-zone design begins.

Google Cloud Architecture Framework

Six Pillars

Workload design quality assessment across six dimensions.

PILLAR 01

System Design

Architecture decisions that underpin workload quality — application design, data management, compute and storage selection, reliability patterns.

PILLAR 02

Operational Excellence

Monitoring, alerting, incident management, SRE practices, deployment automation, and change management.

PILLAR 03

Security, Privacy, Compliance

Identity and access, data protection, network security, threat detection, compliance controls, and supply chain security.

PILLAR 04

Reliability

Designing for availability and resilience — failure planning, testing, recovery, and SLA management.

PILLAR 05

Cost Optimisation

Understanding and reducing expenditure — rightsizing, committed use discounts, billing visibility, and financial accountability.

PILLAR 06

Performance Optimisation

Matching resources to workload needs — latency, throughput, caching, load balancing, and capacity planning.

Google Cloud Adoption Framework

Four Themes · Three Phases

Assessing and developing cloud adoption capability across an organisation.

The Google Cloud Adoption Framework assesses cloud maturity across four themes — Learn, Lead, Scale, and Secure — at three phases of adoption: Tactical, Strategic, and Transformational. Each theme–phase combination identifies a set of capabilities the organisation should develop or demonstrate.

Learn

Developing cloud skills and knowledge across the organisation — from technical practitioners to executive decision makers. Training programmes, certification, and learning paths.

Lead

Executive sponsorship, cloud strategy definition, operating model change, and governance structure for cloud adoption. Includes establishing a Cloud Centre of Excellence (CCoE) or equivalent.

Scale

Expanding cloud usage across workloads and business units — automation, self-service provisioning, workload onboarding processes, and cost management at scale.

Secure

Security posture across the cloud environment — identity governance, data protection, threat detection, compliance monitoring, and incident response capability.

Landing Zone / Cloud Foundation

Enterprise Foundation

Resource hierarchy, governance baselines, and network design for a governed Google Cloud environment.

Organisation, folders, projects

The resource hierarchy determines policy inheritance and billing scope. Folders group projects by business unit, environment, or workload type. Projects are the boundary for resource isolation, IAM, and cost allocation. Hierarchy design is a foundational architecture decision.

IAM baseline

Google Cloud IAM controls access at Organisation, Folder, and Project level. Principle of least privilege. Service account governance — avoiding over-privileged service accounts is a common security gap. Workload Identity Federation for external identity integration.

Network baseline

Shared VPC model for enterprise environments — a host project provides the network, service projects consume it. Cloud Interconnect or VPN for on-premises connectivity. Private Google Access for API access without public internet exposure. DNS design across the hierarchy.

Security baseline

VPC Service Controls to define security perimeters around sensitive data. Organisation Policy Service for preventive controls at Organisation or Folder level. Access Transparency for audit of Google staff access. Binary Authorization for container workload integrity.

Logging and monitoring

Cloud Audit Logs aggregated to a central logging project. Log sinks for long-term retention and SIEM integration. Cloud Monitoring for workload observability. Security Command Center (Premium or Enterprise) for threat detection and posture management across the organisation.

Workload assessment notes

Workload placement decisions in Google Cloud must account for data residency requirements, regulatory constraints on data location, and the impact of the Shared VPC model on connectivity. These are architecture decisions, not defaults — each requires an ADR.

VAF·SA Usage Notes

Applying VAF·SA in Google Cloud Engagements

Where the practitioner method adds value in a Google Cloud environment.

VAF·SA Practitioner Notes — Google Cloud

The Organisation node is frequently contested. In multi-account organisations, the question of who controls the Organisation node — and therefore who can assign Org Policies and modify the resource hierarchy — is often unresolved. Module 01 (Orientation) establishes this before any design work begins.
Shared VPC ownership disputes. The division of responsibility between the host project network team and the service project application team is a recurring source of delivery friction. Module 02 (Intelligence) maps real ownership — not the RACI on the project plan.
Org Policy as a governance instrument. Module 04 (Artefacts) records Org Policy decisions as ADRs — which policies are enforced, at which level, with what exceptions, and what the process is for requesting an exception. The absence of this record is a common governance gap.
Adoption framework as a diagnostic. The Google Cloud Adoption Framework four-theme assessment is a useful intelligence tool in Module 02 — applying it to the client's environment surfaces whether the adoption is Tactical, Strategic, or Transformational, and where the capability gaps are.
Security Command Center findings as evidence. Where Security Command Center is deployed, its findings provide objective evidence of the current security posture for Module 02 (Intelligence) and the Heat Map artefact in Module 04 (Artefacts).

Official References

Google Cloud Documentation

Official vendor sources — not affiliated with Google or Alphabet.

Architecture

Google Cloud Architecture Framework

cloud.google.com/architecture/framework

Adoption

Google Cloud Adoption Framework

cloud.google.com/adoption-framework

Landing Zone

Google Cloud Landing Zone design — enterprise organisations

cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations

Security

Security Command Center overview

cloud.google.com/security-command-center/docs/

Hierarchy

Google Cloud resource hierarchy

cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

← Azure Reference OCI Reference →