# MIG Autoscaler Not Configured

> Managed instance groups with autoscalerEnabled explicitly false are detected, yet the rule permanently abstains by design: a MIG's cost sits at $0 in the aggregator because spend is billed on member VMs individually, and attaching a synthetic group cost would double-count the fleet's dollars.

Source: https://zop.dev/integrations/gcp/recommendations/mig-autoscaler-not-configured
Updated: 2026-08-19

---

## An authoritative false on autoscalerEnabled

- resource.Status: not terminated
- resource.Metadata: autoscalerEnabled=="false" (producer enrichGCPMIG derives it from status.autoscaler, writing meta[autoscalerEnabled]="true"/"false"). Fires only on an authoritative "false"; absent/unknown fails safe (item T0348). The prior gate Tags[autoscaler]=="true" was a key no producer emits, so with empty GCP Tags it fired on every MIG (universal false-positive). Eval row corrected PRODUCER_EMITS_KEY(autoscaler)→ATTR_FIELD(autoscalerEnabled;Metadata).
- Not registered in internal/rules/registry.go, and that is intentional rather than a deferred wiring gap. Evaluate() is a permanent v1 abstain tombstone (see Cost calculation below): registering an always-nil rule would only add per-resource CPU with zero output, so it is deliberately left out of the GCP Compute section, mirroring the RC-189/RC-171/RC-265 "documented, intentionally not registered" convention.

## Why a calcFree MIG would double-count

Permanent v1-abstain by design (always returns nil). Category is now the cost-driven rightsizing (attaching an autoscaler so the MIG scales down is a bill-reducing lever, and it must not be mislabeled to a non-cost category to ship $0 past shouldDropLowSavings). But the MIG is calcFree in the aggregator (mig not in HasOwnCostWithChildren, mirroring "asg": calcFree). Its spend is borne by member compute (VM) rows costed individually, so r.pricing[mig-uid] is structurally $0. Wiring a synthetic group-level cost to make this fire would double-count the fleet (the dollars already sit on the member VMs), and the scale-down saving belongs to the members, not the group. Per concrete-or-abstain the rule abstains permanently rather than emit a $0 or double-counted number. (Was previously documented as a $0 compliance rec; reworked under the 2026-06-27 directive, which says not to naively wire a group-level cost producer.) This does not mirror azure/vmss_no_autoscale.go (RC-ASC-002): that sibling is registered and fires on real data because VMSS carries its own aggregator cost, whereas the GCP MIG is calcFree. That asymmetry, not RC-ASC-002 parity, drives this permanent abstain.

## Turning autoscaling on for the group

1. Navigate to Compute Engine > Instance groups in the GCP Console
2. Select the managed instance group
3. Click Configure autoscaling
4. Set autoscaling mode to 'On: add and remove instances'
5. Configure target CPU utilization (recommended: 70%)
6. Set appropriate minimum and maximum number of instances
7. Set cool-down period (recommended: 300 seconds)