The plan is the machines; the app is a tenant
The hub put App Service on the spectrum as the car service — you hand over code and Azure runs the machines beneath it. The App Service plan is those machines. It is a set of virtual servers, of a chosen size and count, that you rent by the hour; the web apps, APIs and functions you deploy are tenants that run on them. This is the fact beginners miss and invoices punish: you are not billed for an app. You are billed for the plan, whether one app runs on it or ten, whether it serves a million requests or none.
Several apps can share one plan, and often should — they split the machines you are already paying for. The catch is that they also split the machines' capacity: three busy apps on one small plan contend for the same CPU and memory, and one noisy neighbour can starve the others. The plan, then, is the unit of both cost and capacity, and every sizing decision in this part is really the same question asked twice — how much machine do these apps need, and how little can you get away with paying for it.
One more rule the portal enforces quietly: a plan is either Windows or Linux, never both, and every app on it inherits that operating system. Mixing means two plans. It is the first of several ways a second plan appears on your bill without anyone deciding to buy one.
The tiers — a ladder from free demo to dedicated fortress
App Service sells its machines in tiers, and the tier is not a volume knob — it gates features. Move up the ladder and you are not only buying more CPU; you are buying the ability to autoscale, to run deployment slots, to attach to a virtual network. Choosing a tier is choosing a feature set, and the two requirements that decide it for most workloads are the same two the hub named: does it need to scale automatically, and does it need to ship without downtime.
| Tier | What it is for | Scale out | Slots |
|---|---|---|---|
| Free / Shared | Demos, throwaways — shared machines, quotas, no custom TLS worth relying on | No | No |
| Basic | Dev, small internal tools on dedicated machines | Manual, up to 3 | No |
| Standard | The first production tier — most web apps live here | Autoscale | Up to 5 |
| Premium v3 | Higher scale, faster hardware, VNet, more slots | Autoscale, more | Up to 20 |
| Isolated v2 | App Service on hardware that is yours alone — the ASE, in Part C | Autoscale, up to 200 | Yes |
Read the "slots" and "scale out" columns and the gate the hub warned about is plain: autoscale and deployment slots both begin at Standard. Basic is genuinely App Service — dedicated machines, custom domains, TLS — but it scales only by your own hand and has no slots, so a workload that must surge for a seasonal peak or ship without a maintenance window cannot live there. Reaching for Basic to save a little money on such a workload is not thrift; it is buying a tier that fails the requirement you had.1 The App Service blog note "what is Azure App Service" walks the same ladder for reference.
The tier is a feature gate, not a volume knob.
Up versus out — the two ways to add power
There are exactly two directions to give a plan more capacity, and confusing them is a classic interview stumble. Scaling up is vertical: you change the tier or instance size, trading your small machines for larger ones — more CPU and memory per instance. Scaling out is horizontal: you keep the machine size and add more identical instances, and the platform load-balances across them. Up makes each worker stronger; out adds more workers.
The distinction matters because the two solve different problems and cost differently. A memory-hungry app that falls over on a single request needs to scale up — a bigger machine. An app that is fine per-request but drowns under a flood of visitors needs to scale out — more machines to share the crowd. Scaling out is also what elasticity means in practice: on Standard and above, an autoscale rule adds instances when a metric crosses a threshold and removes them when the crowd leaves, so you pay for November's fleet only in November. Scaling up is a manual decision you make rarely; scaling out is the one you automate.
The cost model, and the second plan you did not decide to buy
You pay for a plan by the hour, per instance, at the tier's rate — the moment it exists, running an app or not, and it does not scale to zero the way a consumption Function does. That single fact drives the whole cost model. Consolidate apps that can share capacity onto one plan and you pay once for machines several apps use. Scatter them across a plan each and you pay for idle headroom over and over.
The expensive mistake is rarely a tier chosen too high; it is plans that multiply quietly. A Linux app and a Windows app cannot share, so that is two plans. An app someone stood up "just to test" on its own plan and never deleted is a third, billing every hour since. A staging copy given a full separate plan instead of a deployment slot is a fourth. None of these was a decision to spend more; each was a default nobody costed. The discipline is to treat a new plan the way Part 11f treats a new VM — as a standing bill you must justify, not a free convenience.
One Standard plan, sized for the surge, shared where it can be
Campux's storefront lands on a single Standard plan — the tier the hub already committed it to, because it needs both autoscale for the November peak and deployment slots for downtime-free releases, and both begin here. You size it at S1 with an autoscale rule of one to four instances on CPU: one machine through the quiet months, up to four when the crowd arrives, back down in January. That is scaling out, automated, and it is the Class Two arithmetic finally spent on a real bill.
When the six-person team asks where to put the internal admin tool, the instinct is a second plan. You resist it. The admin tool is low-traffic and shares the storefront's operating system, so it becomes a tenant on the same Standard plan — capacity you already bought, no second bill. If one day it grows noisy enough to disturb the storefront, you split it then, on evidence. Part 11b is where you actually deploy onto this plan and wire the slots the tier provides.
Choosing a tier without guessing
Put the two decisions together and tier selection stops being a shrug. First ask what features the workload demands: autoscale or slots means Standard at minimum; a private network or very high scale pushes to Premium v3; hardware you alone touch means Isolated and an ASE, which Part 11c prices honestly. Only after the feature floor is set do you size within it — the instance size and the autoscale range — against what the app actually uses, not against fear.
Sizing to fear is the compute version of the all-IaaS instinct from Class Four: paying for headroom you will never touch because a bigger number feels safer. The honest move is to start one size down from your worry, watch the real metrics for a week, and scale up only if the graph says so — scaling up is a two-minute change, and Azure charges you nothing for having started modest. A tier chosen from evidence is a tier you can defend in the design review Part 11f prepares you for.
The plan nobody remembers creating
Finance asks why there are four plans when the team ships two apps. You list them: the storefront's Standard plan, a Windows plan for one legacy API, a Basic plan someone spun up to test a library in March, and a second Standard plan holding a staging copy. Two are real. The March plan is deleted; the staging copy collapses into a deployment slot on the storefront's plan. The bill drops by half and nothing that matters goes offline — because you treated each plan as a standing cost, not a free convenience.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. The plan is the billed resource, not the app — you pay for its machines by the hour whether one app or ten runs on them. Consolidating three apps onto one plan means one set of machines instead of three, at the cost of shared capacity. A misreads the model entirely: apps are free to create, plans cost money. C and D describe consumption-plan Functions, not App Service — an App Service plan runs continuously and does not scale to zero, so an idle app on it still bills. Confusing the two billing models is how a "cheap" always-on app quietly out-costs the Function it should have been.
C. Autoscale and deployment slots both begin at Standard — that is the gate the whole tier ladder turns on. Basic is the trap: it is dedicated App Service, but it scales only by hand and has no slots, so it fails both stated requirements to save a little money. Free is a demo tier, not production. Isolated v2 would give you both and more, but the question asks the lowest tier that qualifies, and paying for a dedicated ASE when Standard meets the requirement is exactly the fear-sizing this part warns against. The lowest tier that clears the requirement is the right answer, not the safest-sounding one.
The OS lock, up-versus-out, and shared capacity. Those are the three facts that drive real sizing decisions. The two rejects are the costly misreadings: an App Service plan does not scale to zero — it bills by the hour whenever it exists, which is the whole reason a rarely-run job belongs on a Function instead. And slots are not universal; they begin at Standard, so a design that assumes a staging slot on a Free or Basic app has assumed a feature it did not buy. Each false statement, believed, produces a specific surprise on the invoice or in the release.
PLAN LAYOUT — Campux App Service
1. Storefront -> Standard S1, autoscale 1..4 on CPU.
2. Admin tool -> same Standard plan, as a second app.
3. Staging copy of storefront -> its own Standard S1 plan.
4. Legacy Windows API -> its own (Windows) plan.
Line three. A staging copy of the storefront is exactly what a deployment slot is for — Standard already includes up to five, and a slot runs on the plan you have paid for rather than a second one. Standing up a whole separate Standard plan for staging doubles the storefront's machine bill to solve a problem the tier already solved for free. Lines one, two and four are sound: the storefront needs Standard, the admin tool rightly shares capacity, and the Windows API genuinely cannot share a Linux plan, so its own plan is forced, not wasteful.
Consider the consequence. Shipped as written, the staging plan bills every hour for a copy used a few minutes per release, and because it looks like a legitimate production plan, no cost review flags it for months. Knowing that a slot replaces a plan — Part 11b builds one — is the difference between a staging bill of zero and a staging bill equal to production.
Separate the two problems "slow under load" blurs. One is that a single request is too heavy for the machine — it runs out of CPU or memory serving one caller. The other is that each request is fine, but there are too many at once for one instance to keep up. The first is a scale-up problem; the second is a scale-out problem. Moving to a bigger instance fixes only the first, and buys nothing for the second except a larger idle bill.
Ask for the graph before the upgrade. What does per-instance CPU and memory look like at peak, and how many instances are running? If one instance is pinned while the app serves a crowd, the answer is more instances — scale out, ideally by an autoscale rule so it happens without you. If even a lightly-loaded instance struggles on a single request, then the machine really is too small and scaling up is right. The developer's proposed fix might be correct; you just do not yet know which problem you have.
Default to out, and to evidence. For a storefront facing a seasonal crowd, the usual answer is autoscale out, because the load is about numbers of visitors, not the weight of any one page. Reach for scale-up only when the metrics show a single instance can't handle a single request. Deciding from the graph rather than the complaint is what separates a defensible spend from a reflexive one.
Concede the real point first. The colleague is not wrong that apps on a shared plan contend for capacity, and that a noisy neighbour can hurt the others. Isolation is a genuine benefit, and for a high-value app that must never be disturbed, its own plan is a defensible purchase. The instinct is sound; it is the word "every" that turns a good idea into a standing waste.
Then price the blanket version. A plan per app means paying for idle headroom on every app, including the low-traffic ones that would never have disturbed anyone. You multiply the bill to buy isolation most of the apps did not need, and you create a fleet of plans nobody remembers — the exact "second plan you did not decide to buy" this part is about. Isolation bought reflexively is just cost with a virtuous name.
Offer the calibrated rule. Share a plan by default among apps that can tolerate each other; give an app its own plan when evidence — a real contention incident, or a genuinely critical workload — justifies it. That is isolation spent where it earns its cost, and it is the same "lowest chore, on evidence" instinct Part 11f will formalise into a decision you can defend.
Five things worth carrying out of Part A
- The plan is the billed resource, not the app. You pay for its machines by the hour whether one app or ten runs on them, and it does not scale to zero.
- Tier gates features, not just size. Autoscale and deployment slots both begin at Standard — Basic has neither, however "production" it looks.
- Scale up is vertical (bigger machines, rare, manual); scale out is horizontal (more machines, the thing autoscale automates). Ask which problem you have.
- A plan is Windows or Linux, never both. Mixing operating systems forces a second plan — one of several ways a plan appears on the bill unbidden.
- Consolidate apps that can share; treat a new plan as a standing cost to justify. Staging belongs in a slot, not a second plan.
- Tier names and their exact limits shift over time — Premium has moved through v1, v2 and v3, and slot and instance ceilings are raised periodically. Treat the specific numbers here as current-direction rather than eternal law: verify the ceiling that a design depends on against the App Service pricing page the week you commit to it. The shape of the ladder — features gated by tier, autoscale and slots starting at Standard — has been stable for years and is the part worth memorising. ↩
- "Scales to zero" is the single sharpest line between an App Service plan and a consumption-plan Function, and it is worth over-learning because the whole cost argument turns on it. A plan is rented capacity that bills while it exists; a consumption Function is billed per execution and costs nothing idle. When a workload runs rarely, the plan's always-on bill is the tell that it may belong one rung further toward serverless — the judgement Part 11f makes into a framework. ↩