Autoscaling Plan Template for Engineering Teams

Horizontal autoscaling (HPA in Kubernetes) adds or removes instances. Vertical autoscaling (VPA) changes the CPU and memory allocated to existing instances. Use horizontal scaling for stateless services (web APIs, workers). Use vertical scaling for stateful workloads where adding instances is complex (databases, single-leader caches). Most teams start with horizontal because it is simpler and more predictable.

Set three guardrails: maximum instance count per service, monthly spend alerts in your cloud provider, and weekly cost reviews. The maximum instance count is the most important because it caps the worst case. A service with max 15 pods at $0.15/hr cannot exceed $1,642/month regardless of traffic.

Start with 60 seconds for scale-up and 300 seconds (5 minutes) for scale-down. The scale-up cooldown should be short enough that a second scaling event can fire if the first was insufficient. The scale-down cooldown should be long enough that a brief dip in traffic does not trigger premature removal of instances.

Use a load testing tool (k6, Locust, Artillery) to simulate expected launch traffic at 2x, 5x, and 10x normal peak. Monitor how quickly new instances come online, whether they pass health checks before receiving traffic, and whether the system stabilizes without oscillation. Run the test in a staging environment with the same autoscaling configuration as production.

PMs should understand the cost and reliability trade-offs but not configure the policies. When engineering proposes a max instance count, the PM should ask what happens if traffic exceeds that cap. When costs increase after a policy change, the PM should understand whether the spend is justified by user experience improvements. Include infrastructure cost changes in quarterly business reviews.