Auto-scaling automatically adjusts the number of compute instances or containers in response to demand, keeping performance stable without manual capacity planning.
Auto-scaling uses metrics such as CPU utilization, request rate, queue depth, or custom application signals to add or remove instances. Horizontal scaling changes instance count. Vertical scaling changes instance size. Scheduled scaling handles predictable load patterns.
That automation removes the brittle practice of capacity planning around peak load alone. Systems can absorb traffic spikes without overprovisioning during quiet periods. The challenge is choosing the right metric, cooldown period, and scaling limits because slow metrics cause lagged reactions and aggressive scaling can oscillate or overspend.
Think of it like this. Think of a restaurant that calls in extra staff when the dining room fills up and sends people home when it empties, instead of staffing for the busiest night of the year.
Monitoring collects signals such as CPU, memory, request latency, or queue length. Scaling policies define thresholds, step sizes, minimums, maximums, and cooldown windows. When metrics cross a threshold, the controller adds or removes instances. Kubernetes HPA scales pods; cloud autoscalers scale VMs or serverless capacity.
"CPU is the only metric needed." Request rate, latency, and queue depth often matter more. "Scaling out fixes everything." Vertical sizing and application efficiency are still relevant. "Zero minimum is free." Scaling to zero introduces cold-start latency and may break downstream assumptions.
Improves cost efficiency and availability, but requires careful metric selection and tuning. Aggressive policies can thrash; conservative policies lag behind demand.