Every team eventually inherits autoscaling configuration it didn't write. The author left, the Terraform was half-applied, someone tuned a threshold in the console during an incident two years ago, and now the scaling behavior of production is defined by an unknowable merge of code, clicks, and defaults. Everyone is afraid to touch it, which is exactly how it stays wrong.
The technical trap that makes inherited autoscaling worse than other inherited config is the silent overwrite: autoscaling policies are one of the few places where two writers routinely fight without either noticing.
The silent overwrite, per platform
AWS ASGs and ECS services. Scaling policies live as their own API objects (ASG scaling policies; Application Auto Scaling targets and policies for ECS). If Terraform or CloudFormation defines them, the next apply reverts every console tweak made since, silently, including the incident-era threshold change that was load-bearing. The reverse also happens: policies created by hand in the console are invisible to the code, survive until someone "cleans up drift", and vanish. Either way, the system's real behavior changes with no deploy, no PR, and no alert.
Azure VMSS. Autoscale is a separate autoscaleSettings resource attached to the scale set, with profiles and rules inside it. Portal edits modify that resource in place; the next ARM/Bicep/Terraform deployment that also defines it replaces the whole object, profiles and all. Because it's one resource, you don't lose a rule; you lose the entire tuned profile set at once.
