The plan is the machines; the app is a tenant
The shop’s website and its small staff API each have a front door, but Ada puts them in the same App Service plan. Think of two businesses renting rooms in one building: separate signs do not create separate electricity supplies. These apps share the plan’s compute capacity. If the website consumes that capacity during the November rush, the staff API can feel it too. First understand the building you are paying for; then decide whether sharing it fits.
Compatible apps can share a plan, so adding a second app does not automatically create a second plan charge. They also share its CPU and memory. If both become busy, you may need a larger plan or more workers. Other resources, such as storage and monitoring, can add separate costs. Ask two questions in order: can these apps share a plan, and does that plan have enough capacity for both?
A plan is configured for Windows or Linux, so apps needing different operating systems cannot share that plan. They may also need separate plans for isolation, region, or incompatible scaling needs. Check those constraints before grouping apps merely to reduce a bill.
The tiers — a ladder from free demo to dedicated fortress
A tier is a package of worker sizes, limits, and features. For our storefront, two requirements matter immediately: add workers under a seasonal surge and test a release in a deployment slot before swapping it into production. Standard is the lowest tier here that supports both rule-based autoscale and slots. Outbound VNet integration is also available on Basic and other supported dedicated tiers; it does not require Premium merely because it is private networking.
| 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 | Different worker sizes, scale limits, and advanced features | Autoscale, higher limits | Check current limit |
| Isolated v2 | App Service on hardware that is yours alone — the ASE, in Part C | Autoscale, up to 100 per plan | Yes |
Basic supports manual scale-out, but not the rule-based autoscale and deployment slots required by this example. Standard provides those features; the team still has to configure and test them. Exact instance and slot limits change, so verify the current feature list before committing to a production design.1
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.
Play it through
In this three-minute simulation, place a second compatible app on the same plan. The cost units are illustrative; use the slowdown to ask whether shared capacity is enough.
Practice later, optional: App Service plan and slot swap starts with one app on one plan, which is this part's core idea. Its slot section needs a paid Standard plan (slots are not on Free or Basic), so it bills while it runs. Read its steps and cleanup first, then verify that the staging slot shares the plan's workers.
The cost model, and the second plan you did not decide to buy
On a dedicated paid tier, the plan's selected worker size and instance count drive its compute charge while it is provisioned, even when no app receives traffic. App count by itself does not multiply the plan charge. A scale-to-zero Functions plan has a different compute billing model, though its dependencies may still cost money.2
Look for plans that were created for a short test and never removed. A staging app on a second full plan can also create an unnecessary standing charge when a supported deployment slot meets the release need. A slot has no separate slot fee, but it uses the same plan's workers, so stage and production still need enough shared capacity. A Windows app and a Linux app require different plans. Audit before deleting or consolidating: confirm OS, region, resource needs, release behavior, and dependencies.
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.
The internal admin tool uses the same OS and region and has little traffic, so the team first tests it on the same plan. That avoids a second plan charge if shared capacity is sufficient. Measure both apps during the November peak; move one to a separate plan if contention or isolation requirements justify it. Part 11b covers deployment slots.
Choosing a tier without guessing
First list required features. Rule-based autoscale and slots put this storefront at Standard or above. VNet integration alone does not force Premium; Basic is among its supported tiers. Then choose worker size and minimum/maximum instance counts using measured CPU, memory, response time, and a load test. Check each tier's current limits and price in the target region.
Do not promise that a smaller instance will survive a peak or that scaling changes are instantaneous. Start with a safe baseline, test the expected traffic, and set an alert when response time or resource use approaches your limit. The measured result gives you a reason to scale up, scale out, or improve the app itself.
The plan nobody remembers creating
Finance asks why four paid plans support two apps. You identify a storefront plan, a Windows plan for a legacy API, a forgotten test plan, and another plan for the storefront's staging copy. After checking dependencies and capacity, retire the unused test plan and use a deployment slot for release testing. The separate Windows plan stays. Compare the invoice before and after; savings depend on each plan's size and use.
Explain the shared bill
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
One plan, two apps Training observation: storefront busy; staff API slower No separate plan for staff API
Draw two apps inside one plan.
Predict whether adding a second app creates a second pool of compute.
Follow the linked plan/slot lab and record the plan name and capacity used by each app.
Check your reasoning after you finish
Both apps share the plan capacity. Adding an app is not the same as adding a plan or scaling that plan. Splitting plans may improve isolation but changes the bill.
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. Three compatible apps can use one paid plan instead of three separate plans. They share the same workers, so measure the combined load; the plan may need more paid capacity. Other resources can add charges. A dedicated App Service plan does not stop charging for provisioned workers simply because its apps are idle.
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.
Windows/Linux choice, up versus out, and shared capacity are the three true statements. A paid dedicated plan does not scale to zero when idle. A rarely run job might fit a scale-to-zero Functions plan, but check its duration, dependencies, and cost. Deployment slots start at Standard, not Free or Basic.
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. Standard supports staging deployment slots on the existing plan. A slot has no separate slot charge, while an extra Standard plan adds another set of paid workers. The slot shares those workers with production and can create contention, so check capacity during staging and swap. The Windows API cannot share a Linux plan.
Before removing the extra plan, confirm the staging app is truly a release copy and does not need independent capacity, OS, region, or isolation. Then migrate its release workflow to a slot and verify rollback.
Separate two common causes. One instance may lack memory or CPU even at modest traffic; a larger worker might help. Or each request may run well, but too many arrive at once; more workers might help. A slow database or external dependency is a third possibility that neither scaling choice fixes.
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.
Test the suspected fix. For a seasonal crowd, scaling out is a likely candidate, but first check per-instance CPU and memory, request latency, queueing, dependency timing, and whether the app handles multiple instances correctly. Load-test the chosen size and instance range, then monitor production.
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
- A paid dedicated plan supplies billed capacity. Compatible apps can share it, but they also share workers and can have other resource costs.
- 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.
- A staging slot has no separate slot fee, but it uses the plan's workers. Use it when shared capacity and the release workflow fit.
- Verify the current manual, rule-based, and traffic-based scaling options and slot support for the chosen tier. Outbound VNet integration also supports Basic; it does not make the app privately reachable inbound. Exact limits and regional prices need a current check. ↩
- The dedicated plan is provisioned capacity. A Functions scale-to-zero plan bills compute differently, though connected storage, logs, and network services may still cost money. Microsoft explains App Service plan sharing and slots; slots have no separate charge but share plan workers. ↩
Pick a plan tier and shape you can defend on the bill, and say what changes when you scale up versus out.
Play the lesson above to stamp this class.