App Service Scaling Behaviour: Scale Up, Scale Out, and Autoscale

Scale up versus scale out

Scale up means changing the App Service Plan to a higher tier with more CPU and RAM per instance — for example, moving from S1 (1 vCPU, 1.75 GB RAM) to S2 (2 vCPU, 3.5 GB RAM). All apps in the plan move to the new instance size. This requires a brief restart of all running apps in the plan. Use scale up when a single request is CPU or memory intensive and cannot be parallelised — rendering a large document, running a complex query, or compiling code.

Scale out adds more instances at the current tier. Traffic is spread across all instances by the load balancer. Your application receives more simultaneous capacity without any change to per-request processing power. Scale out is the right response to higher request volume — more users, more concurrent requests.

Most web traffic problems are solved by scaling out, not up. If your S1 plan is at 80% CPU across one instance, adding a second S1 instance cuts load in half without requiring a restart or a tier change.

Manual scaling

All App Service Plan tiers support manual scaling — setting the instance count directly:

# Scale to 3 instances manually
az appservice plan update \
  --resource-group my-rg \
  --name my-app-plan \
  --number-of-workers 3

Manual scaling is appropriate when you know a traffic event is coming and want to pre-warm instances. For example, before a product launch or a scheduled marketing campaign, scale to 5 instances an hour before the event, then scale back down manually afterward.

Configuring autoscale

Autoscaling requires Standard tier or above. Configure it through Azure Monitor autoscale, which applies to the App Service Plan (not individual apps in the plan):

# Enable autoscaling on the App Service Plan
az monitor autoscale create \
  --resource-group my-rg \
  --resource my-app-plan \
  --resource-type Microsoft.Web/serverfarms \
  --name my-app-autoscale \
  --min-count 1 \
  --max-count 10 \
  --count 2

# Scale out: add 1 instance when average CPU > 70% for 10 minutes
az monitor autoscale rule create \
  --resource-group my-rg \
  --autoscale-name my-app-autoscale \
  --condition "CpuPercentage > 70 avg 10m" \
  --scale out 1 \
  --cooldown 10

# Scale in: remove 1 instance when average CPU < 30% for 15 minutes
az monitor autoscale rule create \
  --resource-group my-rg \
  --autoscale-name my-app-autoscale \
  --condition "CpuPercentage < 30 avg 15m" \
  --scale in 1 \
  --cooldown 15

The cooldown period prevents rapid oscillation. After a scale-out event, autoscale waits 10 minutes before evaluating scale-out rules again. This avoids adding an instance, then immediately adding another because the metric has not had time to improve.

Scaling on HTTP queue length

CPU is a useful scaling signal but has a lag — requests pile up in the HTTP queue before CPU rises noticeably. Scaling on HTTP queue length reacts faster to traffic spikes:

# Scale out when HTTP queue length exceeds 20 requests
az monitor autoscale rule create \
  --resource-group my-rg \
  --autoscale-name my-app-autoscale \
  --condition "HttpQueueLength > 20 avg 5m" \
  --scale out 2 \
  --cooldown 5

HttpQueueLength is the number of requests waiting for an instance to become available. A queue building up means your instances are saturated. Scaling out on queue length adds capacity before users experience noticeable latency increases, since the queue fills before CPU rises significantly.

Scheduled scaling profiles

If you have predictable traffic patterns, scheduled profiles avoid scaling lag entirely by pre-warming instances before the peak:

# Run with 4 instances during business hours, scale down overnight
az monitor autoscale profile create \
  --resource-group my-rg \
  --autoscale-name my-app-autoscale \
  --name business-hours \
  --min-count 4 \
  --max-count 10 \
  --count 4 \
  --recurrence week mon tue wed thu fri \
  --timezone "UTC" \
  --start 08:00 \
  --end 20:00

Outside the business-hours window, the default profile with minimum 1 takes effect. Users during off-hours are served by a single instance, saving significant cost compared to running 4 instances around the clock.

New instance warm-up and startup time

When App Service adds a new instance, it starts your application and waits for it to be ready before routing traffic to it. The amount of time this takes depends on your application’s startup — loading configuration, initialising database connections, warming up caches, JIT compiling code.

Two settings help control this:

• WEBSITE_SWAP_WARMUP_PING_PATH — a URL path that App Service pings during slot warm-up. The instance is not marked ready until this endpoint returns 200. Use a custom endpoint that confirms your app is fully initialised, not just that the web server started.
• Minimum instances. Keep at least 2 warm instances if your application has a long startup time. With 2 minimum instances, traffic is always being served even when autoscale adds a third instance that is still starting.