GCP Compute Engine (GCE)

Compute Engine is GCP's VM service — equivalent to AWS EC2. Google's infrastructure advantage shows up here: live migration, custom machine types, and better sustained use economics.

Machine Families Overview

graph LR
    classDef burstable fill:#16a085,stroke:#117a65,color:#fff
    classDef general fill:#2980b9,stroke:#1f618d,color:#fff
    classDef compute fill:#e67e22,stroke:#ba6018,color:#fff
    classDef memory fill:#8e44ad,stroke:#6c3483,color:#fff
    classDef gpu fill:#c0392b,stroke:#922b21,color:#fff

    subgraph AWS["AWS EC2 instance families"]
        T3["t3, t4g<br/>burstable"]:::burstable
        M5["m5, m6i<br/>general purpose"]:::general
        C5["c5, c6i<br/>compute optimized"]:::compute
        R5["r5, r6i<br/>memory optimized"]:::memory
        P3["p3, p4<br/>GPU"]:::gpu
        INF["inf1, trn1<br/>ML inferencing"]:::gpu
    end

    subgraph GCP["GCP machine families"]
        E2["e2<br/>cost-optimized, shared/dedicated"]:::burstable
        N2["n2, n2d, n4<br/>general purpose"]:::general
        C2["c2, c3<br/>compute optimized"]:::compute
        M1["m1, m2, m3<br/>memory optimized"]:::memory
        A2["a2, g2<br/>GPU — A100/L4"]:::gpu
        A3["a3 (H100 GPU), TPU<br/>TPU unique to GCP"]:::gpu
    end

    T3 -->|"closest analog"| E2
    M5 -->|"closest analog"| N2
    C5 -->|"closest analog"| C2
    R5 -->|"closest analog"| M1
    P3 -->|"closest analog"| A2
    INF -->|"closest analog, but<br/>not a real equivalent"| A3

Machine Family Quick Guide

Custom Machine Types — GCP's Killer Feature

AWS forces you into predefined sizes (4 vCPU → 16GB, or 8 vCPU → 32GB, etc.). GCP lets you specify exact vCPU and memory independently:

# AWS: you'd pick m5.xlarge (4 vCPU, 16 GB) even if you need 4 vCPU, 10 GB
# GCP: specify exactly what you need
gcloud compute instances create my-vm \
  --machine-type=custom-4-10240    # 4 vCPUs, 10240 MB (10 GB)

# Format: custom-{vCPUs}-{memoryMB}
# Constraints: memory must be between 0.9 GB and 6.5 GB per vCPU

# Extended memory (beyond 6.5 GB/vCPU)
gcloud compute instances create my-vm \
  --machine-type=custom-4-30720-ext    # 4 vCPUs, 30 GB (extended)

This often saves 20-40% cost compared to the next-size-up predefined instance on AWS.

Creating a VM

# Minimal VM
gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-2

# Production VM with all options
gcloud compute instances create prod-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --boot-disk-size=50GB \
  --boot-disk-type=pd-ssd \
  --network=my-vpc \
  --subnet=us-subnet \
  --no-address \                     # no external IP (private VM)
  --service-account=my-app-sa@project.iam.gserviceaccount.com \
  --scopes=cloud-platform \          # allow SA to call any GCP API it has IAM for
  --tags=backend \                   # firewall rule selector
  --metadata=startup-script='#!/bin/bash
    apt-get update -y
    apt-get install -y nginx'

Key Flags vs AWS

Disk Types

# Add a persistent disk to a running VM
gcloud compute disks create my-data-disk \
  --zone=us-central1-a \
  --size=200GB \
  --type=pd-ssd

gcloud compute instances attach-disk my-vm \
  --disk=my-data-disk \
  --zone=us-central1-a

# Resize a disk (can be done live, no reboot needed)
gcloud compute disks resize my-data-disk \
  --size=400GB \
  --zone=us-central1-a
# Then: sudo resize2fs /dev/sdb (inside VM)

GCP advantage: Persistent Disk can be attached to multiple VMs in read-only mode (for shared datasets). EBS multi-attach is limited and complex.

Preemptible VMs and Spot VMs

Two types of discounted VMs:

# Spot VM (recommended over preemptible for new workloads)
gcloud compute instances create my-spot-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP   # STOP or DELETE on preemption

# Preemptible (legacy)
gcloud compute instances create my-preemptible-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --preemptible

Handling Preemption

# Check if VM was preempted
gcloud compute instances describe my-vm \
  --zone=us-central1-a \
  --format='get(scheduling.preempted)'

# Use a startup script to resume work after preemption
--metadata=startup-script='#!/bin/bash
  # check if this is a restart after preemption
  PREEMPTED=$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/preempted" -H "Metadata-Flavor: Google")
  if [ "$PREEMPTED" = "true" ]; then
    # resume from checkpoint
    gsutil cp gs://my-bucket/checkpoint.pkl /tmp/checkpoint.pkl
  fi
  python3 /opt/train.py'

Instance Templates and Managed Instance Groups (MIGs)

AWS: Launch Template + Auto Scaling Group. GCP: Instance Template + Managed Instance Group.

# Instance Template = Launch Template
gcloud compute instance-templates create my-template \
  --machine-type=n2-standard-2 \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --tags=backend \
  --service-account=my-app-sa@project.iam.gserviceaccount.com \
  --metadata=startup-script='#!/bin/bash
    apt-get install -y my-app
    systemctl start my-app'

# Managed Instance Group = Auto Scaling Group
gcloud compute instance-groups managed create my-mig \
  --template=my-template \
  --size=3 \
  --region=us-central1

# Enable autoscaling (= ASG scaling policy)
gcloud compute instance-groups managed set-autoscaling my-mig \
  --region=us-central1 \
  --min-num-replicas=2 \
  --max-num-replicas=20 \
  --target-cpu-utilization=0.60 \
  --cool-down-period=90

MIG Health Checks (= ASG Health Checks)

# Create health check
gcloud compute health-checks create http my-health-check \
  --port=8080 \
  --request-path=/health \
  --check-interval=10s \
  --timeout=5s \
  --healthy-threshold=2 \
  --unhealthy-threshold=3

# Attach to MIG
gcloud compute instance-groups managed update my-mig \
  --health-checks=my-health-check \
  --initial-delay=120s \
  --region=us-central1

SSH and Connectivity

# SSH to a VM (gcloud handles key management — no .pem files needed)
gcloud compute ssh my-vm --zone=us-central1-a

# SSH to a private VM (no external IP) via OS Login + IAP tunnel
# IAP = Identity-Aware Proxy (GCP's Session Manager equivalent)
gcloud compute ssh my-vm \
  --zone=us-central1-a \
  --tunnel-through-iap

# Required firewall rule for IAP
gcloud compute firewall-rules create allow-iap-ssh \
  --network=my-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --source-ranges=35.235.240.0/20 \  # Google IAP IP range
  --rules=tcp:22

GCP advantage: IAP tunneling is like AWS Systems Manager Session Manager — SSH to private VMs without bastion hosts or public IPs. No .pem files, keys rotated per session.

Live Migration — GCP's Unique Advantage

AWS: when underlying hardware needs maintenance, your instance gets rebooted (scheduled maintenance event). GCP: VMs are live migrated — moved to another host transparently while running. You see a brief performance dip (~10ms) but no reboot, no downtime.

This is why GCP claims better VM availability SLAs. For stateful applications (databases running on GCE), this is significant.

sequenceDiagram
    participant VM as Running VM
    participant SRC as Source host
    participant DST as Destination host

    Note over SRC: Host flagged for upcoming maintenance
    SRC->>DST: Select healthy destination host, begin migration
    loop Iterative pre-copy
        SRC->>DST: Copy VM memory pages while VM keeps serving traffic
        DST-->>SRC: Acknowledge copied pages
    end
    Note over VM,DST: Final sync — VM briefly paused, ~10ms
    SRC->>DST: Copy last changed state
    DST->>VM: Resume execution on destination host
    Note over VM: No reboot, no dropped connections at the OS level

Pricing Model

Pricing Models

Example — n2-standard-4 (us-central1)

Sustained use discounts are fully automatic — just run a VM for most of the month and Google discounts it. AWS requires you to purchase Reserved Instances upfront.

GCE vs EC2 — Summary

Instance Groups

Instance groups let you manage multiple VMs as a single unit and attach them to load balancers. Two types: Managed (GCP controls the VMs) and Unmanaged (you control the VMs, GCP just groups them).

Managed Instance Group (MIG)

A MIG creates identical VMs from an instance template and manages them automatically — auto-healing, auto-scaling, rolling updates, and multi-zone distribution.

graph TD
    classDef template fill:#2c3e50,stroke:#1a252f,color:#fff
    classDef mig fill:#2980b9,stroke:#1f618d,color:#fff
    classDef vm fill:#27ae60,stroke:#1e8449,color:#fff

    TPL["Instance Template<br/>blueprint: machine type, image,<br/>service account, startup script"]:::template --> MIG["Managed Instance Group"]:::mig
    subgraph MIG_GROUP["Identical VMs, spread across zones"]
        V1["VM-1"]:::vm
        V2["VM-2"]:::vm
        V3["VM-3"]:::vm
    end
    MIG --> V1
    MIG --> V2
    MIG --> V3
    V1 -.->|"fails health check →<br/>GCP auto-recreates from template"| MIG

AWS analog: Auto Scaling Group + Launch Template.

# 1. Create instance template
gcloud compute instance-templates create my-template \
  --machine-type=n2-standard-2 \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --tags=backend \
  --service-account=my-app-sa@project.iam.gserviceaccount.com \
  --metadata=startup-script='#!/bin/bash
    apt-get install -y my-app
    systemctl start my-app'

# 2. Regional MIG (spreads VMs across zones automatically — recommended)
gcloud compute instance-groups managed create my-mig \
  --template=my-template \
  --size=3 \
  --region=us-central1     # distributes across us-central1-a/b/c

# Zonal MIG (single zone, simpler but no zone-level HA)
gcloud compute instance-groups managed create my-mig-zonal \
  --template=my-template \
  --size=3 \
  --zone=us-central1-a

Auto-healing

# Create health check
gcloud compute health-checks create http my-hc \
  --port=8080 \
  --request-path=/health \
  --check-interval=10s \
  --unhealthy-threshold=3    # 3 consecutive failures → VM is recreated

# Attach health check to MIG
gcloud compute instance-groups managed update my-mig \
  --health-checks=my-hc \
  --initial-delay=120s \     # grace period after boot before checks count
  --region=us-central1

Auto-scaling

# Scale on CPU
gcloud compute instance-groups managed set-autoscaling my-mig \
  --region=us-central1 \
  --min-num-replicas=2 \
  --max-num-replicas=20 \
  --target-cpu-utilization=0.60 \
  --cool-down-period=90s

# Scale on HTTP load (requests/sec per instance)
gcloud compute instance-groups managed set-autoscaling my-mig \
  --region=us-central1 \
  --max-num-replicas=20 \
  --target-load-balancing-utilization=0.8

# Scale on Pub/Sub queue depth (custom metric)
gcloud compute instance-groups managed set-autoscaling my-mig \
  --region=us-central1 \
  --max-num-replicas=50 \
  --custom-metric-utilization=metric=pubsub.googleapis.com/subscription/num_undelivered_messages,utilization-target=100,utilization-target-type=GAUGE

Rolling Updates

# Zero-downtime rolling update to new template version
gcloud compute instance-groups managed rolling-action start-update my-mig \
  --version=template=my-template-v2 \
  --region=us-central1 \
  --max-surge=3 \            # create 3 extra VMs during rollout (no capacity drop)
  --max-unavailable=0        # never remove a VM before its replacement is healthy

# Canary: 10% of VMs on new version first
gcloud compute instance-groups managed rolling-action start-update my-mig \
  --version=template=my-template-v1 \
  --canary-version=template=my-template-v2,target-size=10% \
  --region=us-central1

# Rollback instantly
gcloud compute instance-groups managed rolling-action start-update my-mig \
  --version=template=my-template-v1 \
  --region=us-central1

Stateful MIG (for databases and stateful apps)

By default, when a VM in a MIG is recreated, its disk is wiped. Stateful MIG preserves per-VM state:

gcloud compute instance-groups managed update my-stateful-mig \
  --stateful-disk=device-name=data-disk,auto-delete=never \
  --stateful-external-ip=interface-name=nic0,auto-delete=never \
  --region=us-central1
# Each VM keeps its disk and IP across restarts/updates

Unmanaged Instance Group (UIG)

A UIG is just a label/grouping for existing VMs. GCP does nothing automatically — no auto-healing, no auto-scaling, no rolling updates. You manually add and remove VMs. VMs in a UIG can have different machine types, images, and configs.

graph TD
    classDef uig fill:#7f8c8d,stroke:#616a6b,color:#fff
    classDef vma fill:#2980b9,stroke:#1f618d,color:#fff
    classDef vmb fill:#e67e22,stroke:#ba6018,color:#fff
    classDef vmc fill:#8e44ad,stroke:#6c3483,color:#fff

    UIG["Unmanaged Instance Group<br/>just a label — no automation"]:::uig --> A["VM-A<br/>n2-standard-4, debian"]:::vma
    UIG --> B["VM-B<br/>e2-standard-2, ubuntu<br/>different config allowed"]:::vmb
    UIG --> C["VM-C<br/>n1-standard-8, custom image"]:::vmc

The only real use case: attaching a set of heterogeneous or pre-existing VMs to a load balancer. Load balancers require a backend to be an instance group or NEG — if your VMs already exist and aren't identical, UIG is how you group them.

# Create UIG
gcloud compute instance-groups unmanaged create my-uig \
  --zone=us-central1-a

# Add existing VMs
gcloud compute instance-groups unmanaged add-instances my-uig \
  --instances=vm-a,vm-b,vm-c \
  --zone=us-central1-a

# Define named ports (required for load balancer backend)
gcloud compute instance-groups unmanaged set-named-ports my-uig \
  --named-ports=http:8080 \
  --zone=us-central1-a

# Remove a VM
gcloud compute instance-groups unmanaged remove-instances my-uig \
  --instances=vm-a \
  --zone=us-central1-a

MIG vs UIG — When to Use Which

Rule of thumb: always use MIG. UIG is a legacy escape hatch for VMs you can't recreate from a template.

Logging and Serial Ports

Two separate but related debugging features available on every GCE instance.

Logging Tab

The Logging tab on a VM instance page shows Cloud Logging entries scoped to that VM — a filtered view of:

• OS-level logs (syslog, kernel messages) — collected by the Ops Agent
• Startup script output
• Application logs (if Ops Agent is configured to tail them)

It's identical to querying Cloud Logging with:

resource.type="gce_instance"
resource.labels.instance_id="1234567890"

Useful for quick instance-specific log review without opening the full Logging console.

Serial Ports — The Emergency Console

A serial port (COM port) is a low-level hardware communication channel that exists independently of the OS and network stack. Unlike SSH (which requires the OS, network, and sshd to be running), serial ports work:

• During BIOS/UEFI POST
• During kernel boot (before network is up)
• During kernel panics and OS crashes
• When the VM is completely unresponsive

graph LR
    classDef serial fill:#e67e22,stroke:#ba6018,color:#fff
    classDef sshok fill:#27ae60,stroke:#1e8449,color:#fff

    BIOS["BIOS / UEFI POST"]:::serial --> GRUB["GRUB bootloader"]:::serial
    GRUB --> KERNEL["Kernel boot<br/>network not up yet"]:::serial
    KERNEL --> INITRAMFS["initramfs"]:::serial
    INITRAMFS --> SYSTEMD["systemd starts units"]:::serial
    SYSTEMD --> SSHD["sshd starts"]:::sshok
    SSHD --> APP["Your application"]:::sshok

    subgraph LEGEND["Visibility"]
        direction LR
        L1["Serial port captures all of this"]:::serial
        L2["SSH only works from here on"]:::sshok
    end

Think of it as plugging a physical monitor into a server in a datacenter — the only way to see what's happening when nothing else works.

Serial Port 1 (COM1) — Primary Boot Console

The most important serial port. This is read-only output from the VM and captures:

• GRUB bootloader messages
• Linux kernel boot messages (dmesg equivalent)
• systemd unit startup sequence
• OOM killer events (Out of memory: Kill process...)
• Kernel panics (with full stack trace)
• cloud-init and startup script output (on Debian/Ubuntu images)
• fsck filesystem checks blocking boot

# View serial port 1 output
gcloud compute instances get-serial-port-output my-vm \
  --zone=us-central1-a \
  --port=1

# Follow output (keep polling for new lines)
gcloud compute instances get-serial-port-output my-vm \
  --zone=us-central1-a \
  --port=1 \
  --start=0

Example output you'd see on port 1:

[    0.000000] Linux version 5.15.0-1030-gcp (x86_64)
[    0.000000] BIOS-provided physical RAM map
[    1.234567] EXT4-fs (sda1): mounted filesystem with ordered data mode
[    5.678901] systemd[1]: Starting OpenSSH Server Daemon...
[    6.123456] systemd[1]: Started OpenSSH Server Daemon.
              ← SSH now works, port 1 has everything before this

Common debugging scenarios with port 1:

Serial Port 2 (COM2) — Interactive Console

Port 2 is interactive — you can connect to it and get a login shell. This is your last-resort access method when SSH is completely broken.

# Step 1: enable interactive serial port access (disabled by default)
gcloud compute instances add-metadata my-vm \
  --metadata=serial-port-enable=TRUE \
  --zone=us-central1-a

# Step 2: connect
gcloud compute connect-to-serial-port my-vm \
  --zone=us-central1-a \
  --port=2
# You'll get a login prompt — enter OS username + password
# Press Enter a few times if you don't see the prompt
# Exit with: ~.  (tilde + dot)

You can also connect from the GCP Console: VM details → Remote Access → Connect to serial console.

Use port 2 when:

• sshd crashed or was misconfigured (/etc/ssh/sshd_config broken)
• SSH keys were accidentally wiped
• Network config is broken (can't reach the VM at all)
• Need to reset a password or fix /etc/fstab
• VM is up but SSH returns Connection refused or Permission denied

Serial Ports 3 and 4 (COM3, COM4)

Available for custom use — rarely needed. Some specialized software uses these for debug output channels. Available via the same gcloud compute connect-to-serial-port command with --port=3 or --port=4.

Serial Port Summary

Stream Serial Port Output to Cloud Logging

For production VMs, enable automatic streaming of serial port 1 output to Cloud Logging. This lets you set alerts on kernel panics or OOM events:

# Enable for a single VM
gcloud compute instances add-metadata my-vm \
  --metadata=serial-port-logging-enable=true \
  --zone=us-central1-a

# Enable project-wide (all VMs)
gcloud compute project-info add-metadata \
  --metadata=serial-port-logging-enable=true

Serial port output then appears in Cloud Logging:

resource.type = "gce_instance"
logName = "projects/PROJECT/logs/serialconsole.googleapis.com%2Fserial_port_1_output"

Set a log-based alert for production incidents:

# Alert on kernel panic
gcloud logging metrics create kernel-panic \
  --description="Kernel panic detected on GCE instance" \
  --log-filter='resource.type="gce_instance"
    logName="projects/PROJECT/logs/serialconsole.googleapis.com%2Fserial_port_1_output"
    textPayload:"Kernel panic"'

SSH vs Serial Port — Decision Tree

graph TD
    classDef start fill:#2c3e50,stroke:#1a252f,color:#fff
    classDef check fill:#2980b9,stroke:#1f618d,color:#fff
    classDef bad fill:#c0392b,stroke:#922b21,color:#fff
    classDef warn fill:#f39c12,stroke:#ba6018,color:#fff
    classDef fix fill:#27ae60,stroke:#1e8449,color:#fff

    START["VM is unresponsive / can't SSH"]:::start --> CHECK["Check Serial Port 1 output first<br/>read-only, no setup needed"]:::check

    CHECK --> PANIC["Kernel panic / OOM"]:::bad
    CHECK --> FSCK["fsck running"]:::warn
    CHECK --> UNIT["systemd unit failed"]:::warn
    CHECK --> SSHD["sshd not started"]:::warn
    CHECK --> NET["Network config broken"]:::warn

    PANIC --> FIXPANIC["Fix root cause:<br/>memory or disk issue"]:::fix
    FSCK --> FIXFSCK["Wait, or force-skip<br/>(risky)"]:::warn
    UNIT --> FIXUNIT["Connect via Port 2,<br/>fix unit config"]:::fix
    SSHD --> FIXSSHD["Connect via Port 2,<br/>restart sshd"]:::fix
    NET --> FIXNET["Connect via Port 2,<br/>fix /etc/network"]:::fix