Run Google Cloud with clear structure and predictable spend

Why teams pick Google Cloud, and where it differs

Google Cloud is rarely chosen because it has the most services. It is chosen for specific strengths: BigQuery for analytics, a mature managed Kubernetes service in GKE, strong networking and a straightforward project model. Teams that came from Google Workspace, or whose product is built around data and machine learning, often find it the most natural fit.

The platform behaves differently from AWS and Azure in ways that surprise newcomers. The global VPC, project-scoped APIs, and an IAM model built around groups and inheritance reward planning. Our Google Cloud consulting work starts by making those structures deliberate, so that the platform is easy to reason about a year later.

Resource hierarchy and project structure

Everything on Google Cloud lives in a project, and projects sit under folders under an organisation. IAM policies and organisation policies inherit downward, so the hierarchy is where governance happens.

We keep it simple and map it to how you actually work:

Separate projects are a strong boundary for IAM, quotas, API enablement and billing, and they cost nothing. We use labels for cost attribution and enforce them in code. Organisation policies then set outer limits: restrict resource locations, block creation of service account keys, and prevent external IP addresses on virtual machines unless approved.

Everything defined as code

We build the hierarchy with Terraform, using a dedicated bootstrap project for state and a pipeline that plans on pull request. Blocking key creation is a good example of a guardrail that is a few lines of code:

resource "google_org_policy_policy" "no_sa_keys" {
  name   = "organizations/${var.org_id}/policies/iam.disableServiceAccountKeyCreation"
  parent = "organizations/${var.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

If your projects were created in the console, we import them gradually through our Terraform engineering service.

Identity and access

Credentials are the usual failure point, and on Google Cloud the culprit is almost always the downloaded service account key. Our baseline:

• IAM roles granted to groups, not individuals, at the narrowest scope that works, with primitive Owner and Editor roles avoided.
• Attached service accounts for compute, and Workload Identity for pods on GKE.
• Workload Identity Federation for CI/CD, so GitHub Actions or other pipelines exchange their own tokens instead of holding keys.
• Separate service accounts per workload, rather than one shared account with broad rights.
• Cloud KMS for customer-managed keys where policy or customers require them.

The custom role or predefined role you pick matters. A pipeline that only deploys to Cloud Run does not need project editor.

Networking with Shared VPC

A Google Cloud VPC is global, with regional subnets, which simplifies multi-region designs. For estates with more than one team, we use Shared VPC: a host project owns the network, and service projects attach workloads to it. Network engineers control subnets and firewall policy, while application teams control their own resources. It is a clean separation, but it requires deciding ownership early.

Other decisions we make up front: non-overlapping IP ranges, private Google access so workloads reach Google APIs without public addresses, Cloud NAT for controlled egress, and hierarchical firewall policies for rules that should apply everywhere. Private clusters on GKE keep nodes off the internet.

Cost control

Google Cloud bills are attributed through projects and labels, so structure does most of the work. We set budgets and alerts per project, export billing data to BigQuery for analysis, and review recommendations for idle or oversized resources. Committed use discounts come after right-sizing and apply only to steady baseline usage.

BigQuery deserves special attention. Query cost depends on the pricing model and on how much data each query scans, so partitioned and clustered tables, limited column selection and per-project controls matter. Cloud credits are also worth a mention: they hide bad habits until they run out, so we build good cost discipline while credits last.

Managed services we lean on

We prefer services Google operates: GKE for Kubernetes, Cloud Run for simple containerised services, Cloud SQL or AlloyDB for relational data, BigQuery for analytics, Pub/Sub for messaging and Cloud Storage for objects. For observability we combine Cloud Monitoring with open tooling; our Kubernetes monitoring guide explains the Prometheus and Grafana patterns we use.

Common failure modes

• Downloaded service account keys. They end up in repositories and laptops. Block them.
• Everything in one project. IAM, quotas and billing become impossible to separate.
• Unbounded BigQuery queries. A careless query can cost real money. Set limits.
• Default network left in place. Auto-created subnets and permissive firewall rules should be removed early.
• No central audit logging. Sinks must be created at organisation level before they are needed.

When Google Cloud is not the right choice

Choose AWS when you need the widest service catalogue, the largest hiring pool or specific services Google lacks. Choose Microsoft Azure when your organisation is built on Microsoft identity and licensing. Google Cloud also has fewer regions and fewer local specialists in some markets, which can affect support and hiring. If you are unsure, book a consultation and we will compare options against your actual workload, or see how we work.