Compute Engine and Managed Instance Groups

A single google_compute_instance is a pet; production Compute Engine on GCP is a managed instance group stamping identical VMs from an instance template, healed and scaled automatically. For Hatch's VM-based workloads you write one google_compute_instance_template, wrap it in a regional google_compute_region_instance_group_manager, attach an autoscaler and a health check, and roll new versions by changing the template — the VMs themselves are disposable.

That disposability is the whole design. No VM is special, none holds irreplaceable state, and any one of them can vanish and be recreated from the template without a human. Once you accept that the template is the source of truth and the running instances are cattle, the rest of the MIG model — autoscaling, autohealing, rolling updates — falls out naturally.

The Instance Template

A google_compute_instance_template is the immutable blueprint: machine type, boot image, disks, network tags, service account, and startup script. It cannot be edited in place. A change means a new template version, which feels like friction until you see it is exactly the property that makes rollouts safe — every version is a distinct, named, reproducible artifact.

Try to mutate a template and Terraform forces a replacement; trying to treat it as editable blocks every rollout. The right mental model is that you never change a template — you create the next one and point the MIG at it.

resource "google_compute_instance_template" "app" {
  project      = "hatch-app-prod"
  name_prefix  = "app-"            # new template = new version, never edited in place
  machine_type = "e2-standard-2"
  tags         = ["https-server"]   # picks up the firewall rule from Topic 58

  disk {
    source_image = "debian-cloud/debian-12"
    auto_delete  = true
    boot         = true
  }

  network_interface {
    subnetwork = "projects/hatch-net-host/regions/us-central1/subnetworks/app-uc1"
    # no access_config block = no external IP
  }

  lifecycle {
    create_before_destroy = true   # so a referenced template can be replaced
  }
}

Regional vs Zonal MIG

A google_compute_region_instance_group_manager spreads its instances across the zones of us-central1 and survives a single-zone outage. The zonal google_compute_instance_group_manager pins every instance to one zone, so a routine zone failure takes the entire group down. For anything with an SLO, the choice is regional — the zonal manager is for cases where you genuinely want everything in one zone.

This is where the regional-subnet model from Topic 56 pays off: because the subnet is regional, a regional MIG places instances in any zone of us-central1 on the same subnet with no per-zone networking to set up. The platform spreads the group for you.

The Autoscaler

A google_compute_region_autoscaler scales the MIG between min_replicas and max_replicas on CPU, load-balancer utilization, or a custom metric. Once an autoscaler is attached, the MIG owns the instance count — you never set it by hand. A hand-set target_size on an autoscaled MIG just gets overwritten on the next scaling decision and produces endless plan churn as Terraform and the autoscaler fight over the number.

Pick a metric that actually reflects load. CPU is the default but a request-rate or load-balancer-utilization signal often tracks real demand better for an HTTP workload. Set the floor and ceiling deliberately, and let the autoscaler choose everything in between.

resource "google_compute_region_autoscaler" "app" {
  project = "hatch-app-prod"
  name    = "app-autoscaler"
  region  = "us-central1"
  target  = google_compute_region_instance_group_manager.app.id

  autoscaling_policy {
    min_replicas = 3
    max_replicas = 10
    cpu_utilization {
      target = 0.6          # the autoscaler owns the count — never hand-set it
    }
  }
}

Health Checks and Autohealing

A google_compute_health_check drives two things at once: load-balancer membership and MIG autohealing. When an instance fails the check, autohealing recreates it from the template, so the group self-repairs instead of paging someone at 3 a.m. Omit the health check and autohealing has nothing to act on — a hung VM stays in rotation serving errors until a human notices.

Tune the check to detect a genuinely broken instance, not a momentary blip, because an over-eager check recreates healthy VMs and an over-lax one leaves broken ones serving. The health check is the signal the whole self-healing loop depends on; it is worth getting right.

Rolling Updates by Template Change

Deployment is a template swap. Point the MIG's version at a new instance template and the update_policy — surge and max-unavailable — rolls instances over gradually instead of all at once. This is the entire deploy mechanism on a MIG: new template, controlled rollout, and rollback by reverting the template, with no separate deploy tool.

Mind the capacity math on a small group. An aggressive update_policy with zero max-unavailable and no surge stalls the rollout, because there is no spare capacity to bring replacement instances up into before taking old ones down. Allow some surge so the rollout always has room to move.