Auto Scaling
Also Known As
horizontal scaling
scale out
ASG
auto scaling group
TL;DR
Automatically adding or removing compute instances based on load metrics — ensuring capacity matches demand without over-provisioning or under-provisioning.
Explanation
Horizontal scaling adds/removes instances; vertical scaling changes instance size. Auto scaling groups (AWS ASG, GCE managed instance groups) scale horizontally based on CloudWatch metrics (CPU, request rate, queue depth). Scale-out policies add capacity when metrics exceed thresholds; scale-in policies remove capacity when load drops. Cooldown periods prevent oscillation. For PHP-FPM, scaling means adding more servers — each request is stateless, so any server can handle any request.
Diagram
flowchart TD
MON[CloudWatch<br/>Metrics] -->|CPU > 70%| SCALE_OUT[Scale Out<br/>Add instances]
MON -->|CPU < 20%| SCALE_IN[Scale In<br/>Remove instances]
subgraph Auto Scaling Group
S1[Instance 1]
S2[Instance 2]
S3[Instance 3 - new]
end
LB[Load Balancer] --> S1 & S2
SCALE_OUT --> S3
LB --> S3
SESS[(Redis Sessions<br/>Shared)] -.->|stateless app| S1 & S2 & S3
style S3 fill:#238636,color:#fff
style SESS fill:#1f6feb,color:#fff
Common Misconception
✗ More instances always solves performance problems — if the bottleneck is the database, adding application servers only increases DB connection pressure.
Why It Matters
Auto scaling handles traffic spikes automatically — without it, you either over-provision (expensive at idle) or under-provision (outage at peak).
Common Mistakes
- Scaling on CPU alone — request rate or queue depth is often a better signal for PHP-FPM workloads.
- No scale-in protection for instances processing long-running jobs — scale-in terminates them mid-job.
- Sessions stored on individual instances — scale-in removes the instance and all its sessions; use Redis for session storage.
- No warm-up period — new instances need time to compile opcache before handling production traffic.
Code Examples
✗ Vulnerable
# Sticky sessions on application servers — blocks scale-in:
# nginx upstream:
upstream app {
ip_hash; # Sticky sessions — user X always goes to server 1
server app1:80;
server app2:80;
}
# Scale-in removes app1 — all of app1's sessions lost
✓ Fixed
# Stateless app servers + Redis sessions = scale freely:
# php.ini / app config:
session.save_handler = redis
session.save_path = 'tcp://redis.internal:6379'
# nginx — no sticky sessions needed:
upstream app {
least_conn; # Route to least busy server
server app1:80;
server app2:80;
}
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
25
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Perplexity 7
Amazonbot 6
Google 4
Unknown AI 2
Ahrefs 2
SEMrush 1
Also referenced
How they use it
crawler 19
crawler_json 3
Related categories
⚡
DEV INTEL
Tools & Severity
🟡 Medium
⚙ Fix effort: Medium
⚡ Quick Fix
Configure HPA on CPU >60% and custom PHP-FPM queue depth metric — scale before workers are saturated, not after; set scaleDown stabilisation window to 5 minutes to avoid flapping
📦 Applies To
PHP 5.0+
web
queue-worker
🔗 Prerequisites
🔍 Detection Hints
Fixed instance count not auto-scaling; PHP workers maxed during traffic spikes causing 502s; over-provisioned idle capacity
Auto-detectable:
✗ No
kubernetes
aws-asg
cloudwatch
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: Medium
✗ Manual fix
Fix: High
Context: File