GCP
Intermediate 15 min read GCP

Compute Engine and Instance Groups

VMs, disks and autoscaling groups

Compute Engine is GCP's IaaS: machine families, images, disks and instance groups with autoscaling. Managed instance groups autoheal and spread across zones; autoscaling scales on utilization.

Compute Enginemachine familymanaged instance groupautoscalingdiskspreemptible
Prerequisites: GCP Service Catalog Compute Families
Before we start

What you will learn

  • Pick a machine family and shape
  • Use managed instance groups with health checks
  • Configure autoscalers and spot/preemptible usage
In 60 seconds

Compute Engine VMs are virtual machines; machine families (E2, N2, C3, M3, GPU) tune cost vs resources. Managed instance groups auto-create/replace instances from an instance template and autoscale on utilization.

Introduction

What is this?

Compute Engine lets you run virtual machines driven by a machine type (vCPU+RAM), boot/attached disks (zonal or regional persistent, SSD, local SSD), an image (Linux/Windows/custom), and network config. Instance templates define a VM spec; Managed Instance Groups (MIGs) keep the desired count, autoheal unhealthy instances, and spread across zones (regional MIGs). Autoscalers add/remove instances based on CPU, load balancer utilization or custom metrics. Spot/preemptible VMs give big discounts for interruptible work.

Motivation

Why do you need it?

  • MIGs replace the VM-as-a-pet problem: define the template, the group maintains the herd.
  • Autoscaling unit economics beat over-provisioning when traffic is spiky.
  • Spot/ preemptible VMs are the cheapest compute path for batch, CI and stateless scale-out.
  • Regional disks + regional MIGs get real HA without a cluster stack.
Think about it

Mental model

Imagine

A trucking company with a fleet policy

Think of

Compute Engine + MIG

One truck (VM) you drive yourself. A fleet (MIG): the yard keeps a set number of trucks by model (template), rotates out broken ones (autoheal), and dispatches more during peak (autoscale). Spot trucks are the cheap booking for non-critical hauls.

Mechanics

How it works

  • Machine type fixes baseline vCPU/RAM; families trade balance (E2) vs compute (C3) vs memory (M3).
  • An instance template defines image/disk/network/service account — the immutable blueprint.
  • MIG creates instances from the template; a health check marks instances unhealthy → replacement.
  • Autoscaler watches utilization metrics and adjusts group size between min/max.
  • Spot VMs are cheaper but preemptible; design retries and resumable work for them.

MIG lifecycle with autoscaler.

Instance template
MIG
Health check
Autoscaler
Backend service
Real world

In production

  • A gaming backend runs a regional MIG across 3 zones behind a global LB with autoscaling on request rate.
  • A batch platform escalates to spot VMs for nightly ETL, retrying interleps on preemption.
  • A CI farm uses a MIG with a custom image baking pipelines, autohealing dead agents.
Guidelines

Best practices

  • Model instances as templates + MIGs, never flip individual VMs by hand.
  • Right-size machine type before autoscaling — scaling a fat VM is waste.
  • Use regional MIGs + health checks for zone-failure tolerance.
  • Reserve leader/traffic-sensitive work for regular VMs; push stateless batch onto spot.
Watch out

Common mistakes

  • Autoscaling with no max → surprise bill on a traffic spike.
  • No health check → the group keeps serving unhealthy instances.
  • Using preemptible VMs for stateful or deadline-bound work.
  • Template drift — hand-edited VMs ignore the template, and group replace reverts your fixes.
Root cause analysis

Common issues

Error
MIG can't create the desired count
Root cause

Region/zone quota, or the template references removed resources

Fix

Check quota (instance/CPU) and that the template's disk/image still exists.

Error
Instances cycling in a restart loop
Root cause

Health check failing due to port/path mismatch

Fix

Verify the app listens on the health-check path; review the health check's port & proxy protocol.

Error
Autoscaler removes instances during a spike
Root cause

Aggregation/cooldown settings cause early scale-in

Fix

Lengthen scale-in cooldown and adjust over-utilization window before it cuts.

When things break

Debugging tips

  • MIG not full? Check instance template validity and quota; read group status and instance health.
  • Autoscale stall: verify the metric, target utilization and min/max values.
  • Vm count jumps? Look at autohealing replacements vs autoscaler churn (cooldowns).
  • Preemption storms: use consumption/spot config and retry loops for the interrupted batch.
Interviews

Interview checkpoint

Practice

Hands-on lab

Create a MIG Behind a Health Check (or Plan)
35 min · intermediate
In progress
Objectives
  • Create an instance template
  • Create a managed instance group with a health check
  • Add an autoscaler and observe desired size

Create a MIG Behind a Health Check (or Plan)

35 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

What keeps a managed instance group's instance count at its target?

2

Spot VMs are cheaper than on-demand but can be reclaimed at short notice.

Go deeper

Official documentation

GCP — Compute Engine overview
docs
GCP — Managed instance groups
docs
GCP — Autoscaling
docs