Deploy and manage Azure compute resources
App Service Plans, Apps, and Scaling
CoreSeparate plan capacity from app configuration and distinguish scale up from scale out.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
App Service apps run on plan capacity, so administrators must change the shared compute boundary when the requirement concerns features, worker size, or instance count.
Must Know
- An App Service plan defines region, operating system, pricing tier, compute size, and worker capacity for its apps.
- An App Service app holds application-specific runtime, deployment, domain, TLS, networking, and configuration settings.
- Scale up changes the plan tier or worker size; scale out changes the number of worker instances.
- Apps in the same plan share its compute resources, so one app’s load can affect the others.
- Automatic or rule-based scale out must use supported tiers and sensible minimum, maximum, and evaluation settings.
Compare and Distinguish
- App Service plan vs app: shared compute and feature boundary vs deployable web application configuration.
- Scale up vs scale out: larger or more capable workers vs more worker instances.
- App Service vs containers or VMs: managed web runtime vs container-oriented runtime vs full guest operating-system control.
Scenario examples
- Scenario: An app needs a feature available only in a higher plan tier. Think: Scale up the App Service plan rather than adding app instances.
- Scenario: CPU rises during business hours and more workers should share requests. Think: Scale out the plan manually or with an applicable scaling policy.
- Scenario: One busy app degrades two quieter apps on the same plan. Think: Evaluate plan capacity or isolate the app in a separate plan.
Exam traps
- Creating another app in the same plan does not create independent compute capacity.
- Scale up and scale out apply to plan compute even when initiated from an app context.
- A managed web requirement does not automatically justify the operational overhead of a VM.
Key takeaways
- Plan equals compute boundary; app equals workload configuration.
- Use vertical scaling for worker capability and horizontal scaling for instance count.
How it works
- App Service schedules an app on the workers allocated to its plan and routes requests across available instances.
- A scale operation changes either worker characteristics or plan instance count while app configuration remains associated with the app.
Objects and administrative surfaces
- App Service plan — subscription, resource group, region, operating system, tier, worker size, instance count, and scaling configuration.
- App Service app — runtime stack, application settings, identity, deployment, domains, networking, diagnostics, and backups.
When to use it
- Use App Service for managed web applications and APIs that do not require guest OS administration.
- Use separate plans when apps need different regions, operating systems, capacity isolation, or independent cost boundaries.
Security and governance implications
- Use managed identity and protected application settings instead of embedded credentials.
- Apply least privilege to app and plan changes because scaling one shared plan can affect cost and every resident app.
How to reason about this
- For capacity symptoms, compare per-instance metrics, total requests, worker count, tier limits, and noisy-neighbor behavior.
- For a failed scale action, inspect plan tier support, quotas, regional capacity, autoscale bounds, and recent activity-log errors.
More detail
- Provision the plan before or with an app, match OS and region requirements, and understand the effect of sharing the plan.
- Configure manual or supported automatic scaling while retaining enough minimum capacity for the application.
Ready for the quiz?
- Which resource controls the pricing tier and worker capacity?
- What change adds more instances without making each instance larger?
- Why can two apps in one plan influence each other’s performance?
Related objectives
- D3.4.S1 — Provision an App Service plan
- D3.4.S2 — Configure scaling for an App Service plan
- D3.4.S3 — Create an App Service