If you have ever opened an Azure bill and wondered why it is so much higher than expected, there is a good chance App Service Plans are the culprit. They are one of those infrastructure concepts that is easy to misunderstand on first encounter — and the misunderstanding is expensive. This article explains how plans actually work, what the tier choices mean in practice, and how to structure your hosting when you are running multiple applications.
What an App Service Plan actually is
An Azure App Service is the thing you deploy: a web app, an API, a function app wrapper. An App Service Plan is the underlying compute that your App Services run on — the virtual machine resources, the region, the operating system, and the pricing tier. The relationship is many-to-one: multiple App Services can run on a single plan, sharing its CPU and memory.
This distinction matters because you pay for the plan, not the app. An empty plan with no apps deployed to it still incurs charges. A plan with ten apps deployed to it costs the same as a plan with one — assuming the apps fit within the plan's resource allocation. Once you internalise this, a lot of Azure cost optimisation becomes obvious.
The tier choices and what they actually buy you
Azure offers a range of tiers, and the names are not always intuitive.
Free (F1) — 60 CPU-minutes per day, 1 GB memory, shared infrastructure. No custom domains. No SSL certificates. Puts your app to sleep after 20 minutes of inactivity, with a cold-start delay on the next request. Genuinely useful only for proof-of-concept work where you need a public URL and nothing else.
Basic (B1, B2, B3) — dedicated compute, custom domains, SSL, no auto-scaling. This is the right tier for non-production environments and low-traffic production apps. B1 (one core, 1.75 GB RAM) costs roughly £10–12 per month in UK South and handles more than most small applications will ever need. The key word is "dedicated" — your app is no longer on shared infrastructure, so performance is consistent and there are no cold starts.
Standard (S1, S2, S3) — adds auto-scaling (up to ten instances), deployment slots, and daily backups. S1 is approximately double the cost of B1 for comparable specs. If your app needs to handle variable load automatically, or if you need staging/production slot swapping for zero-downtime deployments, this is the tier to start at.
Premium (P0v3 and above) — higher compute-to-cost ratio than Standard, faster auto-scaling, virtual network integration, and support for higher memory workloads. Worth evaluating when you have a production app under meaningful load — the per-instance cost is higher but the specs-per-pound are often better than Standard.
The cost trap: one plan per app
The most common mistake is creating a new App Service Plan for every application. It is the default behaviour in the Azure portal's quickstart wizard, and it seems logical — each app gets its own isolated environment. But it means paying for dedicated compute per app, regardless of whether each app actually needs it.
A developer running five small web apps — a consultancy site, two SaaS prototypes, an internal tool, and an API — on five separate B1 plans is paying roughly £50–60 per month for hosting that could comfortably run on a single B2 plan at £20–25. The apps are small, traffic is light, and the shared B2 has more than enough headroom. The savings are real and immediate.
Consolidating apps onto a shared plan
Consolidation is straightforward: in the Azure portal or via CLI, you can move an existing App Service to a different plan in the same region and operating system family. Apps on a shared plan compete for the plan's CPU and memory, so the main consideration is whether your apps have overlapping traffic peaks that would cause contention.
For low-traffic apps — anything below a few hundred concurrent users — contention on a B2 or B3 is rarely an issue. For production apps with real user load, the question becomes whether the apps have independent scaling requirements. If one app needs to scale out under load independently of the others, it needs its own plan; auto-scaling operates at the plan level, not the app level.
A practical rule of thumb: consolidate development, staging, and low-traffic production apps onto one or two shared plans. Give high-traffic or latency-sensitive production apps their own Standard or Premium plan where auto-scaling is available.
Dev, staging, and production separation
A common pattern that works well at small scale:
- One B1 or B2 plan for all non-production environments — development instances, staging environments, internal tools, and side projects all share this plan. These apps do not need isolation from each other; if one causes a spike, it affects the others only temporarily and it matters much less than in production.
- One S1 or P0v3 plan per production application that needs to scale — production gets its own plan with auto-scaling enabled. Deployment slots (available from Standard upward) allow staging-to-production swaps without downtime.
If you are running several small production apps that individually do not justify a Standard plan, consolidating them onto a shared B2 or B3 is reasonable — provided they have low and relatively stable traffic. The risk is that a traffic spike on one app degrades the others. Monitor the plan's CPU and memory metrics and be ready to move apps off if contention becomes a problem.
Always-on and warm starts
One configuration detail worth knowing: the Always On setting, available from Basic tier upward, keeps your app loaded in memory even when there is no traffic. Without it, IIS-hosted .NET apps and some Node.js configurations will unload after a period of inactivity, causing a noticeable cold-start delay for the first request. For any app with a real user-facing URL, Always On should be enabled. It has no additional cost beyond the plan tier that supports it.
What to do when you are starting out
If you are in the early stages of building multiple apps and want to keep costs manageable without sacrificing capability:
- Start with a single B1 plan and deploy everything to it. Custom domains and SSL work, there are no cold starts, and the cost is around £10 per month.
- Upgrade to B2 when you have three or more apps and want more headroom — B2 doubles the CPU and memory for roughly double the price, but you are still splitting it across multiple apps rather than paying per app.
- Move production apps that need auto-scaling to their own Standard plan when traffic justifies it. This is a deliberate decision based on actual load, not a default.
- Use deployment slots on Standard plans for zero-downtime production deployments — this alone is often worth the step up from Basic.
Azure's pricing can feel opaque until you understand the plan abstraction. Once you do, the optimisation is mostly a matter of right-sizing: matching the plan tier to the actual load, and avoiding the default behaviour of creating a new plan for every new app.
Back to Insights