Autoscaling adjusts the number of running instances of a service based on metrics such as CPU use, request rate, or queue length. When demand rises, new instances start; when it falls, extras are removed.
Why it matters
Fixed capacity is either wasteful or fragile: sized for the peak it sits idle most days, sized for the average it fails during a spike. Autoscaling aims to keep response times steady while paying only for what you use. It is a core part of horizontal scaling.
Example
A policy might read: add 2 instances when average CPU stays above 70 percent for 3 minutes, remove 1 when it stays below 30 percent for 15 minutes, with a minimum of 3 and a maximum of 20 instances. Removal is deliberately slower than addition, to avoid flapping.
The main limits are timing and dependencies. A new instance can take one to several minutes to boot, pass health checks, and warm its caches. A sudden spike can overwhelm the existing fleet before help arrives, so keep a buffer or pre-scale before known events such as a sale. Scaling the web tier also does nothing if the single database behind it is the bottleneck.
Common mistakes
- Scaling on CPU when the real constraint is memory, connections, or queue backlog.
- No upper limit, which turns a bot attack or retry loop into a huge bill.
- Ignoring cold starts and warm-up time.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.