Planning and implementing a cloud solution

Choosing compute

GKE modes: Autopilot (Google manages nodes, you pay per Pod resource requests, hardened defaults, the recommended default) vs Standard (you manage node pools, pay for nodes, more control: privileged Pods, custom machine types, GPUs and specific node settings). GKE Enterprise (formerly Anthos) adds fleet management, multi-cluster policy, config sync and service mesh across clouds and on-premises.

The guide mentions “Cloud Run for Anthos”: that product is now Knative serving on GKE / GKE Enterprise. Choose it only when you must run serverless containers on your own clusters. Otherwise Cloud Run (fully managed) is the answer for stateless containers, and Cloud Run functions for small event handlers.

Cloud Run vs Cloud Run functions: functions take source code (a function entry point) and build the container for you; Cloud Run takes a container image (or source with a buildpack via --source). Both scale to zero and are the same platform underneath.

Machine types, Spot VMs, custom machine types

• Predefined types come as standard, highcpu or highmem shapes. Custom machine types let you choose vCPU and memory (for example --custom-cpu=6 --custom-memory=32GB) when no standard shape fits, with extended memory available at a price. Not available for every family (E2 and N-series have them).
• Spot VMs are discounted (up to 60 to 91%) and can be preempted at any time with a 30-second warning. No maximum runtime (the old preemptible VMs ended after 24 hours). Use for fault-tolerant batch, CI, rendering, stateless workers. Not for databases or anything needing guaranteed availability. Set --provisioning-model=SPOT --instance-termination-action=STOP|DELETE.
• Committed use discounts (1 or 3 years, resource or spend based) cut cost for steady usage; sustained use discounts apply automatically to some families. Sole-tenant nodes give dedicated hardware for licensing or compliance.

Choosing data storage

Quick picks: “global relational with strong consistency” = Spanner. “Petabyte analytics with SQL” = BigQuery. “Millions of writes per second, sparse keyed data” = Bigtable. “Mobile app with offline sync” = Firestore. “Lift and shift MySQL” = Cloud SQL. “PostgreSQL needing more speed” = AlloyDB.

Block storage and Cloud Storage classes

Disks can be resized upward only while attached; you cannot shrink them.

All classes have the same latency and durability (11 nines); they differ in price and retrieval fees. Location types: region, dual-region (two specific regions) and multi-region (US, EU, ASIA). Dual- and multi-region give geo-redundancy and higher availability for a higher price. Use Autoclass to move objects between classes automatically by access pattern.

Choosing network resources

Load balancing

Pick by traffic type and scope:

Key points: Application LBs are Layer 7, support URL maps (path and host routing), SSL termination, Cloud CDN, Cloud Armor and IAP. Passthrough network LBs are Layer 4, preserve the client source IP and are regional. Backends are instance groups, network endpoint groups (NEGs), Cloud Storage buckets or serverless NEGs (Cloud Run, functions, App Engine). Health checks decide which backends receive traffic; firewall rules must allow the health check ranges (130.211.0.0/22 and 35.191.0.0/16 for most LBs).

Location availability

• Region = a geographic area (us-central1); zone = an isolated deployment area within it (us-central1-a). Resources can be global (VPC networks, firewall rules, images, snapshots, global LBs), regional (subnets, static regional IPs, regional MIGs, GKE regional clusters) or zonal (VMs, zonal disks, zonal clusters).
• Not every machine type, GPU or service exists in every zone. Check: gcloud compute machine-types list --zones=us-central1-a, gcloud compute zones list, gcloud compute regions list.
• Pick locations by latency to users, data residency law, price, available products and carbon footprint. For high availability spread across at least two zones.

Network Service Tiers

Pick Standard for cost-sensitive traffic where latency is less important and the resource is regional.

Compute Engine deployment

Launching a VM

gcloud compute instances create web-1 \
    --zone=us-central1-a --machine-type=e2-medium \
    --image-family=debian-12 --image-project=debian-cloud \
    --boot-disk-size=20GB --boot-disk-type=pd-balanced \
    --create-disk=name=data-1,size=100GB,type=pd-ssd,auto-delete=no \
    --tags=http-server --metadata=startup-script='apt-get -y install nginx' \
    --service-account=app-sa@my-proj.iam.gserviceaccount.com --scopes=cloud-platform \
    --maintenance-policy=MIGRATE --restart-on-failure \
    --network=my-vpc --subnet=my-subnet --no-address

Attach a disk to a running VM: gcloud compute instances attach-disk web-1 --disk=data-1 --zone=..., then format (mkfs.ext4) and mount.

SSH keys and access

gcloud compute ssh web-1 --zone=us-central1-a uses your credentials and, with OS Login, no key juggling.

Instance templates and managed instance groups

An instance template is an immutable blueprint (machine type, image, disks, network, metadata, service account). Templates cannot be edited: create a new one and roll it out. A managed instance group (MIG) keeps identical VMs from a template and provides autoscaling, autohealing, rolling updates and regional (multi-zone) spreading.

gcloud compute instance-templates create web-tpl-v1 \
    --machine-type=e2-medium --image-family=debian-12 --image-project=debian-cloud \
    --tags=http-server --metadata-from-file=startup-script=start.sh

gcloud compute health-checks create http web-hc --port=80 --request-path=/healthz

gcloud compute instance-groups managed create web-mig \
    --template=web-tpl-v1 --size=2 --region=us-central1 \
    --health-check=web-hc --initial-delay=120

gcloud compute instance-groups managed set-autoscaling web-mig --region=us-central1 \
    --min-num-replicas=2 --max-num-replicas=10 \
    --target-cpu-utilization=0.6 --cool-down-period=90

gcloud compute instance-groups managed rolling-action start-update web-mig \
    --version=template=web-tpl-v2 --region=us-central1 --max-surge=3 --max-unavailable=0

• Autoscaling signals: CPU utilisation, HTTP load balancing serving capacity, Cloud Monitoring metrics, schedules, and a predictive mode. The cool-down (initialization) period keeps the autoscaler from using data from a VM still booting.
• Autohealing recreates VMs that fail an application health check (different from LB health checks, though they can be shared). Set the initial delay longer than boot time.
• Rolling update parameters: maxSurge and maxUnavailable; canary by giving a new template to a subset (--version=template=v2,target-size=20%).
• Zonal vs regional MIG: regional spreads over three zones for resilience; use it for production.
• Stateful MIGs preserve disks, IPs and metadata per instance.
• Unmanaged instance groups are just collections of VMs with no autoscaling or autohealing.

VM Manager

VM Manager is a set of tools for fleet management of Compute Engine VMs, requiring the OS Config agent (installed by default on current Google images) and the OS Config API:

Enable with metadata enable-osconfig=TRUE and gcloud services enable osconfig.googleapis.com. Run a patch job: gcloud compute os-config patch-jobs execute --instance-filter-all --display-name=monthly.

Google Kubernetes Engine deployment

kubectl setup

gcloud components install kubectl          # or: sudo apt install kubectl, or via the standalone package
gcloud components install gke-gcloud-auth-plugin   # required auth plugin for kubectl
gcloud container clusters get-credentials my-cluster --region=us-central1   # writes kubeconfig
kubectl config get-contexts
kubectl config use-context CONTEXT

get-credentials is the command that connects kubectl to a cluster. kubectl talks to the control plane endpoint, so private clusters need network access to it (authorised networks, a VM in the VPC, or the DNS-based endpoint).

Creating clusters

# Autopilot (regional by nature)
gcloud container clusters create-auto ap-cluster --region=us-central1

# Standard zonal
gcloud container clusters create std-zonal --zone=us-central1-a --num-nodes=3 --machine-type=e2-standard-4

# Standard regional (control plane and nodes in three zones; --num-nodes is PER ZONE)
gcloud container clusters create std-regional --region=us-central1 --num-nodes=1

# Private cluster, VPC-native, with authorised networks
gcloud container clusters create priv --region=us-central1 --enable-ip-alias \
    --enable-private-nodes --master-ipv4-cidr=172.16.0.0/28 \
    --enable-master-authorized-networks --master-authorized-networks=203.0.113.0/24

# Autoscaling node pool
gcloud container clusters create asc --zone=us-central1-a --enable-autoscaling --min-nodes=1 --max-nodes=5

Deploying an application

kubectl create deployment web --image=us-docker.pkg.dev/my-proj/repo/web:1.0 --replicas=3
kubectl expose deployment web --type=LoadBalancer --port=80 --target-port=8080
kubectl apply -f deployment.yaml
kubectl get deployments,pods,svc
kubectl rollout status deployment/web

Images come from Artifact Registry (REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG). Container Registry (gcr.io) is shut down.

Cloud Run and Cloud Run functions deployment

# Container image
gcloud run deploy hello --image=us-docker.pkg.dev/cloudrun/container/hello \
    --region=us-central1 --allow-unauthenticated
# From source (builds with buildpacks or a Dockerfile)
gcloud run deploy api --source=. --region=us-central1
# Private service, only callers with roles/run.invoker
gcloud run deploy internal-api --image=... --no-allow-unauthenticated --ingress=internal

# Function triggered by Pub/Sub
gcloud functions deploy on-msg --gen2 --runtime=python312 --region=us-central1 \
    --source=. --entry-point=handler --trigger-topic=my-topic
# Function triggered by a Cloud Storage event
gcloud functions deploy on-upload --gen2 --runtime=python312 --region=us-central1 \
    --source=. --entry-point=handler \
    --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" \
    --trigger-event-filters="bucket=my-bucket"
# HTTP function
gcloud functions deploy hello-http --gen2 --runtime=nodejs22 --trigger-http --allow-unauthenticated

• Cloud Run services can listen to HTTP/gRPC requests; to receive events, connect them through Eventarc triggers or Pub/Sub push subscriptions to the service URL. Eventarc routes events from Google services (including audit-log-based events), Pub/Sub and direct sources as CloudEvents.
• Cloud Run jobs run to completion (batch, migrations), not serving traffic.
• Cloud Storage object change notifications: use Eventarc (google.cloud.storage.object.v1.finalized, .deleted, .archived, .metadataUpdated) or Pub/Sub notifications (gcloud storage buckets notifications create).
• Cloud Run requires the container to listen on $PORT (default 8080) and be stateless. Concurrency, memory and CPU are configurable; default concurrency is 80. Max request timeout up to 60 minutes.
• Where to deploy: HTTP container, stateless, any language: Cloud Run. Small single-purpose event handler: Cloud Run functions. Kubernetes features or stateful: GKE. Needs OS access: Compute Engine.

Data solutions

# Cloud SQL
gcloud sql instances create mydb --database-version=POSTGRES_16 --region=us-central1 \
    --tier=db-custom-2-8192 --availability-type=REGIONAL --storage-auto-increase --backup-start-time=03:00
gcloud sql databases create app --instance=mydb
gcloud sql users create appuser --instance=mydb --password=...
gcloud sql connect mydb --user=postgres

# Spanner
gcloud spanner instances create my-inst --config=regional-us-central1 --description=x --processing-units=100
gcloud spanner databases create appdb --instance=my-inst

# Firestore
gcloud firestore databases create --location=nam5 --type=firestore-native

# BigQuery
bq mk --dataset --location=US my-proj:analytics
bq mk --table analytics.events schema.json

# Pub/Sub
gcloud pubsub topics create orders
gcloud pubsub subscriptions create orders-sub --topic=orders --ack-deadline=30

# Cloud Storage
gcloud storage buckets create gs://my-unique-bucket --location=us-central1 --uniform-bucket-level-access

# AlloyDB
gcloud alloydb clusters create c1 --region=us-central1 --password=... --network=my-vpc

• Cloud SQL high availability (--availability-type=REGIONAL) keeps a standby in another zone with synchronous replication and automatic failover. Read replicas scale reads (and can be cross-region); they do not provide HA failover automatically. Private IP needs private services access.
• Firestore has Native mode (documents and real time) and Datastore mode; the choice is permanent for the database. A database location is permanent too.
• Spanner capacity is nodes or processing units (100 PU = 0.1 node), with regional or multi-region configs.
• Pub/Sub subscription kinds: pull, push, BigQuery, Cloud Storage. Unacknowledged messages are kept 7 days by default on a subscription (the maximum for subscription retention).
• Dataflow runs Beam pipelines, from templates (gcloud dataflow jobs run --gcs-location=gs://dataflow-templates/...) or code.

Loading data

Rule of thumb for bulk transfer: small data or good bandwidth: gcloud storage cp. Many TB from other cloud or recurring: Storage Transfer Service. Hundreds of TB with poor bandwidth: Transfer Appliance.

Networking resources

VPC and subnets

A VPC network is global; subnets are regional (and span the zones in that region). Routes and firewall rules are VPC-wide. Auto mode creates a subnet in every region with a fixed 10.128.0.0/9 layout, which can overlap with other networks; custom mode lets you define subnets and ranges. Use custom mode for production. The default network is auto mode with permissive rules (SSH, RDP, ICMP, internal) and is best deleted, or blocked by skipDefaultNetworkCreation.

gcloud compute networks create prod-vpc --subnet-mode=custom
gcloud compute networks subnets create web-subnet --network=prod-vpc \
    --region=us-central1 --range=10.10.0.0/24 \
    --enable-private-ip-google-access

• Private Google Access lets VMs with only internal IPs reach Google APIs.
• Subnets can add secondary ranges (used by GKE Pods and Services).
• Subnet primary ranges can’t overlap in a VPC; they must be RFC 1918 or privately used public ranges.

Shared VPC

Shared VPC lets a host project own the network while service projects attach and create resources in its subnets. Needs the organization. Admin role: Shared VPC Admin (roles/compute.xpnAdmin), granted at org or folder. Service project users need roles/compute.networkUser on the host project or specific subnets.

gcloud compute shared-vpc enable HOST_PROJECT
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT --host-project=HOST_PROJECT

Use when: central network and security control, separate team projects, same organization. Use VPC Network Peering instead for connecting independent networks (possibly across organizations).

Firewall rules and policies

• VPC firewall rules are stateful, apply to a network, have direction (ingress/egress), priority (0 to 65535, lower number wins), action (allow/deny), a target (all instances, network tags, or service accounts) and a source/destination (CIDR ranges, tags, service accounts).
• Implied rules (lowest priority 65535): allow all egress and deny all ingress. These can’t be deleted but can be overridden.
• Service-account-based rules are more secure than tag-based rules because only IAM controls who can use a service account; tags can be added by anyone with edit rights on the VM.
• Hierarchical firewall policies (organization or folder level) and network firewall policies apply rules at scale; they are evaluated before VPC rules.

gcloud compute firewall-rules create allow-http --network=prod-vpc --direction=INGRESS \
    --action=ALLOW --rules=tcp:80,tcp:443 --source-ranges=0.0.0.0/0 --target-tags=http-server --priority=1000
gcloud compute firewall-rules create allow-from-web --network=prod-vpc --allow=tcp:5432 \
    --source-tags=web --target-tags=db
gcloud compute firewall-rules create allow-iap-ssh --network=prod-vpc --allow=tcp:22 --source-ranges=35.235.240.0/20
gcloud compute firewall-rules list --filter="network:prod-vpc"

Connecting external networks

gcloud compute networks peerings create peer-a-b --network=vpc-a --peer-network=vpc-b --peer-project=proj-b
gcloud compute vpn-gateways create ha-gw --network=prod-vpc --region=us-central1
gcloud compute routers create vpn-router --network=prod-vpc --region=us-central1 --asn=65001

Choose VPN for quick, cheap, encrypted over the internet. Choose Interconnect for high throughput and consistent latency. Choose Peering between VPCs on Google’s network. Transitive routing does not work through peering.

Infrastructure as code

terraform init && terraform plan -out=tfplan && terraform apply tfplan
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-redis bitnami/redis
gcloud infra-manager deployments apply projects/P/locations/us-central1/deployments/d \
    --service-account=... --git-source-repo=... --git-source-directory=.

Terraform tracks state; drift is the difference between state and reality. terraform import brings an existing resource under management.