Azure App Service Plans: Pricing Tiers Compared
An App Service plan is the thing you actually pay for. The plan defines the set of compute resources your apps run on, and every app assigned to a plan runs on that plan's shared set of VM instances. Get the plan right and most operational questions answer themselves. Get it wrong and you'll discover the answer later, usually as a missing feature rather than a performance problem. The tiers aren't a smooth gradient of "more expensive means faster". They're a series of cliffs where specific capabilities switch on. This note is about where those cliffs are.
The three compute categories
App Service plans divide into three categories by how the underlying hardware is allocated.
| Category | Tiers | Primary use case | Key features |
|---|---|---|---|
| Shared compute | Free (F1), Shared (D1) | Development, testing, and learning with low traffic | Apps run on shared VMs with CPU quotas; no autoscaling and no SLA. Custom domains are available in the Shared tier |
| Dedicated compute | Basic (B), Standard (S), Premium (P, Pv2, Pv3, Pv4) | Production workloads, with more features and performance as the tiers go up | Apps run on dedicated VMs. Higher tiers add custom domains, TLS support, autoscaling, more instances, deployment slots, and a 99.95% SLA |
| Isolated compute | Isolated (Iv2) | Mission-critical applications needing maximum security, isolation, and scale | Apps run inside a dedicated virtual network (App Service Environment v3), giving both compute and network isolation. Highest scale-out ceiling, up to 100 instances per plan |
The shared tiers are genuinely for learning. No SLA is the detail that matters — not the CPU quota — because it means you can't put anything you care about there regardless of how light the traffic is.
A note on performance measurement, since course material often repeats it: App Service compute has historically been compared using the Azure Compute Unit (ACU), a normalised score with a Standard_A1 VM set to 100. It's worth knowing the term, but Azure no longer publishes ACU values — the metric turned out to have limited ability to predict real-world performance across the attributes that matter. Microsoft's current recommendation is to run your own workload on a candidate SKU and measure. Treat ACU as vocabulary for reading older documentation, not as a sizing tool.
Where the feature cliffs are
Within dedicated compute, the differences between Basic, Standard, and Premium are what most tier decisions turn on.
| Feature | Basic (B) | Standard (S) | Premium (P, Pv2, Pv3) |
|---|---|---|---|
| Use case | Dev/test, low traffic | Production workloads, moderate traffic | Production workloads, high traffic, demanding apps |
| Compute | Dedicated VMs, less powerful | Dedicated VMs, more powerful than Basic | High-performance dedicated VMs — faster processors, SSD storage, high memory-to-core ratio |
| Custom domains | Supported | Supported, with TLS | Supported, with TLS |
| Max instances (scale out) | Up to 3 | Up to 10 | Up to 30 (v2/v3/v4 tiers) |
| Autoscaling | Not supported | Supported | Supported |
| Deployment slots | Not supported | Supported (5 slots) | Supported (20 slots) |
| Storage | 10 GB | 50 GB | 250 GB |
| SLA | Yes, financially backed | Yes, typically 99.95% | Yes, financially backed, high availability |
| Virtual network integration | Via Hybrid Connections | Via VNet Integration | Via VNet Integration/Injection |
Four of those rows are the ones that actually force a tier upgrade in practice.
Autoscaling is the clearest divide. Basic requires manual scaling; Standard and Premium support scaling automatically against metrics or a schedule. If your traffic has any real variability, Basic means someone is watching a graph. The mechanics of rules, triggers, and the newer automatic scaling option are covered in the note on scaling App Service.
Deployment slots are the second, and arguably the more important one. Standard and Premium provide staging slots, which are what make zero-downtime deployment and pre-production validation possible. Basic has none. Any team practising continuous deployment has effectively already chosen Standard as its floor. See the dedicated note within the series on deployment slots and swaps for what slots make possible.
Scale-out ceilings rise with the tier: 3 instances for Basic, 10 for Standard, 30 for Premium. App Service Environments in the Isolated tier raise that to 100.
Virtual network connectivity improves in kind, not just degree. Basic offers Hybrid Connections; Standard and Premium provide proper VNet Integration, which is what lets you reach private resources and apply network security groups and firewall rules. The security implications of that are covered in the note on App Service networking and authentication.
Zone redundancy, and what it really costs
App Service supports zone redundancy on Premium v2 through v4 plans, and on Isolated v2 plans inside a zone-redundant App Service Environment. Enabling it distributes your plan's instances across multiple physical availability zones within a supported region, so a single zone failure doesn't take the app down.
Three requirements are worth knowing before you plan around it:
- A minimum of two instances. This is enforced. If you specify a capacity below two, the platform raises it to two and bills you for two.
- Scale-unit support. App Service runs internally on infrastructure called scale units (also called stamps). Not every scale unit supports availability zones, and you don't choose which one your plan lands on — it's assigned based on the plan's resource group. Check the plan's
maximumNumberOfZonesproperty; if it's 1, zone redundancy isn't available and the only fix is redeploying to a new plan in a new resource group. - Cost. There's no separate meter for zone redundancy and the per-instance price is unchanged. The cost comes entirely from that enforced two-instance minimum.
It's also worth knowing what zone redundancy doesn't protect. During a zone outage the application keeps serving traffic, but non-runtime operations can be affected — plan scaling, app creation, configuration changes, and publishing. And Azure doesn't guarantee that requests for replacement instances succeed during a zone failure; the platform backfills on a best-effort basis. If you need guaranteed capacity through a zone loss, you have to over-provision for it.
Finally, App Service is a single-region service. Zone redundancy is not regional resilience — if the region goes down, the app goes down. Multi-region availability is a separate design problem involving plans in each region and a global routing layer such as Traffic Manager or Front Door.
Scale up versus scale out
Two different operations get conflated constantly, and the tier decision depends on telling them apart.
Scaling up increases CPU, memory, and disk for each instance, and unlocks features — dedicated VMs, custom domains and certificates, staging slots, autoscaling. You scale up by changing the pricing tier of the plan.
Scaling out increases the number of VM instances running your application, up to the ceiling your tier allows.
One caveat from the reliability guidance that rarely makes it into course notes: avoid scaling up and down on a running production app. Changing the resources assigned to each instance can trigger an application restart, which is a self-inflicted transient fault. The better pattern is to pick a tier and instance size that meet your performance needs under typical load, then handle traffic variation by scaling out and in. Related: run more than one instance in production regardless of load, because App Service performs automated maintenance on instances and will replace unhealthy ones — with a single instance, that's downtime.
Plans can be scaled up or down at any time, and you can run different plans for different apps. Since all apps in a plan share its instances, plan boundaries are also isolation boundaries, a runaway app affects everything sharing its plan.