Managed vs Unmanaged Instance Groups
A Managed Instance Group (MIG) is a collection of identical Compute Engine VMs created from a single instance template, managed as one unit for scaling, updates, and healing. Because every VM is stamped from the same template, GCP can automatically replace unhealthy instances, roll out new versions gradually, and resize the group up or down without you touching individual VMs. An Unmanaged Instance Group, by contrast, is just a logical grouping of dissimilar existing VMs for load balancing purposes — it supports none of the automation MIGs provide, so it's rarely the right choice for production workloads.
Cricket analogy: A managed instance group is like a franchise's entire pace-bowling unit trained under one identical fitness and skills program, so any bowler can be swapped in mid-series without a drop in standard, unlike a mixed unmanaged squad of loanees with no shared training regimen.
Instance Templates
An instance template is an immutable specification — machine type, boot disk image, network tags, startup script, and metadata — that defines what every VM in a MIG looks like. Because templates are immutable, updating a MIG's configuration means creating a new template version and pointing the MIG at it, rather than editing the old one in place; this immutability is what makes rolling updates and rollbacks predictable, since you can always reference the exact prior template version if a new rollout misbehaves.
Cricket analogy: An instance template is like a fixed, board-approved training manual issued to the entire fast-bowling academy — you don't edit last year's manual mid-season, you publish version two and transition bowlers onto it gradually.
Autoscaling Policies
MIG autoscaling adjusts the number of instances based on one or more signals: average CPU utilization, HTTP load balancer serving capacity, Cloud Monitoring custom metrics, or scheduled scaling for predictable traffic patterns. You configure a target value (e.g., 60% average CPU) plus min and max instance counts, and the autoscaler adds or removes instances to converge on that target, respecting cooldown periods so it doesn't thrash by scaling up and down repeatedly for short-lived spikes.
Cricket analogy: This is like a captain rotating bowlers to keep the over-rate and workload target steady across a T20 innings — bring on an extra bowler when the required run rate spikes, rest one when the game is settled, without over-rotating on every single ball.
Health Checks and Auto-Healing
MIGs support auto-healing through health checks: if an instance fails a configured health check (e.g., an HTTP probe to /healthz returning non-200 for a sustained period), the MIG automatically deletes and recreates that instance from the template. This is distinct from the load balancer's own health checks, which only remove an unhealthy instance from serving traffic without recreating it — auto-healing goes a step further by actually replacing the broken VM, which is critical for recovering from crashed processes or corrupted state without manual intervention.
Cricket analogy: Auto-healing is like a team's medical staff immediately substituting a concussed fielder with a like-for-like replacement from the bench under concussion substitute rules, rather than just resting him on the boundary and playing a man short.
# Create an instance template
gcloud compute instance-templates create web-template-v2 \
--machine-type=e2-medium \
--image-family=debian-12 \
--image-project=debian-cloud \
--tags=http-server
# Create a managed instance group from the template
gcloud compute instance-groups managed create web-mig \
--base-instance-name=web \
--template=web-template-v2 \
--size=2 \
--zone=us-central1-a
# Configure autoscaling to target 60% CPU utilization, between 2 and 10 instances
gcloud compute instance-groups managed set-autoscaling web-mig \
--zone=us-central1-a \
--max-num-replicas=10 \
--min-num-replicas=2 \
--target-cpu-utilization=0.6 \
--cool-down-period=90Regional Managed Instance Groups spread instances across multiple zones within a region automatically, so a single zone outage doesn't take down your entire fleet. Prefer regional MIGs over zonal MIGs for production workloads unless you have a specific reason to pin instances to one zone.
A short autoscaler cooldown period combined with a noisy metric (like instantaneous CPU spikes) can cause thrashing — the group repeatedly scales up and down, adding cost and destabilizing rolling updates. Tune the cooldown period and consider using a smoothed metric or scheduled scaling for predictable traffic patterns.
- Managed Instance Groups (MIGs) create identical VMs from one instance template and support autoscaling, auto-healing, and rolling updates.
- Unmanaged instance groups are just logical groupings for load balancing and lack automation — avoid them for production.
- Instance templates are immutable; updates require creating a new template version and rolling the MIG onto it.
- Autoscaling policies target signals like CPU utilization, load balancer capacity, or custom metrics, within configured min/max bounds.
- Auto-healing uses health checks to detect and replace broken instances automatically, distinct from load balancer health checks that only stop routing traffic.
- Regional MIGs distribute instances across zones for higher availability than zonal MIGs.
- Cooldown periods prevent autoscaler thrashing from short-lived metric spikes.
Practice what you learned
1. What is the key difference between a Managed and an Unmanaged Instance Group?
2. How do you update the configuration of instances in a MIG?
3. What does MIG auto-healing do that a load balancer's health check alone does not?
4. Why might you prefer a regional MIG over a zonal MIG for a production service?
5. What problem can a very short autoscaler cooldown period combined with a noisy metric cause?
Was this page helpful?
You May Also Like
Compute Engine Basics
Learn how Google Compute Engine provisions virtual machines, machine types, disks, and networking so you can run workloads on GCP infrastructure.
Google Kubernetes Engine Basics
Learn the fundamentals of GKE, Google's managed Kubernetes service, including clusters, nodes, workloads, and Autopilot mode.
Cloud Run Basics
Learn how Cloud Run runs stateless containers as fully managed, autoscaling, pay-per-request services on GCP.