6.2 Managed Instance Groups, Instance Templates & Autoscaling

Why This Topic Matters

The exam guide's second Compute Engine bullet is explicit: "Creating an autoscaled managed instance group by using an instance template." This is the standard pattern for running a resilient, horizontally scalable fleet of identical VMs on Google Cloud, and it shows up constantly in ACE scenarios about web tiers, worker fleets, and anything described as needing to "automatically handle traffic spikes" or "survive a zone failure."

Instance Templates: The Blueprint

An instance template is an immutable configuration object that defines everything needed to create a VM: machine type, boot disk image, additional disks, network tags, labels, metadata (including startup scripts), and the service account the instance runs as. Templates can be global (usable by MIGs in any region) or regional (restricted to one region, useful when you reference region-specific resources like a regional disk). Because templates are immutable, you cannot edit one in place -- to change the VM configuration, you create a new template version and roll it out to the group.

Managed Instance Groups (MIGs)

A managed instance group uses an instance template to create and maintain a set of identical VM instances, and is the mechanism GCP uses for both horizontal scaling and self-healing fleets.

For production traffic, regional MIGs are the default recommended choice -- an entire zone can go down and the group keeps serving from the other zones. Within a MIG, instances are normally stateless (any instance can be destroyed and replaced without consequence), but a stateful MIG preserves per-instance configuration -- attached stateful disks, hostname, and specific metadata -- across recreation, which is appropriate for singleton or quasi-stateful services (e.g., a licensed application tied to a specific hostname) that still benefit from autohealing.

Autoscaling Signals

An autoscaling policy can combine multiple signals; when more than one is configured, Compute Engine calculates a recommended group size for each signal and scales to the largest of those recommendations.

Predictive autoscaling deserves special attention: it works only with the CPU utilization signal, needs a minimum of 3 days of CPU-based autoscaling history before Compute Engine can generate forecasts, and uses an initialization period (e.g., 300 seconds) to tell the autoscaler how far in advance to scale out so new instances are warm before predicted load arrives. It cannot be combined with the load-balancing-capacity signal.

Health Checks and Autohealing

A MIG can attach a health check so that Compute Engine automatically recreates instances that fail it -- this is autohealing, distinct from the load balancer's own health check (which just routes traffic away from unhealthy backends). An initial delay setting gives a newly created instance time to boot and start serving before autohealing starts evaluating it, preventing a slow-starting app from being caught in a destroy-recreate loop.

Rolling Updates

Because instance templates are immutable, deploying a new application version means creating a new template version and triggering a rolling update on the MIG, controlled by max surge (how many extra instances can be created above the target size during the rollout) and max unavailable (how many instances can be offline at once). Updates can be proactive (Compute Engine actively replaces instances right away) or opportunistic (only replaced when Compute Engine would recreate them anyway, e.g., due to autoscaling or autohealing) -- opportunistic is the lower-risk choice when you want a change to roll out gradually as natural churn happens rather than all at once. The replacement method also matters: RECREATE deletes and recreates the instance (a new VM, new boot disk from the template), while RESTART only reboots existing instances in place, which is only valid when the underlying template change does not require a new VM (for example, a metadata-only change). A MIG can also run a canary update by applying a new template version to only a percentage of the group first, verifying health, and then rolling the rest forward -- the standard answer whenever a scenario asks for a low-risk way to validate a new version before a full fleet rollout.

Cooldown Period

Every autoscaled MIG has a configurable cooldown period (default 60 seconds) during which the autoscaler ignores a newly created instance's metrics -- giving the instance time to initialize and start serving real traffic before it factors into the next scaling decision. Setting the cooldown too short can cause the autoscaler to over-scale in response to a warm-up spike; setting it far longer than the application's actual startup time delays legitimate scale-out reactions.

Worked Scenario

An e-commerce site expects a predictable traffic surge every day at noon and unpredictable spikes during flash sales. The right design: a regional MIG (survives a zone outage) built from an instance template with the current app version baked into the boot disk, an autoscaling policy combining a schedule-based signal for the predictable noon surge and a load-balancing-capacity signal for the unpredictable flash-sale spikes, plus a health check for autohealing. When the team ships a new app version, they publish a new template and run a rolling update with a modest max-surge so capacity never dips during the rollout.