> Autoscaling strategies are often traditionally hand-coded to depend on the costs associated of not completing transactions or site going down from a business

> Autoscaling strategies are often traditionally hand-coded to depend on the costs associated of not completing transactions or site going down from a business impact analysis (BIA). Adding on this, my current thinking is that it would be possible to better surface this tradeoff by modeling autoscaling as an inventory problem. There's a stockout cost and a holding cost; for a given probability of hitting a cold start and for a given cold start lag, it should be possible to compute the optimal instances on-hand. Then there are, as you point out, many special business rules. Where I work we have a pool system for testing environments. It works reasonably well until a particular team, sitting upstream of approximately half the company, makes a release. Then suddenly everyone's pipelines kick off simultaneously. So now they have a system which watches for signs of impending release and pre-emptively scales up. Autoscaling should not be your first line or final line of defence. It is a powerful tool, not a magic wand.