Instance Templates & Managed Instance Groups
The pattern for scalable, self-healing fleets of identical VMs.
Instance templates
- Immutable blueprint: machine type, image, disks, network, tags, metadata, startup script.
- Cannot be edited - to change, create a new template (or roll one out to a MIG).
- Required to create a managed instance group.
Managed vs. unmanaged groups
- Managed Instance Group (MIG) - built from a template; all VMs identical. Gives autoscaling, auto-healing, rolling updates, regional distribution, load-balancer integration (via optional named-port mappings).
- Unmanaged group - a bag of pre-existing, possibly dissimilar VMs. No autoscaling/auto-healing. Rarely the exam answer - only for legacy heterogeneous VMs behind a load balancer.
Stateless vs. stateful MIGs
- Stateless - no per-VM state to preserve; any VM is interchangeable. Website front ends, image/queue processing, batch workers. The common case.
- Stateful - a VM keeps identity or disk data that must survive recreation/updates (stateful config: per-instance disks, IPs, metadata). Databases, legacy apps.
Zonal vs. regional MIG
- Regional MIG spreads instances across multiple zones in a region - survives a zone outage. Preferred for HA (recommended default).
- Zonal MIG lives in a single zone.
Autoscaling
- Scale on: CPU utilization, load-balancing capacity, Cloud Monitoring metrics, a queue-based workload (Pub/Sub), or a schedule (start time, duration, recurrence).
- Set min and max replicas; a cool-down period avoids thrashing after a new VM boots.
- You define the policy; the autoscaler adds/removes instances automatically from the measured load, keeping the group average below the target.
- Monitor a group (or a single VM) from its Observability/Monitoring tab: CPU over the last hour by default, plus disk and network. Use these graphs to size the policy, and set Cloud Monitoring alerts on utilization.
Auto-healing & health checks
- Auto-healing recreates a VM that fails an application health check (not just the VM being up).
- A VM that stops, crashes, or is deleted outside the group's own commands is recreated with the same name and the same template.
- Uses a separate health check with an initial delay so a slow-booting app isn't killed during startup.
- A health check needs a protocol, port, and health criteria; Google Cloud then computes a health state per instance. It is essentially an uptime check for the group.
- Check interval - how often to probe (e.g. every 5s).
- Timeout - how long to wait for a response.
- Healthy threshold - consecutive successes before an instance counts as healthy.
- Unhealthy threshold - consecutive failures before it counts as unhealthy.
With a 5s interval and an unhealthy threshold of 2, an instance must fail two checks - a span of 15 seconds - before it is marked unhealthy:
The auto-healing health check (recreates unhealthy VMs) is separate from the load balancer health check (routes traffic away). They can differ. Also: don't set the initial delay too short or healthy-but-still-booting VMs get killed in a loop.
You can't edit a template in place. To change instance config, create a new template and do a rolling update (--max-surge, --max-unavailable) or canary to the MIG.
Stateful IP addresses
A stateful policy preserves each VM's IP across autohealing, update, and recreation events, so the VM keeps the same address. Both internal and external IPv4 addresses can be preserved, assigned automatically or pinned per instance.
- Application needs its IP to stay static once assigned, or its config depends on specific IPs.
- Clients (users or other apps) reach the server through a dedicated static IP.
- Migrating existing workloads without changing network configuration.
Setting a stateful IP config on an existing MIG promotes the ephemeral IPs of current instances to static and applies to future instances too.