Azure App Service Plans and Pricing Tiers Explained: Pick the Right One

An Azure App Service plan is the group of virtual machines that your web apps, APIs and slots run on, and its pricing tier decides both the features you get and the hourly bill. For a small production workload, start with Basic or Standard, move to Premium v3 or v4 when you need more memory, scale-out headroom or reservations, and use Free only for experiments. You pay for the plan's instances, so one well-sized plan hosting several light apps is usually cheaper than one plan per app.

This guide is for developers, IT admins and small-business owners who are creating their first App Service plan or trying to understand why a bill looks the way it does. By the end you will know what each tier includes, how billing works, how many apps fit in a plan, and how to change a tier safely.

What an App Service plan is

An App Service app always runs in a plan. The plan defines the compute resources, and the apps simply use them. According to Microsoft Learn, each plan defines:

• The operating system (Windows or Linux).
• The region, such as West US or East US.
• The number of VM instances.
• The size of the VM instances (small, medium, large).
• The pricing tier.

When an app runs, it runs on every instance configured in the plan. Several consequences follow directly from that design:

• If multiple apps are in the same plan, they share the same VM instances.
• Every deployment slot of an app also runs on those same instances.
• Diagnostic logging, backups and WebJobs use CPU and memory on those instances as well.
• All apps in the plan scale together. Scaling the plan, manually or with autoscale rules, affects every app in it.

Azure Functions can also use App Service plans in some scenarios, which matters if you already have a Functions app on a dedicated plan.

Plan versus app

A common beginner mistake is to treat the app as the billable unit. In the dedicated tiers it isn't. The plan is the billable resource, so deleting an app does not stop charges if the plan stays, and an empty plan keeps billing. When you clean up a test environment, delete the plan, or the resource group that contains it.

The pricing tiers at a glance

Microsoft groups the tiers into three categories.

The tiers available to you depend on the operating system, the region and other factors, so the list in the portal may be shorter than the list in the documentation.

Limits that differ by tier

The service limits table in the Azure documentation gives the most useful comparison. These values were read from Microsoft Learn on 26 October 2026; check the page again before you commit to a design, because limits change.

For Basic and above, the documentation notes that the real number of apps you can host depends on app activity, instance size and resource use. "Not listed" means the limits table has no entry for that tier, so plan on slots and autoscale starting at Standard.

The practical reading of the table:

• Basic is the cheapest dedicated tier. The limits table lists no deployment slots or autoscale for it, and it tops out at three instances. It suits low-traffic internal tools and small sites. The Azure pricing page describes Basic as designed for low-traffic workloads without advanced autoscale or traffic management, and says savings plans and reserved instances aren't available for it.
• Standard adds autoscale and up to five deployment slots, which is the first tier where a staging slot and a swap-based release process work. Microsoft has moved Standard to a "previous plans" page for new customers, so you may not see it in every region or subscription.
• Premium (v3 and v4 are the current generations on the pricing page) gives 250 GB storage, up to 30 instances, 20 slots, and support for savings plans and reservations. Memory-optimized sizes carry an "m" in the name, such as P1mv3.
• Isolated runs inside an App Service Environment in your own virtual network. Use it when you need network isolation or very high scale; it is rarely the right choice for a small business.

How billing works

Except for the Free tier, an App Service plan is charged for the compute it uses. The rule differs by category:

• Shared: each app receives a quota of CPU minutes and each app is charged for that quota.
• Dedicated tiers (Basic, Standard, Premium): the plan defines the number of VM instances and each instance is charged.
• IsolatedV2: the App Service Environment defines the number of isolated workers and each worker is charged.

The Azure pricing page states that pay-as-you-go billing is by the second with no upfront commitment, and that prices depend on instance size and count. Prices vary by region, operating system and currency, and the pricing page loads them dynamically, so use the Azure pricing calculator for your region rather than a number from an article.

What doesn't cost extra

You aren't charged separately for most App Service features, including custom domains configured on an app, TLS/SSL certificate bindings, deployment slots and backups, subject to the limits of your tier. Slots do consume plan resources, because an active slot competes with the production app for the same instances.

Microsoft lists these exceptions:

• App Service domains: you pay when you buy one and each year when you renew it.
• App Service certificates: you pay when you buy one and at each renewal.
• IP-based TLS connections: there is an hourly charge for each, although some Standard or higher tiers include one for free. SNI-based TLS is free.

Related services are billed separately. If you add Azure Traffic Manager, a database or storage, their charges apply on top of the plan.

Dev and test pricing

The pricing page notes that Windows Basic, Standard and Premium v2 or v3 plans are eligible for dev/test pricing, which applies to subscriptions under the relevant dev/test offer. Check the offer terms before assuming you qualify.

How many apps fit in one plan

Because compute is shared inside a plan, putting several apps in one plan is the main cost-saving technique. The risk is that a noisy app starves its neighbours. Microsoft gives a general guide for the maximum number of apps per plan size:

Treat these as ceilings for lightly loaded apps, not targets. Active slots count as active apps in this guidance.

Isolate an app in its own plan when:

• The app is resource intensive.
• You want to scale it independently of the other apps.
• It needs resources in a different geographic region, which a plan can't provide because a plan lives in one region.

If a shared plan is struggling, move the heavy app to a new plan. In the portal, open the app, go to its App Service plan settings and change the plan; Microsoft documents this as "move an app to another App Service plan".

Per-app scaling is a middle path. When enabled, you can limit each app or slot to a subset of the plan's instances, but plan capacity and billing remain at the plan level.

Choosing a tier: a practical checklist

Work through these questions in order and stop at the first tier that satisfies all of them.

1. Is this production? If yes, skip Free and Shared. Both have no SLA according to the Azure pricing page, and the app can't scale out.
2. Do you need staging slots or autoscale? Both start at Standard. If you only need a manual instance count, Basic can reach three instances.
3. Do you need more than a few instances, more storage or reservations? Move to Premium. Reservations and savings plans are listed for the Premium tiers, not Basic.
4. Do you need network isolation for the whole environment? Only then consider Isolated.
5. Is the workload steady? If it will run all year, look at reserved instances or savings plans on the tiers that support them. If it is spiky, rely on autoscale instead.

A realistic starting setup for a small company with a public website and two internal apps is a single Linux or Windows plan on Basic or Standard running all three apps, with a budget alert, then splitting out the busiest app when metrics justify it.

Create a plan and check its tier

You can create a plan in the portal while creating an app, or ahead of time. The Azure CLI equivalent is below. Replace the placeholders with your own names.

az group create --name rg-contoso-web --location westus
 
az appservice plan create \
  --name plan-contoso-web \
  --resource-group rg-contoso-web \
  --sku B1 \
  --is-linux

The --sku value selects the tier and size, for example B1, S1 or P1V3. Create apps against the plan from the portal or with az webapp create --plan. To see which plans and SKUs exist in a resource group:

az appservice plan list --resource-group rg-contoso-web --output table

Change the tier: scale up and scale out

Microsoft separates two ideas:

• Scale up changes the pricing tier (and instance size) to get more CPU, memory, disk or features such as custom domains, staging slots and autoscale.
• Scale out increases the number of VM instances that run your app.

Both apply in seconds, affect all apps in the plan, and need no code change or redeploy.

Scale up in the portal

1. Open the Azure portal and open your app.
2. In the left pane, under App Service plan, select Scale up.
3. Select a pricing tier and choose Select.
4. Wait for the success notification.

If you are leaving the Free tier, the documentation says you must first remove any spending limit on the Azure subscription, which you do in Cost Management + Billing.

Scale up with the CLI

az appservice plan update \
  --name plan-contoso-web \
  --resource-group rg-contoso-web \
  --sku S1

Scale out manually

az appservice plan update \
  --name plan-contoso-web \
  --resource-group rg-contoso-web \
  --number-of-workers 2

Each extra instance is billed at the instance rate, so doubling instances doubles the compute cost of the plan. For rule-based scaling on Standard and above, see the Azure Monitor autoscale documentation linked below. App Service also offers an automatic scale-out option that handles varying HTTP load.

Scaling up and down is reversible. Microsoft's own example is to start on Free, then scale up when you add a custom DNS name, and scale back down later if you no longer need the higher tier's features.

Settings that depend on the tier

Some app settings only work on certain tiers, and the portal will tell you to scale up when you reach one. A frequent one is Always On. With it off, which is the default, the app is unloaded after 20 minutes without requests, and the next request pays a warm-up delay. With it on, the front-end load balancer sends a GET request to the application root every five minutes to keep the app loaded. Continuous WebJobs and cron-triggered WebJobs need it. You can set it under Settings then Configuration then General settings, or with the CLI:

az webapp config set \
  --name contoso-intranet \
  --resource-group rg-contoso-web \
  --always-on true

If the command fails or the toggle is greyed out, the plan's tier likely doesn't support the setting; scale up and retry.

Controlling cost after you pick a plan

• Set a budget alert. Cost Management budgets can warn you before a forgotten plan runs for a month. EpiFive has a step-by-step guide in Azure budgets and cost alerts setup.
• Delete idle plans. A plan with no apps still bills at its instance rate.
• Consolidate lightly used apps into fewer plans, within the density guidance above.
• Right-size after measuring. Review CPU and memory metrics on the plan before moving up a tier.
• Use reservations or savings plans only for steady workloads on tiers that support them.

For a broader review, see the Azure cost optimization checklist.

Troubleshooting common problems

The tier you want isn't offered

The tiers shown depend on operating system, region and other factors. Try another region, or create the plan on the other operating system, then check the list again.

An app is slow after hours of quiet

This is the Always On behaviour described above. Turn on Always On, which requires a tier that supports it.

One app slows all the others

They share the same VMs, and backups, logs and WebJobs also use plan CPU. Move the heavy app to its own plan or scale out the plan.

The bill is higher than expected

Check for extra instances, empty plans, active slots, IP-based TLS bindings and purchased domains or certificates. Use Cost analysis in Cost Management, filter by resource type, and compare plan instance counts against what you intended.

Summary checklist

• Treat the plan as the billable unit and the apps as tenants.
• Skip Free and Shared for anything customers or staff rely on.
• Pick Standard if you need slots or autoscale, Basic if you don't.
• Move to Premium for scale, storage and reservations.
• Keep apps that scale differently in separate plans.
• Add a budget alert and delete plans you no longer use.

References

• Azure App Service plans (Microsoft Learn)
• Azure subscription and service limits: App Service limits (Microsoft Learn)
• Scale up features and capacities in Azure App Service (Microsoft Learn)
• Configure an App Service app (Microsoft Learn)
• Get started with autoscale in Azure (Microsoft Learn)
• App Service pricing (Azure)