App Service plans: tiers, scaling and sharing
An Azure App Service plan is the set of compute resources (virtual machines) that one or more App Service apps run on. The plan, not the app, decides the region, operating system, VM size, instance count and pricing tier, and it is the thing you pay for. The decision rule for exams: features such as autoscale and deployment slots are unlocked by the tier of the plan, capacity is changed by scaling the plan, and every app in a plan shares the same VMs and scales together; to give an app its own capacity, move it to its own plan.
What the plan owns and what the app owns
| Owned by the plan | Owned by the app |
|---|---|
| Operating system (Windows or Linux) | Runtime stack and code |
| Region | App settings, connection strings, slot settings |
| VM size and number of instances | Custom domains and certificates bindings |
| Pricing tier (Free, Shared, Basic, Standard, Premium, Isolated) | Deployment slots (limited by the tier) |
Microsoft Learn lists the tier families as Free, Shared, Basic, Standard, Premium (v2, v3 and v4 generations) and IsolatedV2 (App Service plans). Free and Shared run your app on a VM shared with other customers’ apps and cannot scale out. Basic and above run on dedicated VMs, and only apps in the same plan share those VMs. IsolatedV2 adds network isolation on top, through an App Service Environment.
The plan also hosts more than web apps. A function app on the Dedicated hosting option runs in an App Service plan, which is why that plan is a recurring answer in choosing an Azure compute service and in the Azure Functions guide.
The tier ladder: where each feature starts
The limits page (Azure subscription limits) gives these values for App Service:
| Tier | Max instances | Staging slots per app | Autoscale | Always On |
|---|---|---|---|---|
| Free, Shared | 1 (shared) | none | no | no |
| Basic | 3 | none | no | yes |
| Standard | 10 | 5 | yes | yes |
| Premium | 20 (v1), 30 (v2, v3, v4) | 20 | yes | yes |
| Isolated | 100 | 20 | yes | yes |
Memorise the two jumps. Basic to Standard is where autoscale and deployment slots appear. Standard to Premium raises the instance and slot ceilings. Custom domains need Shared or higher; Free allows only the azurewebsites.net name.
Scale up, scale out, and the shared fate of the apps
Scale up changes the tier or VM size of the plan: more CPU and memory per instance, or more features. Learn describes it as changing the pricing tier, and you can scale down again at any time. Scale out changes the instance count, manually or with autoscale rules, and needs Basic for manual scale-out and Standard or higher for autoscale.
Both operations act on the plan. Learn is explicit that all apps in a plan scale together, that deployment slots run on the same VMs, and that backups, diagnostic logs and WebJobs consume the same CPU and memory. An active slot counts as an active app when sizing the plan.
Two operational rules come up in questions (Manage an App Service plan):
- An app can be moved to another plan only if the source and target plans are in the same resource group and region and have the same OS type. You cannot change the region of a plan; clone the app instead.
- Deleting the last app in a plan deletes the plan by default, but a plan that stays empty still bills, because it keeps its VM instances reserved.
Worked example: three apps, one plan
A team runs an intranet site, a public API and a reporting app. Each has a production slot and one staging slot. They put all three in one Standard S1 plan with two instances.
- Active apps: 3 apps with 2 slots each (production and staging) gives 6 active apps.
- Learn’s density guidance for S1 is 8 apps, so 6 fits with some room. Adding three more apps would give 12, over the guidance.
- The API gets busy at month end. Scaling the plan out to 4 instances helps the API, but the intranet and reporting apps also now run on 4 instances, and each added instance is billed.
- If the reporting job’s CPU spikes were starving the API, scaling out does not isolate them. The fix is to move the reporting app to its own plan in the same resource group, region and OS.
Two things to notice: the guidance is guidance, not a hard limit, and per-app scaling can limit an app to a subset of instances but does not change the plan’s capacity or bill.
Which exams test this
| Exam | How it appears | Where on this site |
|---|---|---|
| AZ-104 | Domain “Deploy and manage Azure compute resources” (20-25%), objective group “Create and configure Azure App Service”: provision a plan, configure plan scaling, create an app, TLS, custom DNS, backup, networking, deployment slots. Outline as of April 17, 2026. | Compute resources explained |
| AI-200 | Domain “Develop containerized solutions on Azure” (20-25%): deploy containers to App Service, supplying environment variables and secrets. | Containerized solutions explained |
| SC-500 | Minor: “Secure compute” (20-25%) lists security controls for Azure App Service; it is about hardening, not plan sizing. | Secure compute explained |
AZ-104 is the exam that asks about plans directly. For AI-200 the plan matters mostly as the answer to “where does this container run”.
How exam questions are built around plans
- Tier as a hidden requirement. A scenario says “swap with zero downtime” or “scale automatically at CPU 70 percent”. The answer is a plan at Standard or above. Options that add instances to a Basic plan do not help.
- Up versus out. More memory per request or a missing feature means scale up. More concurrent users means scale out. Words like “peak traffic” and “automatically” point to autoscale.
- Shared plan, noisy neighbour. “One app uses too much CPU and affects the others” means move it to its own plan, not scale the existing one.
- Move constraints. Different OS or region in the target plan means the move is not supported.
- Cost traps. An empty plan still bills. Free and Shared bill differently from dedicated tiers, which bill per VM instance.
For the same-region question in a slot swap, see the related availability sets and zones guide for what a plan does and does not give you for resilience. For secrets that reach an app, see Azure Key Vault.
Practice questions
Question 1. Two web apps run in one Standard S1 App Service plan. The reporting app now uses so much CPU that the customer-facing app slows down. The customer-facing app must keep its current instance count and cost. What should you do?
- A. Scale out the existing plan to more instances
- B. Move the reporting app to a new plan in the same resource group and region
- C. Add a staging deployment slot to the reporting app
- D. Enable Always On for the reporting app
Show answer
Answer: B
Apps in a plan share the same VM instances, so heavy use by one app affects the others. Moving the reporting app to its own plan in the same resource group, region and OS type gives it separate VMs. Scaling out the existing plan adds instances for both apps and raises the cost. A deployment slot runs on the same VMs as the app. Always On keeps the app loaded but adds no capacity.
Question 2. A web app runs in a Basic B2 plan. The team needs deployment slots for blue-green releases and wants the instance count to adjust automatically with load. What is the most direct change?
- A. Scale out the Basic plan to three instances
- B. Enable Always On on the app
- C. Scale up the plan to the Standard tier
- D. Move the app to a Free plan to reduce cost
Show answer
Answer: C
Deployment slots and autoscale are available from the Standard tier upward, so the plan must be scaled up to at least Standard. Scaling out a Basic plan only adds instances manually, up to 3, and does not unlock slots or autoscale. Enabling Always On does not provide either feature. Moving the app to a Free plan removes capabilities.
Go deeper
- Azure App Service plan overview (tiers, billing, density guidance)
- Manage an App Service plan (move, scale, delete)
- Azure subscription and service limits (App Service limits table)
- Related guides: Choosing an Azure compute service, Azure load balancing options, Azure Functions triggers and bindings, How to study for certification exams