Foundations: projects, regions, zones, and billing

• Resource — anything you create in GCP: a VM, a bucket, a Cloud Run service, a Gemini endpoint.
• IAM (Identity and Access Management) — the system that decides who (principal) can do what (role) on which resource.
• Principal — a user, group, or service account that IAM grants roles to.
• Service account — a non-human identity used by applications and services.
• Organization / Folder — the two grouping levels above projects.
• Org policy — a guardrail constraint applied down the hierarchy (for example “no external IPs”, “only these regions”).
• Billing account — the payment entity that projects are linked to.
• SKU — one billable line item (for example “N2 instance core running in Frankfurt”).
• Quota — a limit on how much of a resource a project may use (rate or allocation).
• SUD / CUD — sustained-use discount (automatic) / committed-use discount (you commit for 1 or 3 years).
• Spot VM — deeply discounted VM that Google can reclaim at any time.
• Egress — data leaving a region or Google’s network; usually billed.
• ADC (Application Default Credentials) — the standard way client libraries find credentials.

Everything in GCP lives in a tree. Policies set at a node are inherited by everything below it.

Organization  (example.com — tied to Cloud Identity / Workspace domain)
├── Folder: prod
│   ├── Project: payments-prod        <- resources live here
│   └── Project: ml-platform-prod
├── Folder: dev
│   └── Project: ml-sandbox-dev
└── Project: shared-networking

Level	Purpose	What is attached
Organization	The company root	Org policies, top-level IAM, audit logging defaults
Folder	Group by team, environment, or business unit	IAM and org policies for the whole group
Project	The unit of everything (below)	Resources, enabled APIs, quotas, billing link
Resource	The actual thing	Resource-level IAM (for example one bucket)

Key rules:

• IAM is additive downward. A role granted at the folder applies to all projects inside; you cannot remove an inherited grant lower down (you can use deny policies or IAM conditions, which are separate mechanisms).
• Org policies are the guardrails: restrict regions (gcp.resourceLocations), forbid service-account key creation, require OS Login, and so on.
• Without an organization (a personal Gmail account) you only have loose projects, so none of the central governance applies.

A project is the fundamental container and boundary in GCP. Every resource belongs to exactly one project. It is the unit of:

1. Ownership and organisation — resources are created in a project.
2. Access control — IAM roles are most often granted at the project level; service accounts are created in a project.
3. API enablement — a service (Vertex AI, Cloud Run, BigQuery) must be enabled per project before use (gcloud services enable aiplatform.googleapis.com).
4. Billing — each project is linked to exactly one billing account at a time; costs are reported per project.
5. Quotas — most quotas (GPUs, requests per minute, Gemini tokens per minute) are per project (and usually per region).
6. Networking scope — a VPC network belongs to a project (shared VPC lets one host project share its network with others).
7. Audit and logging — logs, metrics, and audit trails are scoped to the project.

The three identifiers

Identifier	Example	Notes
Project name	My ML Sandbox	Human-friendly label, can be changed, need not be unique
Project ID	ml-sandbox-482913	Globally unique, chosen at creation, immutable, used in APIs, CLI, and resource names
Project number	341827364518	Assigned by Google, immutable; appears in default service account emails (341827364518-compute@developer.gserviceaccount.com)

Working with projects

gcloud projects create ml-sandbox-482913 --folder=123456789012
gcloud billing projects link ml-sandbox-482913 --billing-account=0X0X0X-0X0X0X-0X0X0X
gcloud config set project ml-sandbox-482913
gcloud services enable run.googleapis.com aiplatform.googleapis.com

Project-per-what? — design guidance

• Separate by environment (dev / staging / prod) so a mistake or a leaked credential cannot cross the boundary, and so IAM and quotas differ per environment.
• Separate by team or workload when blast radius, cost attribution, or access needs differ. A common pattern is one project per service per environment.
• Do not create one project per customer unless you really need isolation; there are limits on project counts and management overhead.
• Keep shared resources (networking, artifact registry, logging sinks, CI/CD) in dedicated shared projects.
• Use labels (env=prod, team=ml) on projects and resources for cost reports.

Lifecycle and gotchas

• Deleting a project schedules deletion; you have about 30 days to restore it. After that everything inside (data, service accounts, API keys) is gone.
• Default service accounts (the Compute Engine default account) are often granted Editor automatically on older projects: over-privileged. Create dedicated service accounts with least-privilege roles instead.
• Enabling an API is not free of consequence: some APIs have costs or default quotas of zero until requested.
• A project with no billing account can use only free APIs; paid services fail with a billing-not-enabled error. If billing is disabled (for example after a card failure), paid resources are stopped.

The geography

Google Cloud
├── Region: europe-west4 (Netherlands)          <- an independent geographic area
│   ├── Zone: europe-west4-a                    <- a deployment area within a region
│   ├── Zone: europe-west4-b                    (separate power, cooling, networking;
│   └── Zone: europe-west4-c                     low-latency links between zones)
├── Region: us-central1 (Iowa)
└── Multi-region: EU, US, ASIA                  <- a large area spanning several regions

• A region is an independent geographic location (there are 40+), named <area>-<direction><number>: europe-west4, us-central1, asia-northeast1. Regions are at least hundreds of kilometres apart.
• A zone (what you may call a subregion) is an isolated failure domain inside a region, named <region>-<letter>: europe-west4-a. Each region has three or more zones (a few older ones have fewer). A zone is roughly one or more datacenters; it can fail independently of its siblings.
• A multi-region (EU, US, ASIA) is a special location for some services (Cloud Storage, BigQuery, Spanner) where data is stored redundantly across several regions within the area.
• Global resources (VPC networks, global load balancers, IAM, Cloud DNS) are not tied to a single region.

Resource scope: global, regional, or zonal

Scope	Examples	Failure behaviour
Zonal	Compute Engine VM, persistent disk, GPU VM	Lost if that zone fails
Regional	Cloud Run service, GKE regional cluster, regional MIG, Cloud SQL (HA), subnetworks, Vertex AI endpoint	Survives a single-zone failure
Multi-regional	Cloud Storage EU bucket, BigQuery US dataset, Spanner multi-region	Survives a regional outage
Global	VPC, global external load balancer, IAM policies	Not region-bound

How to choose a region

1. Data residency and compliance — GDPR, local-law requirements. Use the org policy constraints/gcp.resourceLocations to enforce allowed locations.
2. Latency to users and to your other systems — keep compute near the data and near the callers.
3. Service and hardware availability — not every region has every service, GPU type (L4, A100, H100, TPU), or Gemini model version. ML teams are often constrained by GPU availability: us-central1, europe-west4, and a few others tend to have the most.
4. Price — the same SKU varies by region (often 10-30%).
5. Carbon footprint — Google publishes a low-carbon indicator per region.

Zones and high availability

• Putting an app in one zone is a single point of failure for that zone.
• For HA, spread across two or more zones in one region (regional managed instance groups, regional GKE, Cloud Run does it automatically) behind a load balancer.
• For disaster recovery, replicate to a second region (cross-region replicas, multi-region storage, a warm standby).
• Traffic between zones in a region is cheap but not free; traffic between regions and out to the internet costs more (see billing).

Practical details

gcloud config set compute/region europe-west4
gcloud config set compute/zone   europe-west4-a
gcloud compute zones list --filter="region:europe-west4"
gcloud run deploy my-svc --image=... --region=europe-west4

• Data and models for generative AI have location endpoints: a regional endpoint (europe-west4-aiplatform.googleapis.com) pins processing to a region, while a global endpoint routes to wherever capacity is. For strict residency use a regional (or multi-region data-residency) endpoint, noting that the newest Gemini models are often available first or only on the global endpoint.
• A common mistake is mixing regions: a Cloud Run service in us-central1 reading a bucket in europe-west4 pays latency and egress charges on every request.

The model

Billing account  (payment profile: card or invoicing, currency, tax info)
   ├── Project A   ── resources ── usage (metered by SKU)
   ├── Project B
   └── Project C
Cost = sum over SKUs of (usage × unit price) − discounts/credits

• A Cloud Billing account holds the payment method and is linked to one or more projects. A project has one billing account at a time; one billing account can serve many projects. Billing accounts can be owned by an organization, so finance controls them while teams control projects.
• Usage is metered per SKU and attributed to the project, service, region, and labels that produced it.
• You pay in arrears: usage accrues through the month and is charged when a threshold is reached or at the monthly cycle end (self-serve cards) or invoiced (monthly invoicing for larger customers).

Roles that matter

• Billing Account Administrator — links projects, manages payment and budgets.
• Billing Account User — can link a project to the account (needed when creating projects).
• Billing Account Viewer — reads cost data.
• Project roles (Owner, Editor) do not grant access to the billing account itself.

Pricing models

Model	How it works	Typical use
On-demand	Per second/minute/request/token, no commitment	Default, spiky or unknown load
Sustained-use discount (SUD)	Automatic discount when a VM runs a large fraction of the month (applies to some older machine families)	Always-on VMs
Committed-use discount (CUD)	Commit to spend or resources for 1 or 3 years for a lower rate (resource-based, or flexible spend-based)	Predictable baseline load, GPUs, Cloud Run, Vertex AI
Spot VMs	60-91% off, can be preempted at any time with a short notice	Fault-tolerant batch, training with checkpointing
Provisioned throughput (Gemini)	Reserve model capacity for a fixed fee	Predictable latency and throughput for production LLM traffic
Free tier	Monthly free usage for selected products (always-free) and a trial credit for new accounts	Experiments
Negotiated / enterprise	Custom discounts, marketplace commits	Large customers

What generates cost (the usual suspects)

1. Compute — VMs, GPUs and TPUs are billed per second while allocated, whether or not they are busy. A forgotten GPU VM is the classic bill shock. Cloud Run bills per request-time (or per instance-time if CPU is always allocated); scale-to-zero means no cost while idle.
2. Storage — per GB-month, by class (Standard, Nearline, Coldline, Archive); persistent disks bill even when the VM is stopped.
3. Network egress — data leaving a region or to the internet. Ingress is free. Cross-region and cross-zone traffic is billed at lower rates.
4. Managed AI usage — Gemini and other models are billed per token (input and output priced differently, with separate rates for cached tokens, long context, batch, and image/audio/video modality); embeddings per character or token; training and endpoints per node-hour.
5. Data analytics — BigQuery per bytes scanned (on-demand) or per slot (capacity).
6. Logging and monitoring — ingestion volume beyond free allotment, often a surprise.

Controls and visibility

• Budgets and alerts — set a budget on a billing account or project, with email/Pub/Sub alerts at thresholds (50%, 90%, 100%). A budget does not stop spending by itself. To enforce a cap you must wire the Pub/Sub alert to a function that disables billing on the project (blunt, and it stops all paid services).
• Quotas — protect against runaway usage (limits on GPUs, requests, tokens). Lowering quotas is a real cost safeguard.
• Billing export to BigQuery — detailed per-SKU, per-label, per-project data; the basis for custom dashboards and FinOps analysis.

-- Top cost drivers by service and project, last 30 days (BigQuery billing export)
SELECT service.description AS service, project.id AS project,
       ROUND(SUM(cost) + SUM(IFNULL((SELECT SUM(c.amount) FROM UNNEST(credits) c), 0)), 2) AS net_cost
FROM `my-billing-project.billing.gcp_billing_export_v1_XXXXXX`
WHERE usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY service, project
ORDER BY net_cost DESC
LIMIT 20;

• Labels on resources and projects (team, env, cost-center) flow into the export, enabling chargeback.
• Recommender and Cloud Billing reports suggest idle VMs, oversized machines, and commitment opportunities.

Cost hygiene checklist for ML work

1. Delete or stop GPU VMs, notebooks, and Vertex endpoints when idle; prefer scale-to-zero services (Cloud Run) for inference with spiky traffic.
2. Use Spot VMs with checkpointing for training.
3. Keep data, training, and serving in the same region.
4. Cache prompts and use batch pricing for Gemini where latency allows.
5. Set a project budget plus alert, and request quotas only as high as needed.
6. Export billing to BigQuery and review monthly.