1. Autoscaling Principles
Scale-out (horizontal) adds instances — preferred for stateless workloads and cloud-native designs. Scale-up (vertical) increases instance size — useful for databases or legacy apps that can't distribute load.
Reactive scaling responds to real-time metrics (CPU spikes, queue depth). Predictive scaling (available in VMSS) uses ML on historical patterns to pre-provision capacity before demand hits.
2. Metric-Based & Schedule-Based Scaling
Common Metrics
- CPU / Memory % — standard compute pressure signals
- Queue depth — messages waiting (Service Bus, Storage Queue)
- HTTP request count / latency — application-level signals
- Custom metrics — Application Insights or Azure Monitor custom telemetry
Schedule-Based Scaling
Pre-scale for known patterns: business hours, batch windows, campaign launches. Combine with metric rules — schedule sets the floor, metrics handle bursts above it.
3. Scale-In Policies & Flapping Prevention
- Cooldown period — minimum time between scale actions (default 5 min for VMSS). Prevents oscillation.
- Scale-in policy — choose which instance to remove: Default (balance AZs), NewestVM, OldestVM.
- Instance protection — mark VMs that should never be removed (long-running jobs).
- Gradual scale-in — remove one instance at a time; re-evaluate before removing more.
4. Autoscale Decision Flow
5. Scaling Mechanisms Compared
| Feature | VMSS Autoscale | App Service Autoscale | AKS HPA / KEDA |
|---|---|---|---|
| Unit of Scale | VM instances | App Service instances | Pod replicas (+ node autoscaler) |
| Metric Sources | Azure Monitor, custom | Azure Monitor, custom | Metrics Server, Prometheus, external (KEDA) |
| Predictive Scaling | ✅ ML-based | ❌ | ❌ (use CronJob scaler in KEDA) |
| Scale-to-Zero | Min = 0 possible | ❌ (min 1) | ✅ with KEDA |
| Cooldown | Configurable (default 5 min) | Configurable | stabilizationWindowSeconds |
| Best For | IaaS workloads, lift-and-shift | Web apps, APIs | Microservices, event-driven |
6. Performance Anti-Patterns
- Noisy Neighbor — shared resources (App Service Plan, SQL elastic pool) where one tenant starves others. Fix: isolate or use resource governance.
- Connection Pool Exhaustion — new instances open connections but old ones aren't released. Fix: use connection pooling middleware, limit max connections, implement retry with backoff.
- Cold Cache After Scale — new instances have empty caches, causing a thundering herd to the database. Fix: cache warming, gradual traffic shift, read replicas.
- Scaling the wrong tier — adding web servers when the bottleneck is database IOPS. Fix: identify the true bottleneck with distributed tracing before scaling.
7. Real-World: Designing Autoscale for Black Friday Traffic
Scenario: An e-commerce platform expects 10× normal traffic on Black Friday. Historical data shows a ramp starting at 6 AM.
Design:
- Schedule-based rule pre-scales App Service to 8 instances at 5:30 AM (warm caches).
- Metric rule adds instances when CPU > 70% for 5 min (handles unexpected surges).
- KEDA scales order-processing pods based on Service Bus queue depth.
- Cosmos DB autoscale set to 10× normal RU/s max; burst handled by serverless throughput.
- Cooldown set to 10 min on scale-in to prevent premature shrinkage during traffic lulls.
- Post-event: review metrics, adjust predictive model for next year.
8. Exam Tip
🎯 AZ-305 often tests whether you pick scale-out + schedule vs scale-up. Choose scale-out for stateless services; choose scale-up only when the workload can't be distributed (e.g., single-instance legacy DB). Know that KEDA enables scale-to-zero — important for cost optimization questions.