MIG Autoscaler Not Configured
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-ASC-003 |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | mig_no_autoscaler.go |
Where it applies
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
- Navigate to Compute Engine > Instance groups in the GCP Console
- Select the managed instance group
- Click Configure autoscaling
- Set autoscaling mode to ‘On: add and remove instances’
- Configure target CPU utilization (recommended: 70%)
- Set appropriate minimum and maximum number of instances
- Set cool-down period (recommended: 300 seconds)