Tuning autoscaling for cost: the settings that waste the most money

Quick answer

Tune five settings in order. 1) Minimum capacity, which sets the floor you pay 24/7 and is almost always higher than needed: cutting a minimum of 10 to 4 on m5.large saves about $420 a month. 2) Scale down thresholds and cooldowns, since a 15 minute cooldown after every scale down step means capacity lingers for hours. 3) Target utilisation, where moving from 40 to 65 percent CPU cuts steady fleet size by roughly a third. 4) Scale down step size, which should be gradual but not glacial. 5) Scheduled scaling for predictable patterns, which beats reactive scaling on both cost and latency. Expect 20 to 40 percent off autoscaled fleets.

Autoscaling is supposed to mean you pay for what you use. In practice most autoscaling groups are tuned once at launch, with settings chosen for confidence rather than measurement, and then never revisited. The result is a system that scales up eagerly, scales down reluctantly, and never goes below a floor somebody picked from intuition.

The five settings ranked by money wasted

Setting	Common error	Cost impact
Minimum capacity	Set too high for comfort	Highest, paid 24/7
Scale down cooldown	Too long, capacity lingers	High
Target utilisation	Too conservative, 30 to 40%	High
Scale down step	One instance at a time	Medium
Scheduled scaling	Not used at all	Medium

Setting 1: the minimum is the bill you always pay

Minimum capacity is the single most expensive autoscaling setting because you pay it every hour of every day, including the hours when nothing is happening. It is also the setting chosen with the least data, typically a round number that felt safe during the launch.

Find the true floor by looking at actual capacity used during your quietest hour across 30 days, then add enough headroom to absorb a sudden spike while new capacity starts. On an m5.large at $0.096 per hour, dropping a minimum from 10 to 4 saves about $420 a month per group. Across twenty groups that is $8,400 a month for a configuration change.

The constraint to respect is startup time. If an instance takes six minutes to become healthy and your traffic can triple in two, the minimum must cover that ramp. The fix for slow startup is not extra idle capacity, it is faster startup: pre baked images, warmed caches, and lighter init.

Setting 2: cooldowns that hold capacity for hours

A scale down cooldown of 300 seconds after each step means removing six instances takes 30 minutes even after demand has collapsed. Combine that with a scale down threshold set well below the scale up threshold and capacity can persist for hours past the point it was needed.

The asymmetry is justified, scaling down too aggressively causes thrashing, but most configurations overcorrect. A reasonable shape is a short scale up cooldown (60 seconds or less, since responsiveness matters most here), a moderate scale down cooldown (180 to 300 seconds), and a scale down step that removes multiple instances at once when utilisation is far below target rather than one at a time.

Setting 3: target utilisation

A target of 40 percent CPU means the fleet is sized so average utilisation stays at 40 percent, which is another way of saying 60 percent of the fleet is headroom. Moving the target to 65 percent cuts the steady state fleet size by roughly a third, and on a 30 instance fleet of m5.xlarge at $0.192 per hour that is about $1,400 a month.

Whether you can is a latency question, not a cost one. Queueing theory is unkind near saturation: response time rises sharply above about 70 to 80 percent utilisation for most request driven services. So 65 percent is usually safe, 80 percent is usually not, and the correct answer depends on your traffic burstiness and p99 requirements. Test it: raise the target one step, watch p99 latency for a week, repeat. The trade off is the subject of autoscaling cost versus performance.

Setting 4: predictable patterns deserve scheduled scaling

Reactive autoscaling responds after demand arrives, which means a lag during which either latency suffers or you keep extra capacity to cover it. For traffic that is predictable, and most business traffic is highly predictable by hour and day, scheduled scaling sets capacity ahead of the curve.

Scale up at 8am before the morning ramp and down at 7pm after it falls, and the reactive policy only handles the deviation from the expected pattern. This is both cheaper and better for latency, which is unusual. For non-production the extreme version is scaling to zero outside working hours, which removes about 70 percent of runtime.

Setting 5: Kubernetes specific tuning

On Kubernetes the equivalent levers differ. The cluster autoscaler scales nodes based on pending pods, so the binding constraint is pod resource requests, not usage: a cluster full of pods requesting four times what they use will provision nodes it does not need. Fix requests first. Then check the scale down utilisation threshold, commonly defaulted to 50 percent, and the scale down delay after add, commonly 10 minutes, both of which keep nodes alive longer than necessary. Pod disruption budgets that are too strict can also block node removal entirely, which is a common reason a cluster never scales down.

Expected outcome

Tuning all five typically removes 20 to 40 percent from an autoscaled fleet's cost. On a $50,000 a month autoscaled compute base that is $10,000 to $20,000. Change one setting at a time with a week of observation, because changing minimum, target, and cooldown together leaves you unable to attribute a latency regression. Then keep the settings in Terraform and price scaling configuration changes against the resource catalog so a minimum raised during an incident gets revisited rather than becoming permanent.

FAQ

Which autoscaling setting wastes the most money?

Minimum capacity, because you pay it every hour of every day including the quiet ones, and it is usually a round number chosen for comfort at launch rather than from data. On an m5.large at $0.096 per hour, dropping a minimum from 10 to 4 saves about $420 a month per group. Across twenty groups that is $8,400 a month from a configuration change.

How do I find the right minimum capacity?

Look at actual capacity used during your quietest hour across 30 days, then add enough headroom to absorb a sudden spike while new capacity starts. The binding constraint is startup time: if an instance takes six minutes to become healthy and traffic can triple in two, the minimum must cover that ramp. The better fix is faster startup through pre baked images and lighter init.

What target utilisation should autoscaling use?

Usually around 65 percent CPU for request driven services. A target of 40 percent means 60 percent of the fleet is headroom; moving to 65 percent cuts steady state fleet size by roughly a third, about $1,400 a month on a 30 instance m5.xlarge fleet. Above roughly 70 to 80 percent, response time rises sharply, so raise the target one step at a time and watch p99 latency for a week.

Why does my fleet not scale down quickly?

Cooldowns and step size. A 300 second scale down cooldown after each step means removing six instances takes 30 minutes even after demand collapsed, and a scale down threshold set far below the scale up threshold makes capacity persist for hours. Use a short scale up cooldown, a moderate scale down cooldown, and a step that removes several instances at once when utilisation is far below target.

Is scheduled scaling better than reactive scaling?

For predictable traffic, yes, on both cost and latency, which is unusual for a cost lever. Reactive scaling responds after demand arrives, so you either accept a latency lag or hold extra capacity to cover it. Scaling up at 8am before the morning ramp and down at 7pm after it falls leaves the reactive policy handling only deviation from the expected pattern.

Why does my Kubernetes cluster never scale down?

Usually one of three causes. Pod resource requests far above actual usage, since the cluster autoscaler provisions against requests not usage. Default settings that keep nodes alive longer than needed, such as a 50 percent scale down utilisation threshold and a 10 minute scale down delay after add. Or pod disruption budgets strict enough to block node removal entirely.

What to do next

Keep scaling settings in code and priced. C3X costs Terraform changes against a live resource catalog. Start with the quickstart.