App Service Plans

Azure App Service plans define the compute resources used to run one or more App Service apps (web apps, mobile backends, or APIs). Unlike managing a VM where you install the OS and runtime yourself, App Service plans are a platform-managed bundle: Microsoft provides and maintains the VM, underlying OS, and platform services while you select the runtime (for example ASP.NET Core or Python), deploy your app, and manage your data. Key benefits

• No OS patching or VM lifecycle management — Microsoft handles platform updates.
• Choose a runtime and deploy code quickly.
• Host multiple apps within the same plan to share compute resources and lower costs.

You can run multiple applications under a single App Service plan. For example, a single Linux App Service plan can host both an ASP.NET Core app and a Python app when the runtimes and OS are supported by that plan. When to create a separate App Service plan

• You need apps deployed in different regions (plans are regional).
• You require a different OS (Windows vs. Linux plans are not mixable).
• You need different performance or isolation (e.g., memory- or CPU-intensive apps should be isolated to avoid impacting other apps).

​

App Service plan tiers (overview)

Azure provides tiers that scale from experimentation to enterprise production. Tiers differ by compute type, storage, scaling features, deployment slots, and price. The table below summarizes the common tiers and their attributes: Compute types by tier

• Shared compute — Free and Shared tiers: apps run on infrastructure shared across customers.
• Dedicated compute — Basic through Premium tiers: VMs dedicated to your subscription’s App Service plan.
• Isolated — Provisioned inside a dedicated virtual network via App Service Environment (ASE) for maximum network control and isolation.

​

Scaling options

Azure App Service supports two primary scaling approaches:

• Scale up (vertical scaling)
  • Move the App Service plan to a higher pricing tier or choose a larger instance size to gain more CPU, memory, or disk.
  • Best when your workload needs more power per instance rather than additional instances.
• Scale out (horizontal scaling)
  • Increase the number of instances to distribute load.
  • Manual scaling is available in Basic tier; autoscale is available from Standard tier and above.
  • Autoscale rules can trigger based on metrics (e.g., CPU > 70% for N minutes), HTTP queue length, custom metrics, or schedules.

Choose scale up when single-instance performance is the bottleneck; choose scale out when concurrency and throughput require additional instances.

​

Creating an App Service plan in the Azure portal (example)

The Azure portal provides a guided experience to create an App Service plan. You can configure subscription, resource group, plan name, OS (Windows or Linux), region, and pricing tier. Steps (portal)

1. Sign in to the Azure portal and choose Create a resource > Web + Mobile > App Service plan (or search “App Service plan”).
2. Select the subscription and resource group, set the plan name, choose OS (Windows/Linux), and pick the region.
3. Click Explore Pricing Plans to view available SKUs and choose a tier and instance size.
4. Review hardware and feature perspectives, then create the resource.

Here is an example screenshot of the “Create App Service Plan” page (the screenshot shows Standard S1 selected as an example): The portal offers two helpful pricing perspectives:

• Hardware view — shows CPU, memory, and instance sizes.
• Feature view — highlights capabilities such as custom domains, autoscale, backup, staging slots, and zone redundancy.

After creating the plan, open the App Service plan resource to view metrics, scale options, and settings. The overview displays essentials and performance metrics like CPU, Memory, and Data In. If there are no apps deployed to the plan, deployment slots and app lists will be empty. Within the App Service plan blade you will find actions and settings such as:

• Scale up — change pricing tier or instance size.
• Scale out — configure instance count or autoscale rules.
• Networking, Diagnostics, Backups, and other resource settings.

Note: The Isolated tier option is provided via App Service Environment (ASE) and does not appear as a standard tier selection in the plan blade. ASE deployments require selecting and configuring a virtual network during provisioning. When attempting to configure scale-out on plans that do not support autoscale (for example, Free or Basic tiers), the portal displays guidance and recommended pricing plans to enable autoscale. The screenshot below shows the Scale out page with a “See recommended pricing plan” prompt. Manual scaling is available in the Basic tier, while autoscale requires Standard tier or higher. To enable autoscale:

1. Upgrade the App Service plan to a tier that supports autoscale.
2. Configure autoscale rules based on target metrics or schedules (for example, add instances when CPU > 70% for X minutes).

​

Additional resources

• Azure App Service pricing and tiers: https://azure.microsoft.com/pricing/details/app-service/
• App Service plans and scaling documentation: https://learn.microsoft.com/azure/app-service/overview-hosting-plans
• App Service Environment (ASE) details: https://learn.microsoft.com/azure/app-service/environment/overview

Now that you understand App Service plans, tiers, compute types, and scaling, you can choose a plan that fits your application requirements and budget. Host multiple apps in a single plan to share resources, or create separate plans where region, OS, performance, or isolation requirements demand it.