This chapter covers Azure App Service, a fully managed platform for hosting web applications, REST APIs, and mobile backends. It is a core PaaS (Platform as a Service) offering and appears frequently on the AZ-900 exam under objective 2.2 (Describe core architecture services). Understanding App Service helps you answer about 3-5% of exam questions, often comparing PaaS to IaaS or explaining deployment slots, scaling, and plan tiers. By the end of this chapter, you will know what App Service is, how it works, its pricing tiers, and the key exam traps.
Jump to a section
Imagine you own a catering business. To serve meals, you could build your own commercial kitchen from scratch: rent a space, install industrial ovens, hire a chef, manage inventory, and handle all maintenance. That's like running your web app on a virtual machine (IaaS) — you control everything but also manage everything. Now consider a managed restaurant franchise: you bring your recipes (your code), and the franchise provides a fully equipped kitchen, trained cooks (the platform), and handles cleaning, repairs, and ingredient sourcing. You just focus on cooking. Azure App Service is that franchise. It provides a fully managed platform for hosting web apps, REST APIs, and mobile backends. You deploy your code (or container) and Azure handles the web server (IIS), load balancing, auto-scaling, SSL certificates, and patching. You don't even see the underlying VMs. The mechanism: when you create an App Service, Azure provisions a front-end load balancer, a web worker sandbox (a secure, isolated process) on a pool of VMs, and a file share for your content. Requests come in through the load balancer, which distributes them across multiple worker instances if you scale out. Each worker runs your code in a sandboxed w3wp.exe process (for .NET) or equivalent for other stacks. If your app crashes, the sandbox is recycled automatically. The platform monitors health and can restart workers without your intervention. This is why App Service is called Platform as a Service (PaaS) — you only manage your app, not the platform.
What is Azure App Service?
Azure App Service is a fully managed platform for building and hosting web apps, RESTful APIs, and mobile backends. It is a PaaS (Platform as a Service) offering, meaning you do not manage the underlying infrastructure (VMs, operating system, web server). Instead, you focus on your code and data, while Azure handles everything else: patching, load balancing, auto-scaling, and security. App Service supports multiple programming languages and frameworks, including .NET, .NET Core, Java, Ruby, Node.js, PHP, and Python. You can also run containers using Docker.
The Business Problem App Service Solves
Traditionally, hosting a web application required buying or renting servers, installing an operating system, configuring a web server (like IIS or Apache), setting up a database, and then deploying your code. You also had to maintain the servers, apply security patches, and scale manually. This is complex, time-consuming, and expensive, especially for small to medium businesses. App Service eliminates this overhead by providing a ready-to-use hosting environment. You simply upload your code (or connect to a repository), and Azure takes care of the rest. This allows developers to deploy quickly, scale automatically based on traffic, and pay only for the resources they use.
How App Service Works: Step-by-Step Mechanism
App Service Plan: Before creating an App Service, you need an App Service Plan. This plan defines the region, number of VM instances, size of each instance (e.g., B1, S1, P1v2), and pricing tier (Free, Shared, Basic, Standard, Premium, Isolated). The plan is essentially a contract for the underlying VMs that host your apps. Multiple apps can share the same plan, and they all run on the same VMs. If you scale the plan (e.g., from 1 to 3 instances), all apps in that plan scale together.
Web Worker Sandbox: When you create an App Service (e.g., a web app), Azure assigns it to a web worker sandbox on one of the VMs in your plan. The sandbox is an isolated process (like w3wp.exe for .NET) that runs your code. Each sandbox has its own file system, environment variables, and memory limits. Azure monitors the health of the sandbox and automatically recycles it if it crashes.
Front-End Load Balancer: Incoming HTTP/HTTPS requests first hit a global load balancer (Azure Front Door or Azure Traffic Manager, depending on configuration) or a regional load balancer. The load balancer distributes requests across the available worker instances for your app. If you have multiple instances (scale out), the load balancer uses a round-robin or least-connections algorithm.
Deployment: You can deploy code to App Service using various methods: FTP, Git (local or cloud-based like GitHub, Bitbucket, Azure Repos), Zip deploy, or continuous deployment via CI/CD pipelines. Behind the scenes, Azure copies your files to a shared file system (Azure Files) that is mounted by all worker instances. This ensures all instances see the same content.
Scaling: App Service supports two types of scaling: scale up (increase the size of the VM, e.g., from Standard S1 to S2) and scale out (increase the number of VM instances). Scaling out can be manual or automatic based on metrics like CPU usage or request count. Auto-scaling uses Azure Monitor autoscale rules.
App Service Features: App Service provides built-in features like custom domains, SSL/TLS certificates, authentication/authorization (using Azure AD, Facebook, Google, etc.), staging environments (deployment slots), backup and restore, and integration with Azure SQL Database, Redis Cache, and other services.
Key Components and Tiers
App Service Plan Tiers: - Free (F1): 1 GB storage, 60 minutes of compute per day, no custom domains, shared VM resources. Good for testing only. - Shared (D1): 1 GB storage, 240 minutes of compute per day, custom domains, shared VM resources. Also for testing. - Basic (B1, B2, B3): Dedicated VMs, up to 10 GB storage, custom domains, manual scaling up to 3 instances. No auto-scaling, no SLA. Suitable for low-traffic production apps. - Standard (S1, S2, S3): Dedicated VMs, up to 50 GB storage, auto-scaling up to 10 instances (configurable), traffic manager integration, deployment slots (5). SLA of 99.95%. Suitable for production workloads. - Premium (P1v2, P1v3, etc.): More powerful VMs (v2 and v3 series), up to 250 GB storage, auto-scaling up to 30 instances, more deployment slots (20), private endpoints, VNet integration. SLA of 99.95%. For high-traffic or enterprise apps. - Isolated (I1, I2, I3): Runs on dedicated, isolated VMs within an App Service Environment (ASE). Highest performance, up to 1 TB storage, up to 100 instances, full network isolation. SLA of 99.95%. For compliance-heavy or high-security workloads.
App Service Types: - Web App: Hosts web applications (HTTP/HTTPS). - API App: Hosts RESTful APIs with built-in Swagger support. - Mobile App: Hosts mobile backends (deprecated in favor of Web App with Mobile Apps SDK). - Function App: Hosts serverless functions (Azure Functions) — actually a separate service but runs on App Service infrastructure.
Comparison to On-Premises Hosting
On-premises, you would buy a server, install Windows Server or Linux, configure IIS or Apache, set up a firewall, and manage backups. Scaling requires purchasing more hardware. With App Service, you skip all that. You get built-in load balancing, auto-scaling, managed SSL, and a 99.95% SLA (Standard tier). The trade-off is less control: you cannot install custom software on the VM, and some configurations are limited (like custom IIS modules). But for most web apps, this is a net gain.
Azure Portal and CLI Touchpoints
Portal: In the Azure portal, you can create an App Service by searching "App Services" and clicking "Add". You fill in the resource group, app name, runtime stack (e.g., .NET 6), region, and App Service Plan. After creation, you can deploy code via the "Deployment Center" (Git, GitHub Actions, etc.), configure custom domains in the "Custom domains" blade, and set up scaling in the "Scale up" and "Scale out" blades.
CLI Example: Create a web app with Azure CLI:
az group create --name myResourceGroup --location eastus
az appservice plan create --name myPlan --resource-group myResourceGroup --sku S1
az webapp create --name myUniqueAppName --resource-group myResourceGroup --plan myPlanThis creates a resource group, a Standard S1 plan, and a web app. You can then deploy code using az webapp deployment source config-zip or az webapp up.
Create an App Service Plan
First, you must create an App Service Plan. This defines the region, VM size (e.g., S1, P1v2), and pricing tier (Free, Shared, Basic, Standard, Premium, Isolated). The plan determines the compute resources available to your apps. You can create multiple apps in the same plan, and they share the underlying VMs. In the portal, you specify the plan name, pricing tier, and instance count. The CLI command is `az appservice plan create`. Behind the scenes, Azure provisions a set of VMs (or uses existing ones) in the chosen region based on the SKU. The plan also determines scaling limits: Basic allows up to 3 instances, Standard up to 10, Premium up to 30.
Create a Web App
Once the plan exists, you create a web app (or API app, mobile app). You specify a globally unique name (e.g., myapp.azurewebsites.net), runtime stack (e.g., .NET 6, Node.js 14), and the plan. Azure then creates a sandboxed worker process on one of the plan's VMs. The app gets a default domain `*.azurewebsites.net`. You can later add custom domains. The portal shows the app's URL, status, and basic metrics. CLI: `az webapp create`.
Deploy Application Code
You deploy your code using one of several methods: Git (local push to a remote Azure git repository), FTP, Zip deploy, or continuous deployment from GitHub, Bitbucket, or Azure Repos. For continuous deployment, you connect your repository and Azure automatically pulls changes on each commit. Behind the scenes, Azure copies your files to a shared Azure Files share mounted by all worker instances. This ensures all instances serve the same content. The default deployment directory is `site/wwwroot`. You can also use deployment slots to stage changes before swapping to production.
Configure Custom Domain and SSL
To use your own domain (e.g., www.contoso.com), you add it in the portal under "Custom domains". You must verify ownership by adding a TXT record to your DNS. Then, you bind an SSL/TLS certificate to enable HTTPS. Azure provides a free managed certificate for `*.azurewebsites.net` and custom domains (if you use Azure DNS). You can also upload your own certificate. The portal handles the binding. Behind the scenes, Azure front-end load balancers terminate SSL and forward traffic to the worker instances over HTTP (or you can configure end-to-end SSL).
Scale the App
You can scale up (increase VM size) or scale out (increase instance count). Scale up is done in the "Scale up" blade, where you choose a higher tier (e.g., from S1 to S2). Scale out is in the "Scale out" blade, where you set a manual instance count or enable autoscale rules based on metrics like CPU percentage or request count. Autoscale uses Azure Monitor to trigger scale actions. When you scale out, Azure adds more VMs to the plan and the load balancer distributes traffic to them. Scaling up may cause a brief downtime (a few seconds) because the app is moved to a different VM.
Scenario 1: E-commerce website with variable traffic A small online retailer expects heavy traffic during Black Friday but low traffic the rest of the year. They deploy their .NET Core e-commerce site to Azure App Service on a Standard S2 plan. They configure autoscale rules to scale out from 2 to 10 instances when CPU exceeds 70% and scale in when CPU drops below 30%. During normal days, they pay for 2 instances. On Black Friday, the site automatically scales to handle the load. They also use deployment slots to stage a new feature before swapping to production. The team sets up continuous deployment from GitHub. Cost: approximately $150/month for 2 instances, scaling up to $750/month during peak. If they had used VMs, they would have needed to manage scaling manually or over-provision.
Scenario 2: API backend for a mobile app A startup builds a mobile app that requires a REST API. They choose Azure App Service API App (now just Web App) with Node.js. They create a Basic B1 plan to keep costs low initially. As the user base grows, they scale up to Standard S1 for auto-scaling and a 99.95% SLA. They use Azure AD for authentication (built-in App Service authentication) and connect to Azure SQL Database. The team uses deployment slots for blue-green deployments. One mistake: they initially didn't enable auto-scaling, and during a viral marketing campaign, the API became unresponsive because the single instance was overwhelmed. After enabling auto-scaling, they handle spikes smoothly.
Scenario 3: Corporate intranet with high security A financial services company hosts an internal web application that must be isolated from the public internet. They use an Isolated tier App Service within an App Service Environment (ASE) deployed inside their virtual network. The ASE ensures the app runs on dedicated VMs not shared with other tenants. They use VNet integration to connect to an on-premises database via VPN. Cost is high (thousands per month), but compliance requirements mandate full isolation. Without ASE, they would have to manage their own IIS farm, which would be more expensive and less reliable.
Objective 2.2: Describe core architecture services – The exam expects you to know that Azure App Service is a PaaS offering for hosting web apps, APIs, and mobile backends. You must differentiate it from IaaS (VMs) and serverless (Azure Functions).
Common Wrong Answers and Why Candidates Choose Them: 1. *"App Service is IaaS because you can choose the VM size."* – Wrong. Choosing VM size is part of the App Service Plan, but you do not manage the VM. It's PaaS. 2. *"App Service is serverless."* – Wrong. Serverless (Azure Functions) is a separate service; App Service runs on dedicated or reserved VMs, even at the Free tier. Only Functions is serverless. 3. *"App Service can only run .NET apps."* – Wrong. It supports multiple languages: .NET, Java, Node.js, PHP, Python, Ruby. 4. *"You can install custom software on the App Service VM."* – Wrong. You cannot RDP into the VM or install software. Use WebJobs or containers for custom runtimes. 5. *"Free tier includes a custom domain and SSL."* – Wrong. Free tier does not support custom domains or SSL. You need at least Shared tier for custom domains and Basic for SSL.
Specific Terms That Appear on the Exam: - App Service Plan: The container that defines the region, VM size, and pricing tier. - Deployment Slots: Staging environments (e.g., "staging", "production") that allow zero-downtime deployment via swap. - Auto-scaling: Only available in Standard, Premium, and Isolated tiers. - SLA: 99.95% for Standard and above; no SLA for Free/Shared/Basic. - App Service Environment (ASE): Isolated, dedicated environment for high security and compliance.
Edge Cases: - If you stop an App Service, you still pay for the App Service Plan (the reserved VMs). To stop billing, you must delete the plan. - Scaling up (changing VM size) may cause a brief downtime; scaling out (adding instances) does not. - Deployment slots share the same App Service Plan, so scaling the plan scales all slots.
Memory Trick: Use the mnemonic PaaS = Platform as a Service – think of App Service as a "platform" that provides the web server, load balancing, and patching. If you have to manage the OS, it's IaaS. If you only write code and don't care about the server at all, it's serverless (Functions).
Decision Tree for Exam Questions: - Question asks for "web app hosting with minimal management" -> App Service (PaaS). - Question mentions "full control over OS" -> Virtual Machines (IaaS). - Question mentions "event-driven, pay-per-execution" -> Azure Functions (serverless). - Question mentions "staging environment for testing before production" -> Deployment slots. - Question mentions "99.95% SLA" -> Standard tier or higher.
Azure App Service is a PaaS offering for hosting web apps, REST APIs, and mobile backends.
An App Service Plan defines the region, VM size, and pricing tier; multiple apps can share a plan.
Scaling options: scale up (increase VM size) and scale out (increase instance count). Auto-scaling is available in Standard, Premium, and Isolated tiers.
Deployment slots allow zero-downtime deployments via slot swap; available in Standard and above.
SLA: 99.95% for Standard, Premium, and Isolated tiers; no SLA for Free, Shared, or Basic.
Custom domains and SSL require at least Shared (custom domain) and Basic (SSL) tiers.
You cannot RDP into the VM; use Kudu console or SSH for Linux for debugging.
Stopping an app does not stop billing for the plan; delete the plan to stop charges.
App Service supports .NET, .NET Core, Java, Node.js, PHP, Python, Ruby, and containers.
App Service Environment (ASE) provides isolated, dedicated hosting for high-security workloads.
These come up on the exam all the time. Here's how to tell them apart.
Azure App Service (PaaS)
Fully managed platform – no OS or web server management.
Auto-scaling built-in (Standard tier and above).
Built-in load balancing, SSL, and custom domains.
Supports multiple languages and containers.
99.95% SLA (Standard tier); no SLA for Free/Shared/Basic.
Azure Virtual Machines (IaaS)
Full control over OS and software.
Manual scaling or use VM scale sets.
You must configure load balancer and SSL yourself.
Any language or framework can be installed.
SLA of 99.95% for individual VMs with premium storage; 99.99% for availability sets.
Azure App Service (PaaS)
Always running – ideal for continuous web apps and APIs.
Scales by adding VM instances (manual or autoscale).
Billed per hour for the App Service Plan (reserved resources).
Supports long-running requests (up to 230 minutes).
Deployment slots for staging.
Azure Functions (Serverless)
Event-driven – runs only when triggered.
Scales automatically based on event count (consumption plan).
Billed per execution and per GB-second (consumption plan).
Execution timeout of 5 minutes (default) up to 10 minutes (Premium plan).
No deployment slots; use function app slots (preview).
Mistake
Azure App Service is Infrastructure as a Service (IaaS).
Correct
App Service is Platform as a Service (PaaS). You do not manage the underlying VMs or operating system. Azure handles patching, load balancing, and scaling. You only manage your code and configuration.
Mistake
You can RDP into the VM running your App Service.
Correct
You cannot RDP into the worker VM. App Service runs in a sandboxed environment. For advanced scenarios, you can use Kudu console (a browser-based shell) or SSH for Linux apps, but not full RDP.
Mistake
Free tier supports custom domains and SSL.
Correct
Free tier does not support custom domains or SSL. You need at least Shared (D1) tier for custom domains and Basic (B1) for SSL. Free tier is for testing only.
Mistake
App Service only supports .NET applications.
Correct
App Service supports multiple languages: .NET, .NET Core, Java, Node.js, PHP, Python, Ruby. You can also run custom containers.
Mistake
Stopping an App Service stops billing.
Correct
Stopping the app does not stop billing for the App Service Plan. You are charged for the reserved VMs in the plan. To stop billing, you must delete the plan or scale it down to Free tier (if possible).
An App Service Plan is a container that defines the region, VM size, and pricing tier for one or more apps. The App Service (web app, API app, etc.) is the actual application hosted within that plan. You pay for the plan, not the individual apps. If you delete the plan, all apps in it are deleted. If you stop an app, you still pay for the plan.
Yes, App Service supports running custom containers via Web App for Containers. You can deploy a Docker image from Azure Container Registry, Docker Hub, or other registries. This allows you to use any runtime or custom dependencies not natively supported. The underlying platform still manages the VM, but your app runs in a container.
A deployment slot is a live staging environment that shares the same App Service Plan. You can deploy a new version of your app to a slot (e.g., 'staging'), test it, and then swap it with the production slot. The swap is instantaneous and warms up the new instance before routing traffic. This enables zero-downtime deployments. Slots are available in Standard, Premium, and Isolated tiers.
Auto-scaling uses Azure Monitor autoscale rules. You define conditions based on metrics like CPU percentage, memory, or request count. When a condition is met, Azure adds or removes VM instances from the App Service Plan. For example, you can scale out by 2 instances if CPU > 80% for 5 minutes. Autoscale is only available in Standard, Premium, and Isolated tiers. Basic tier supports manual scaling only.
The SLA is 99.95% for Standard, Premium, and Isolated tiers. Free, Shared, and Basic tiers have no SLA. To qualify for the SLA, you must have two or more instances (scale out) and ensure your app meets the uptime requirements. The SLA covers connectivity to the app; it does not cover application-level errors.
Yes, but Azure Storage static websites are cheaper for static content. App Service is better for dynamic web apps. If you have a static site (HTML, CSS, JS) with no server-side code, use Azure Storage static website hosting. It is much cheaper and simpler.
You can set the connection string in the App Service configuration (Application Settings). The connection string is stored securely and injected as an environment variable. Your app reads it using standard database libraries. For added security, use Managed Identity to authenticate to Azure SQL without storing credentials.
You've just covered Azure App Service — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?