Autoscaling Is the One Config Surface With Two Writers and No Merge

A writeup on dev.to about adopting autoscaling config you did not write names the mechanism more precisely than most drift discussions manage: across ECS, ASG, VMSS and MIG, the scaling policy is its own object, with multiple possible writers and last-writer-wins semantics ^[1]. Nothing merges and nothing warns, which means the real scaling behavior of production can change with no deploy, no PR and no alert ^[1][5].

The specifics differ by platform only in blast radius. On AWS, ASG scaling policies and the Application Auto Scaling targets and policies behind ECS services are separate API objects; if Terraform or CloudFormation declares them, the next apply silently reverts every console tweak made since, including the incident-era threshold that turned out to be load-bearing ^[3]. The inverse is equally common: a policy created by hand in the console is invisible to the code, survives right up until someone cleans up drift, and then disappears ^[4]. Azure VMSS autoscale is a single autoscaleSettings resource containing profiles and rules, so portal edits modify it in place and the next ARM, Bicep or Terraform deployment that also defines it replaces the whole object; you do not lose one rule, you lose the entire tuned profile set at once ^[6]. On GCP, the MIG autoscaler is likewise its own attached object, gcloud edits and Terraform definitions overwrite each other whole, and a MIG that gets deleted and recreated comes back with whatever the code says rather than what the console said ^[7].

The ordering advice in the piece is the part worth stealing. Inventory from the API rather than from the repo, using describe-policies and describe-scaling-policies on AWS, az monitor autoscale list, and gcloud compute instance-groups managed list ^[8]. Then freeze before fixing: pick one source of truth, almost always the IaC, import the live policy objects verbatim including the warts, and diff until plan shows zero changes, so the first apply after adoption is a no-op ^[9]. Tuning while two writers still exist is the mistake that produces the next inherited mess.

Only once there is one honest copy do the smells become checkable, and the source lists six that inherited policies reliably contain: cooldowns under 120 seconds, which make the group oscillate on its own noise ^[10]; targets above 90 percent, where new capacity arrives after the damage and the policy functions as a post-incident notification system ^[11]; targets below 30 percent, which is permanent over-provisioning in an autoscaling costume ^[12]; min equal to max, which is a fixed fleet with extra steps ^[13]; no policy at all on a group everyone assumed had one ^[14]; and step policies stacked on target tracking against the same metric, two controllers on one wheel ^[15]. The usable target band implied by those two thresholds is 60 percentage points wide, which is a lot of room to be wrong inside ^[19].

Enforcement is the cheap half. CloudTrail records PutScalingPolicy and PutAutoScalingPolicy, Azure activity logs and GCP audit logs record their equivalents, so an alert on policy-write events whose principal is not the deploy pipeline converts the next silent overwrite into a loud one ^[16]. Incident-time tuning still works; it just arrives with a follow-up task to codify or revert instead of becoming un-owned state ^[17].

Watch two signals. The first plan after import should show zero changes, and if it does not, the import is not finished ^[9]. After that, watch for policy writes attributed to a human principal ^[16], and treat any tuning that changes target, cooldown and max in one apply as a lost experiment rather than a fix ^[18].