The most surprising thing about Azure App Service Plan tiers is that the "Free" tier is often a worse choice than "Basic" for anything beyond a fleeting demo.
Let’s see what that looks like in practice. Imagine you’ve got a small web app, my-demo-app, deployed to a Free tier App Service Plan, my-demo-plan.
az appservice plan show --name my-demo-plan --resource-group my-resource-group --query "{Name:name, Tier:sku.name, Capacity:sku.capacity, Location:location}" -o table
Output:
Name Tier Capacity Location
------------- ----- --------- ----------
my-demo-plan F1 1 East US
Right now, it’s fine. But what happens when traffic spikes? The Free tier is a shared environment with no guaranteed resources. Your app might get throttled, or even stopped, if another tenant on the same underlying hardware is using too much CPU or memory. This isn’t a bug; it’s a feature of the Free tier’s resource sharing.
The App Service Plan is the fundamental unit of compute for your web apps, API apps, and other App Service workloads. It defines the location, size, features, cost, and compute resources of the underlying virtual machines that host your applications. You don’t pick a tier for an individual app; you pick a tier for the plan, and all apps within that plan share its resources.
Here’s the breakdown of the common tiers and what they offer:
- Free (F1): Great for learning, testing, or very low-traffic demos. Limited CPU, memory, and disk space. No custom domains, SSL, or auto-scaling. Crucially, it’s subject to aggressive throttling and can be recycled by Azure.
- Shared (D1): Similar to Free but allows custom domains and SSL. Still shared resources and subject to throttling. Generally, not recommended for production.
- Basic (B1, B2, B3): Dedicated compute resources. You get a guaranteed amount of CPU, memory, and disk. Enables custom domains, SSL, and basic auto-scaling (though not always recommended to rely on auto-scale here). This is the entry point for production workloads where you need reliability.
- Standard (S1, S2, S3): More powerful dedicated VMs with higher CPU, memory, and disk. Offers advanced features like deployment slots, VNet integration (on some configurations), and more robust auto-scaling.
- Premium (P1v2, P2v2, P3v2, P1v3, P2v3, P3v3): Even more powerful instances, often with faster CPUs and more RAM. Supports features like private endpoints, App Service Environments (ASEs), and sophisticated auto-scaling. The 'v2' and 'v3' denote different generations of hardware with performance improvements.
- Isolated (I1, I2, I3): Runs your App Service Plan on dedicated Azure infrastructure, completely isolated from other customers. This is for the highest security and compliance needs.
Choosing the right tier involves balancing cost against performance, features, and scalability requirements.
Let’s say you’ve outgrown the Free tier and want to move my-demo-app to a more stable environment. You’d create a new Basic tier plan and then move the app.
First, create a Basic tier plan (e.g., B1):
az appservice plan create \
--name my-basic-plan \
--resource-group my-resource-group \
--location "East US" \
--sku B1 \
--is-linux # or --no-linux for Windows
Then, move your app to this new plan:
az webapp update \
--name my-demo-app \
--resource-group my-resource-group \
--plan my-basic-plan
Now, my-demo-app runs on dedicated hardware. You can verify the change:
az webapp show --name my-demo-app --resource-group my-resource-group --query "{Name:name, Plan:serverFarm.id}" -o tsv | sed 's/\/providers\/Microsoft.Web\/serverfarms\///' | xargs -I {} az appservice plan show --name {} --resource-group my-resource-group --query "{Name:name, Tier:sku.name, Capacity:sku.capacity}" -o table
Output:
Name Tier Capacity
------------- ---- ----------
my-basic-plan B1 1
The key is understanding that the plan is the compute resource. If your app is experiencing slow responses, intermittent unavailability, or you’re seeing throttling errors, it’s almost always a symptom that your App Service Plan tier is insufficient for the workload. You don’t optimize the app; you scale up the underlying compute.
One aspect that catches people off guard is the concept of "instance size" within a tier. For example, Standard (S1) has one instance size. Premium (P1v2, P2v2, P3v2) offers different instance sizes within the same tier. P2v2 has more CPU and RAM than P1v2. So, if you need more resources but don’t need the features of the next tier up (like Premium’s private endpoints), you can often "scale up" within the Premium tier by changing from P1v2 to P2v2. This is a more granular way to adjust performance without a full tier jump.
The next step after optimizing your App Service Plan tier is often understanding how to leverage deployment slots for zero-downtime deployments.