App Service Plans — Tiers and Scaling

Azure Basics · PaaS Compute – App Service, Container Instances and AKS · Lesson 1 of 5

An App Service Plan is the set of VMs running web apps; the tier decides features (slots, autoscale) and limits; scaling up changes the tier/size, scaling out changes the instance count.

An App Service Plan defines the compute for web apps: region, pricing tier, size and instance count. Several apps can share one plan (sharing its resources); you pay per plan, not per app.

Tier	Used for	Key points
Free / Shared (F1, D1)	Trying things out	Shared infrastructure, no custom-domain SSL, no scale-out
Basic (B1–B3)	Dev/test	Dedicated, manual scale-out (a few instances), no slots, no autoscale, backup of the production slot
Standard (S1–S3)	Production	Autoscale, deployment slots (5)
Premium v3/v4 (P0V3…)	Heavy production	More instances, more slots, higher performance
Isolated v2 (I1V2…)	Isolation in an App Service Environment	Private networking, large scale

flowchart LR
  B1["B1<br/>1 instance"] -- "scale up: change tier/size" --> S1["S1"]
  S1 -- "scale out: add instances" --> S1x3["S1 × 3 instances"]
  S1x3 -- "autoscale by CPU/schedule" --> S1xN["S1 × N"]

Scale up/down: change the tier/size (more CPU, RAM, features) — az appservice plan update --sku S1.
Scale out/in: change the instance count — manually with --number-of-workers 3 or with autoscale (Standard and above) by metric (CPU, memory, HTTP request count) or schedule; always add a scale-in rule.
--is-linux creates a Linux plan (the current CLI defaults to Linux; --is-linux false for Windows).

Traps: Basic has no slots and no autoscale; scaling up is not scaling out; per-tier limits change over time — check the current pricing page.

Command	Meaning
`az appservice plan create -g rg-devops-lab -n plan-lab --sku B1 --is-linux`	Create a plan
`az appservice plan update -g rg-devops-lab -n plan-lab --sku S1`	Scale up
`az appservice plan update -g rg-devops-lab -n plan-lab --number-of-workers 3`	Scale out

Where App Service fits among PaaS options

Service	Best for	Billing model
App Service	Web apps and APIs that run continuously	Per plan instance
Azure Functions	Event-driven code (HTTP, queue, timer)	Per execution on Consumption or Flex Consumption, or a Premium plan
Azure Container Apps	Containers and microservices with scale-to-zero, built on Kubernetes without managing it	Per vCPU-second and memory
AKS	Full Kubernetes control	Per node VM
Static Web Apps	Static front ends with optional serverless APIs	Free and Standard plans

A simple web API with steady traffic often fits App Service; spiky event processing fits Functions; several containers that talk to each other fit Container Apps.

Density and scaling

All apps in a plan run on every instance of that plan. Putting many busy apps in one plan saves money until they compete for CPU and memory; move a noisy app to its own plan. Per-app scaling lets one app run on fewer instances than the plan has. Premium v3 and higher support zone redundancy, spreading instances across availability zones.

Billing surprises

A plan is billed whether or not apps are running; stopping an app does not stop the charge. Scale the plan down or delete it.
The Free tier limits CPU minutes per day and does not allow custom domains with TLS; use it only for experiments.
Linux and Windows plans are priced differently and cannot be mixed in one plan.

Choosing a starting point

For a training project, B1 is enough to learn deployment. For production, start with Standard or Premium v3 so you get slots and autoscale, then use metrics (CPU, memory, HTTP queue length) to decide whether to scale up or out. az appservice plan show -g rg-devops-lab -n plan-lab --query "{sku:sku.name, workers:sku.capacity}" shows the current tier and instance count.