Managed Instance Groups in GCP: Autohealing, Rolling Updates, and Scaling

Simple explanation

If you have never used a managed instance group before, here is the core idea:

• A MIG is a group of identical VMs, all created from one instance template.
• You tell the group how many VMs you want. GCP keeps that count maintained.
• If a VM becomes unhealthy or crashes, the group deletes it and creates a new one automatically.
• When you want to deploy an update, you create a new template version and the group replaces VMs gradually. Old ones go down, new ones come up.
• MIGs work best for stateless applications: web servers, API backends, background workers. Anything where it does not matter which specific VM handles a given request.

Why managed instance groups matter

Running VMs individually works fine for one or two machines. Once you have three or more doing the same job, managing them by hand creates real problems:

• Resilience: a single VM is a single point of failure. A MIG survives individual VM failures without any manual intervention.
• Repeatability: every VM starts from the same template, so there is no configuration drift between instances over time.
• Scaling: traffic spikes are handled by adding VMs, not by manually provisioning them under pressure.
• Safer deployments: rolling updates replace VMs one batch at a time, so a bad deployment does not take down your entire service at once.
• Less operational overhead: the group self-heals. You do not need to monitor for crashed VMs and recreate them by hand.

How managed instance groups work

The flow from initial setup to a running, self-healing fleet:

1. Create an instance template. The template defines machine type, OS image, disk size, network tags, service account, and startup script. Every VM in the group is created from this spec. See Instance Templates for the full guide.
2. Create the managed instance group. You specify the template, the desired number of VMs, and whether the group is zonal or regional.
3. GCP provisions the VMs. The group creates the requested number of VMs. Each one starts up, runs the startup script, and becomes available.
4. Attach a health check. The group polls each VM on a port and path you define. A VM that stops responding is marked unhealthy and replaced.
5. Optionally attach autoscaling. The group can grow and shrink automatically based on CPU utilisation, load balancer traffic metrics, or a schedule. See Autoscaling Instance Groups.
6. Deploy updates via a new template version. When you need to change the OS image, machine type, or startup script, create a new template and trigger a rolling update. The group replaces VMs in batches.
7. The group maintains desired state continuously. If a VM is deleted, fails a health check, or is preempted, the group creates a replacement from the current template.

Zonal vs regional managed instance groups

The most important decision when creating a MIG is whether it is zonal or regional. This determines your availability posture directly.

Creating a managed instance group

You need an instance template before creating a MIG. The commands below assume you already have one named web-server-template. For a walkthrough of creating your first VM and template from scratch, see Creating Your First VM.

# Create a zonal MIG with 3 VMs
gcloud compute instance-groups managed create web-mig \
  --template=web-server-template \
  --size=3 \
  --zone=us-central1-a

# Create a regional MIG spread across all zones in a region
gcloud compute instance-groups managed create web-mig-regional \
  --template=web-server-template \
  --size=6 \
  --region=us-central1

# Check VM status in the group
gcloud compute instance-groups managed list-instances web-mig \
  --zone=us-central1-a

For a regional MIG, GCP distributes VMs evenly across zones automatically. A group of 6 in us-central1 will typically place 2 VMs in each of the three zones.

Autohealing with health checks

Without a health check, the MIG only replaces VMs that crash at the hypervisor level. That misses a much more common failure mode: the VM is running but the application inside it is broken. A deadlocked process, an OOM-killed app, or a service that stalled during startup will all pass a basic liveness check while silently failing to serve requests.

Attaching an HTTP health check closes this gap. The MIG polls a specific port and path on each VM. If a VM stops responding correctly, the group deletes it and creates a replacement.

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

# Attach the health check to the MIG with an initial delay
gcloud compute instance-groups managed update web-mig \
  --zone=us-central1-a \
  --health-check=web-health-check \
  --initial-delay=60s

The —initial-delay=60s gives new VMs time to finish booting and starting the application before health checks begin evaluating them. Set it to comfortably exceed your application’s actual startup time.

Rolling updates

To deploy a new application version, create a new instance template with the updated configuration — new OS image, updated startup script, different machine type, whatever changed. Then trigger a rolling update to point the MIG at the new template.

The group replaces VMs in batches, not all at once. Two flags control the pace:

• max-unavailable: how many VMs can be down simultaneously during the rollout. Lower is safer but slower.
• max-surge: how many extra VMs above target size can be created temporarily during the rollout. Higher values speed up the rollout at additional cost.

# Start a rolling update to a new template
gcloud compute instance-groups managed rolling-action start-update web-mig \
  --zone=us-central1-a \
  --version=template=web-server-template-v2 \
  --max-unavailable=1 \
  --max-surge=1

# Watch the update status
gcloud compute instance-groups managed describe web-mig \
  --zone=us-central1-a

# Wait until the update is complete
gcloud compute instance-groups managed wait-until web-mig \
  --version-target-reached \
  --zone=us-central1-a

Manual resizing

When autoscaling is not attached, you can resize the group manually. For workloads with variable traffic, autoscaling is usually a better approach than adjusting size by hand.

# Scale up to 5 VMs
gcloud compute instance-groups managed resize web-mig \
  --size=5 \
  --zone=us-central1-a

# Scale down to 2 VMs
gcloud compute instance-groups managed resize web-mig \
  --size=2 \
  --zone=us-central1-a

When to use managed instance groups

MIGs are the right choice when you need a repeatable, self-healing fleet of VMs. Common use cases:

• Stateless web applications on Compute Engine: API servers, web frontends, reverse proxies that can run on any VM in the group.
• Backend services behind a load balancer: MIGs register directly with GCP external and internal load balancers, making horizontal scaling straightforward.
• Background workers and queue processors: fleets of VMs pulling tasks from Pub/Sub or Cloud Tasks, where individual VM failures are normal and expected.
• Cost-optimised fleets using Spot VMs: MIGs handle Spot VM preemptions automatically, making them practical for fault-tolerant workloads at 60–91% lower cost.
• Workloads that need VM-level control: specific OS configurations, custom kernel modules, or software that cannot run in a container.

When not to use them

• One-off or long-lived “pet” VMs: if you are running a single VM for a specific purpose with no intention to scale it, a standalone VM is simpler and more appropriate.
• Stateful workloads without careful design: use Cloud SQL, Filestore, or Cloud Storage for state, or look at stateful MIG policies for specific use cases.
• Container-native applications: if you are already building with containers, Cloud Run or GKE are better fits and require less infrastructure management. See Cloud Run vs Compute Engine for a direct comparison.

Managed instance groups vs single VMs

GCP also has unmanaged instance groups, which let you group arbitrary existing VMs together for load balancing purposes. They have no autohealing, no rolling updates, and no autoscaling. They exist mainly for legacy use cases where VMs cannot all be identical. For new infrastructure, use managed instance groups.