This chapter covers Azure App Service Plans and Web Apps, the core compute platform for hosting web applications, REST APIs, and mobile backends in Azure. For the AZ-104 exam, this topic is heavily tested under objective 3.2 (Configure and manage Azure App Service), typically appearing in 10–15% of questions. You will need to understand plan pricing tiers, scaling behavior, deployment slots, and networking constraints to pass scenario-based questions. Mastery of this material is essential for any Azure administrator responsible for deploying and managing web workloads.
Jump to a section
An Azure App Service Plan is like a factory floor with a certain number of workstations (VMs) and a power supply (tier). Each workstation has a fixed capacity: memory, CPU, and disk. The factory floor can be expanded by adding more workstations (scale out) or upgrading the power supply to a stronger one (scale up). Web apps are like assembly lines that run on these workstations. Multiple assembly lines can share the same floor if they are lightweight; but if one line requires heavy machinery, it might need a dedicated workstation. The factory manager (Azure) automatically assigns each app to a workstation, but all apps on the same plan share the collective resources of all workstations. If one app consumes too much power, it can starve others. To prevent this, you can isolate apps by putting them on separate plans (dedicated workstations). The plan's pricing tier determines the hardware spec: Free/Shared (shared floor with neighbors), Basic (dedicated but limited), Standard (auto-scale capable), Premium (more power and features), and Isolated (private floor in a datacenter). Just as a factory floor has a maximum number of workstations, a plan has a maximum instance count (scale limit) that varies by tier. You can also set auto-scale rules to add or remove workstations based on CPU load or other metrics, like a factory supervisor who hires temporary workers when orders surge.
What is an Azure App Service Plan?
An App Service Plan defines a set of compute resources for a web app to run. These resources are the equivalent of a server farm in traditional hosting. The plan specifies the region, the number of VM instances, the size of each VM (tier), and the pricing tier (Free, Shared, Basic, Standard, Premium, Isolated). All apps assigned to a plan share the same VM resources. If you have multiple apps in one plan, they all run on the same VMs. The plan's tier determines the features available: custom domains, SSL, auto-scaling, staging slots, VNet integration, etc.
How It Works Internally
When you create a web app, you must associate it with an App Service Plan. The plan is the container that allocates resources. The underlying infrastructure consists of VMs managed by Azure. Each VM runs a sandboxed environment (a worker process) that hosts your application code. The number of VMs backing a plan is equal to the instance count you set. By default, a new plan has 1 instance. You can scale out by increasing the instance count (up to the maximum allowed by your tier). The load balancer in front of the VMs distributes incoming HTTP requests across all instances. All instances run the same application code and share the same configuration.
Key Components, Values, Defaults, and Timers
Pricing Tiers: Free (F1) – 60 CPU minutes/day, 1 GB storage, shared infrastructure, no custom domain. Shared (D1) – shared infrastructure, custom domain supported. Basic (B1, B2, B3) – dedicated VMs, up to 3 instances, no auto-scaling. Standard (S1, S2, S3) – dedicated VMs, up to 10 instances (default max 10, can be increased via support), auto-scaling supported. Premium v2/v3 (P1v2, P2v2, P3v2, P1v3, etc.) – more CPU/memory, up to 30 instances, faster networking. Isolated (I1, I2, I3) – dedicated App Service Environments (ASE) on dedicated VNet, up to 100 instances.
Instance Count: Default 1. For Free/Shared, max 1 instance. Basic: max 3. Standard: max 10 (default). Premium: max 30. Isolated: max 100.
Auto-scaling: Can scale based on metrics (CPU, memory, HTTP queue length) or schedule. Minimum cool-down period between scale operations is 5 minutes. Default scale rule: increase by 1 instance when CPU > 70% for 10 minutes, decrease by 1 when CPU < 30% for 10 minutes.
Deployment Slots: Each Standard or higher plan supports up to 5 deployment slots (plus production). Slots are live apps with their own hostnames. You can swap slots with zero downtime.
VNet Integration: Standard or higher plans support regional VNet integration (preview for Basic). Isolated plans can be deployed directly into a VNet (ASE).
Always On: Feature (Basic and higher) that keeps the app loaded, preventing idle timeout. Without it, the app may unload after 20 minutes of inactivity.
Minimum TLS Version: Default 1.0, can be set to 1.2.
HTTP Version: Supports 1.1 and 2.0.
Configuration and Verification Commands
Create a plan:
az appservice plan create --name MyPlan --resource-group MyRG --sku S1 --is-linux false --location eastusCreate a web app:
az webapp create --name MyWebApp --plan MyPlan --resource-group MyRG --runtime "DOTNETCORE|6.0"Scale out:
az appservice plan update --name MyPlan --resource-group MyRG --number-of-workers 5List plans:
az appservice plan list --resource-group MyRG --output tableGet plan details:
az appservice plan show --name MyPlan --resource-group MyRGInteraction with Related Technologies
Azure Front Door / Traffic Manager: Can distribute traffic across multiple App Service instances in different regions (multi-region deployment).
Azure Application Gateway: Can terminate SSL and route to App Service via VNet integration (internal IP).
Azure CDN: Can cache static content from App Service.
Azure Key Vault: Can store SSL certificates for custom domains.
Azure SQL Database / Cosmos DB: Backend databases for web apps.
Azure DevOps / GitHub Actions: CI/CD pipelines deploy to App Service slots.
Exam-Relevant Details
Free and Shared tiers have quota limits; they are not suitable for production.
You cannot change the plan's tier from Free/Shared to Basic/Standard without downtime? Actually, you can scale up with minimal downtime, but scaling down may cause downtime if the new tier has fewer resources.
Auto-scaling is only available in Standard and higher tiers.
Deployment slots are only available in Standard and higher tiers.
Always On is required to avoid cold starts; it is available in Basic and higher.
VNet integration (regional) is available in Standard and higher; gateway-required VNet integration is deprecated.
App Service Environment (ASE) is for Isolated tier only.
The default instance count is 1.
The maximum number of instances for Standard tier is 10 by default but can be increased to 20 by support ticket.
Minimum TLS version can be enforced via Configuration > General Settings.
You can restrict access by IP address via Access Restrictions.
You can enable Managed Identity for accessing other Azure resources without secrets.
Backup and restore features are available in Standard and higher.
Custom domains and SSL are available in Shared and higher (but Free does not support custom domains).
The plan's SKU determines the available features; you cannot use features not supported by the tier.
You can move an app to a different plan, but both plans must be in the same region and resource group (actually, they can be in different resource groups but same region).
You can scale up (change tier) or scale out (increase instances) independently.
The az webapp config set command can modify runtime settings.
The az webapp log tail command streams logs.
The az webapp deployment slot commands manage slots.
Common Exam Traps
Trap 1: Choosing Free tier for a production app because it's free. Reality: Free tier has CPU quotas and no custom domain; it will be throttled.
Trap 2: Thinking auto-scaling is available in Basic. Reality: Basic supports manual scaling only; auto-scaling requires Standard or higher.
Trap 3: Assuming deployment slots are available in all tiers. Reality: Only Standard and higher.
Trap 4: Believing that scaling up (changing tier) causes downtime. Reality: Scaling up is usually seamless, but scaling down may cause brief downtime.
Trap 5: Confusing instance count with SKU size. Instance count is the number of VMs; SKU size is the VM size (e.g., S1, S2, S3).
Trap 6: Forgetting that Free and Shared tiers share resources with other customers; performance is unpredictable.
Conclusion
Understanding App Service Plans is fundamental to managing web apps in Azure. The plan defines the boundaries of compute resources, features, and scalability. For the exam, focus on tier capabilities, scaling options, and slot usage. Always match the tier to the application requirements: Free for dev/test, Basic for low-traffic production, Standard for most production workloads, Premium for high performance, and Isolated for strict isolation.
Create an App Service Plan
Navigate to the Azure portal, search for 'App Service plans', click 'Add'. Fill in resource group, name, region, operating system (Windows/Linux), and pricing tier (SKU). For example, select 'S1 Standard' for a production web app. Review and create. The plan is created with 1 VM instance. The VM is provisioned in the selected region. The plan acts as a container; no app yet.
Create a Web App in the Plan
In the portal, click 'Create a resource' > 'Web App'. Select the existing plan (or create new). Provide app name, runtime stack (e.g., .NET 6, Node.js 14), and region (auto-filled from plan). Click 'Review + create'. Azure provisions the web app: it creates a deployment slot (production), configures the runtime, and allocates storage. The app is now running on the plan's VM(s).
Scale Out the Plan
In the App Service Plan blade, under 'Settings', click 'Scale out (App Service plan)'. Move the slider to increase instance count (e.g., from 1 to 3). Click 'Save'. The platform adds two more VMs to the plan. The load balancer starts distributing traffic to all three instances. The web app is now running on 3 VMs. Scaling out is immediate.
Configure Auto-Scaling
Under 'Scale out', switch to 'Custom autoscale' (requires Standard tier or higher). Create a scale condition: e.g., scale out by 1 instance when CPU > 70% for 10 minutes; scale in by 1 when CPU < 30% for 10 minutes. Set instance limits (min 1, max 10). The autoscale engine monitors metrics and adjusts instance count based on rules. Cool-down period is 5 minutes.
Create a Deployment Slot
In the web app blade, under 'Deployment', click 'Deployment slots'. Click 'Add Slot', give it a name (e.g., 'staging'), and choose whether to clone settings from production. A new live app is created at `<slotname>-<appname>.azurewebsites.net`. You can deploy code to this slot, test it, then swap with production with zero downtime.
Scenario 1: E-commerce Website with Seasonal Traffic
A retail company runs an e-commerce site on Azure App Service. They use a Standard S3 plan with auto-scaling configured to handle Black Friday traffic. The site is deployed across two regions (East US and West US) for disaster recovery, with Azure Traffic Manager routing users to the nearest region. Each region has an App Service Plan with a minimum of 3 instances and a maximum of 20. Auto-scale rules are based on CPU and memory usage. During normal days, the site runs on 3 instances. On Black Friday, traffic surges; auto-scale adds instances up to 20. The company also uses deployment slots for blue-green deployments: they deploy new code to a staging slot, run integration tests, then swap slots. They use VNet integration to connect to a backend SQL Database in a VNet. Misconfiguration: initially they used Basic tier, which does not support auto-scaling, causing outages during peak. They learned to use Standard or higher for production.
Scenario 2: Enterprise SaaS Application with Isolated Requirements
A financial services company hosts a multi-tenant SaaS application that must be isolated from other Azure customers due to compliance. They use an Isolated tier App Service Plan inside an App Service Environment (ASE) deployed into their own VNet. The ASE provides dedicated compute resources on a private network. They scale up to I3 instances for high memory and CPU. They use multiple deployment slots for each tenant (production, staging, testing). They integrate with on-premises databases via ExpressRoute and VNet peering. Common issue: they initially tried to use regional VNet integration with Standard plan, but compliance required full isolation. They moved to ASE, which is significantly more expensive but meets regulatory needs.
Scenario 3: High-Traffic API Backend with Global Distribution
A social media company runs a REST API on Azure App Service. They use Premium v3 plan (P3v3) for low latency and high throughput. They have 10 instances globally distributed across multiple regions via Azure Front Door. Each region's plan is scaled to handle local traffic. They use slot swaps for zero-downtime deployments multiple times per day. They also use Azure CDN to cache static responses. Misconfiguration: they initially set the minimum TLS version to 1.0, which was rejected by security audit. They updated to 1.2 via portal. They also had an issue with cold starts because 'Always On' was disabled; enabling it resolved the problem.
What AZ-104 Tests on This Topic (Objective 3.2)
The exam focuses on your ability to configure and manage App Service Plans and Web Apps. Specific sub-objectives include: create and configure App Service plans (3.2.1), configure web apps (3.2.2), configure deployment slots (3.2.3), and implement scaling (3.2.4). Questions are often scenario-based: you are given a business requirement (e.g., "need zero-downtime deployment, support auto-scaling, and custom domain") and asked to choose the correct plan tier or configuration.
Common Wrong Answers and Why Candidates Choose Them
Choosing Free tier for a production web app – because it's free. Candidates overlook that Free tier has CPU quotas (60 minutes/day) and no custom domain support. The exam expects you to know that Free and Shared are for dev/test only.
Selecting Basic tier when auto-scaling is required – because Basic supports scaling (manual). Candidates don't realize auto-scaling is a feature of Standard and higher. The exam will explicitly mention "auto-scale" in the requirement.
Assuming deployment slots are available in all tiers – because they are a common feature. Candidates forget that slots require Standard or higher. The exam will ask about slot swapping and expect you to know the tier prerequisite.
Confusing scale up vs scale out – candidates might think scale up adds instances. Scale up changes the VM size (e.g., S1 to S2), while scale out adds instances. The exam tests both concepts.
Specific Numbers, Values, and Terms That Appear Verbatim
Instance limits: Free/Shared (1), Basic (3), Standard (10 default, can be increased to 20 via support), Premium (30), Isolated (100).
Auto-scaling cool-down period: 5 minutes.
Default auto-scale rules: CPU > 70% for 10 minutes -> scale out 1; CPU < 30% for 10 minutes -> scale in 1.
Deployment slots: 5 slots max per app (plus production) in Standard and higher.
Always On: Available in Basic and higher; prevents idle timeout after 20 minutes.
Minimum TLS version: Can be set to 1.0, 1.1, or 1.2; default 1.0.
SKU tiers: F1, D1, B1/B2/B3, S1/S2/S3, P1v2/P2v2/P3v2, P1v3/P2v3/P3v3, I1/I2/I3.
Edge Cases and Exceptions the Exam Loves to Test
Moving a web app to a different plan: Both plans must be in the same region and resource group? Actually, they must be in the same region but can be in different resource groups. The exam may test this nuance.
Scaling down: Changing to a lower tier may cause downtime if the new tier has fewer resources. The exam may ask about impact.
Linux vs Windows plans: Plans are OS-specific; you cannot mix. The exam may ask about creating a plan for a Linux app.
ASE vs regional VNet integration: ASE is for Isolated tier; regional VNet integration is for Standard and higher (preview on Basic).
How to Eliminate Wrong Answers Using the Underlying Mechanism
Always map the requirement to the tier capabilities. If the requirement includes "auto-scale", eliminate Free, Shared, and Basic. If it includes "deployment slots", eliminate Free, Shared, Basic. If it includes "custom domain", eliminate Free. If it includes "VNet integration", eliminate Free, Shared. If it includes "high memory", choose Premium or Isolated. If it includes "isolated network", choose Isolated (ASE). Also, remember that scaling out increases instances, scaling up increases VM size. For zero-downtime deployment, use slots (requires Standard+). For global distribution, use multiple plans in different regions with Traffic Manager or Front Door.
App Service Plan defines the compute resources (VMs) and pricing tier for web apps.
Free and Shared tiers are for dev/test only; they have quotas and limited features.
Auto-scaling requires Standard tier or higher; Basic supports only manual scaling.
Deployment slots require Standard tier or higher; max 5 slots per app.
Always On (prevents idle timeout) is available in Basic and higher tiers.
Custom domains are supported in Shared and higher; SSL requires Basic or higher.
VNet integration (regional) is available in Standard and higher; ASE is for Isolated tier.
Scale up changes VM size; scale out adds VM instances.
Default auto-scale rule: scale out if CPU > 70% for 10 min, scale in if CPU < 30% for 10 min.
Cool-down period for auto-scale is 5 minutes.
You cannot change the OS (Windows/Linux) of a plan after creation.
Moving a web app to another plan requires both plans to be in the same region.
These come up on the exam all the time. Here's how to tell them apart.
Manual Scaling
You manually change instance count via portal or CLI.
Available in all tiers (Free/Shared limited to 1 instance).
No rules; you decide when to scale.
Sufficient for predictable traffic patterns.
Requires monitoring and manual intervention.
Auto-Scaling
Instance count adjusts automatically based on metrics or schedule.
Available only in Standard, Premium, and Isolated tiers.
Rules define trigger metrics and actions.
Ideal for variable or unpredictable traffic.
Uses cool-down period (5 min) to avoid flapping.
Scale Up (Change Tier)
Changes VM size (e.g., S1 to S2).
Increases memory, CPU, and storage per instance.
May cause brief downtime when tier changes (especially scaling down).
No change in number of VMs.
Limited by maximum VM size available in region.
Scale Out (Add Instances)
Increases number of VM instances.
Increases overall capacity but per-instance resources unchanged.
No downtime; load balancer distributes traffic.
Limited by tier's max instance count.
Works with auto-scaling rules.
Regional VNet Integration
Available in Standard and higher tiers (preview on Basic).
App runs in a multi-tenant plan but can access resources in a VNet via a delegated subnet.
No dedicated VMs; shares infrastructure.
Supports outbound-only traffic to VNet (inbound requires private endpoint).
Lower cost, but limited isolation.
App Service Environment (ASE)
Requires Isolated tier (I1, I2, I3).
App runs on dedicated VMs inside a VNet (single-tenant).
Full inbound/outbound VNet access.
Higher cost, but full network isolation.
Supports up to 100 instances.
Mistake
Free tier supports custom domains and SSL.
Correct
Free tier does not support custom domains. Shared tier supports custom domains but not SSL. SSL requires Basic or higher.
Mistake
You can auto-scale a Basic tier plan.
Correct
Auto-scaling is only available in Standard, Premium, and Isolated tiers. Basic supports manual scaling only.
Mistake
Deployment slots are available in all pricing tiers.
Correct
Deployment slots require Standard tier or higher. Free, Shared, and Basic tiers do not support slots.
Mistake
Scaling up (changing tier) always causes downtime.
Correct
Scaling up is typically seamless with minimal to no downtime. Scaling down may cause brief downtime if the new tier has fewer resources.
Mistake
All web apps in the same plan run on separate VMs.
Correct
All apps in a plan share the same VMs. If you need isolation, put each app in its own plan (or use Isolated tier).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An App Service Plan is the container that defines the compute resources (VMs, tier, region) for one or more web apps. An App Service (web app) is the actual application that runs on the plan. The plan determines the features available to the app, such as auto-scaling, slots, and VNet integration. You can have multiple apps in one plan, sharing the same VMs.
Yes, you can scale up or down by changing the tier (e.g., from Basic to Standard). Scaling up is typically seamless with minimal downtime. Scaling down may cause brief downtime if the new tier has fewer resources. You can do this in the portal under 'Scale up (App Service plan)' or via the `az appservice plan update` command with the `--sku` parameter.
You can have up to 5 deployment slots per web app, plus the production slot. This feature requires Standard tier or higher. Slots are live apps with their own hostnames. You can swap slots with zero downtime, which is useful for blue-green deployments.
There is no default auto-scaling rule; you must configure custom autoscale rules. A common rule is: scale out by 1 instance when CPU percentage > 70% for 10 minutes, and scale in by 1 instance when CPU percentage < 30% for 10 minutes. The cool-down period between scale operations is 5 minutes.
No. Free tier does not support custom domains. You need at least Shared tier to add a custom domain. However, Shared tier does not support SSL; for SSL, you need Basic or higher.
Always On keeps the web app loaded in memory, preventing it from being unloaded after 20 minutes of inactivity. This avoids cold starts. It is available in Basic and higher tiers. Enable it for production apps that need consistent response times. Note that it consumes resources (memory) continuously.
You can use regional VNet integration (Standard tier or higher) to allow the app to access resources in a VNet via a delegated subnet. For full inbound/outbound isolation, use an App Service Environment (ASE) in the Isolated tier. Alternatively, you can use private endpoints for inbound traffic.
You've just covered Azure App Service Plans and Web Apps — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?