Create and Configure Azure App Service (AZ-104)

Azure App Service is a fully managed platform as a service (PaaS) for hosting web applications, REST APIs, and mobile back ends. You bring your code or a container image and Azure runs it on managed infrastructure, patching the OS, load balancing, and providing HTTPS endpoints, so you never manage a virtual machine.

Every app runs on an App Service plan, and understanding this relationship is the key to the whole topic. The plan represents the set of compute resources (VMs) that host your apps: its operating system, region, and pricing tier. The plan is what you pay for; apps themselves add no separate compute charge.

Apps on a plan share every instance. When several apps sit on one plan, every app runs on every instance of that plan. If the plan has three instances, each app has a copy on all three. That has a consequence people often miss: scaling out does not isolate a busy app. Add an instance and the noisy app runs there too, consuming the new capacity alongside its neighbours. The only way to give one app its own compute is to put it on a separate App Service plan.

Moving an app to another plan. You can change an app's plan without redeploying it (Change App Service plan on the app), but only to a plan in the same resource group, same region, and same operating system as the current one (Azure calls this the same webspace). If the app uses virtual network integration, disconnect it before the change and reconnect it afterwards. To isolate a noisy app, then, you create a new plan in the same resource group and region with the same OS, move the app, and leave its neighbours on the original plan.

You provision a plan when you create your first app, or ahead of time from Create a resource > App Service Plan, choosing the operating system (Windows or Linux), region, and pricing tier. The tier determines how much power each instance has, how many instances you can run, whether apps share hardware with other customers, and which features you can use at all.

App Service plans come in a ladder of pricing tiers, each unlocking more resources and features, so a requirement maps to the lowest tier that supports it.

Three dividing lines matter most. First, Free and Shared run on shared infrastructure, while Basic and above run on dedicated VMs. Second, the feature floors: custom domains need Shared; TLS bindings, managed certificates, backups and Always On need Basic; autoscale, deployment slots and IP-based SSL need Standard. Basic can still scale out, but only to a manually set count of up to three instances. Third, Isolated v2 plans run in an App Service Environment (ASE) v3, a single-tenant deployment of App Service injected into a subnet of your own virtual network: no front ends or workers are shared with other customers, yet it is still managed web hosting rather than VMs you patch. Because a cost constraint usually accompanies a feature requirement, check every requirement against the table and choose the first tier that meets all of them, no higher.

App Service scales in two independent directions: scale up gives each instance more resources, and scale out adds more instances.

Scale up (vertical scaling) means changing the plan's pricing tier or instance size so each instance gets more CPU and memory, for example B1 to B2, or S1 to P1v3. Moving to a higher tier also unlocks features (slots, autoscale) the lower tier lacked. Scale up is the fix when a single request or process needs more than one instance provides, such as out-of-memory errors on one heavy request; adding more copies of an undersized instance fails the same way on each.

Scale out (horizontal scaling) means adding instances that each run a copy of every app on the plan, spreading many small requests across them. It is the fix when total load exceeds capacity but each request fits comfortably on one instance.

Instance caps. Each tier has a maximum instance count (Basic 3, Standard 10, Premium v3 30). A Basic plan that is already at three instances can still gain capacity cheaply by moving to a larger size in the same tier (each step from B1 to B2 to B3 adds cores and memory per instance) before you pay for a higher tier you do not otherwise need.

Autoscale rules (Standard and above). Autoscale changes the instance count based on a metric (CPU percentage, memory percentage, HTTP queue length) or a schedule. An autoscale setting has a minimum, maximum and default instance count. The default is used only when metrics are unavailable; it is not a level the plan returns to. Rules work in pairs: a scale-out rule adds instances when a threshold is crossed, and a separate scale-in rule removes them when load falls. Without a scale-in rule nothing ever removes instances, so after a surge the plan stays at its peak count, and you keep paying for it, until you add one. Set the scale-in threshold well below the scale-out threshold so the two do not fight. Premium plans also offer platform-managed automatic scaling driven by HTTP traffic, as an alternative to rule-based autoscale.

With a plan in place, you create the app itself. From Create a resource > Web App, you name the app (its default hostname becomes <name>.azurewebsites.net, or, for new apps, a unique default hostname that adds a random hash and region, which the portal now selects by default) and select the App Service plan (new or existing), region, and operating system. An app always takes the region and OS of its plan.

The important choice is the Publish option, which sets how your app is packaged:

• Code means you deploy application code and pick a runtime stack such as .NET, Node.js, Python, Java, or PHP. App Service provides and maintains the runtime.
• Container means you deploy a custom container image (for example from Azure Container Registry), giving you full control over the runtime and dependencies. Linux containers run on Linux plans; Windows containers need a Premium or Isolated v2 plan.

Getting code onto the app. Supported methods include the Deployment Center (continuous deployment from GitHub through GitHub Actions, Azure Repos, Bitbucket or local Git), ZIP deploy of a build package (for example az webapp deploy), and pulling a container image from a registry. Deployment Center is configured per slot, so a pipeline can target a staging slot directly. You do not deploy to App Service by copying disks, replicating VMs or uploading files straight into a storage account.

You manage application settings and connection strings in the app's Configuration (Environment variables) blade; they reach the code as environment variables. Because App Service is PaaS, you never touch the underlying VM; you manage the app and its configuration, and the remaining tasks in this lesson are all settings on this web app resource.

Four general settings change how an app behaves without any code change, and each solves a different problem.

Always On. Without it, App Service unloads an app after about 20 minutes with no incoming requests. Unloading stops anything running inside the app's process, including continuous WebJobs, which is why background jobs on an idle site appear to die on their own. Always On is not available on Free or Shared.

HTTPS Only versus minimum TLS version. A certificate binding makes HTTPS possible; HTTPS Only makes it mandatory by redirecting plain HTTP. The minimum TLS version is a different control: it decides which TLS protocol versions an HTTPS connection may use, and it does nothing about plain HTTP. They are often set together but never substitute for each other.

ARR affinity. With affinity on, a client keeps returning to one instance for its whole session, so when only a handful of clients generate most of the traffic, their requests pile onto a few instances while the rest sit idle. A stateless app should turn it off.

To map a custom domain, you create DNS records at your DNS provider that point the name at the app and prove you own it, then add the domain under the app's Custom domains blade. Custom domains need at least the Shared tier (not Free).

Two records, two jobs. A routing record sends traffic to the app, and a TXT verification record named asuid carries the app's custom domain verification ID. The record you use for routing depends on whether the name is a subdomain or the zone apex:

Why a CNAME for subdomains. A CNAME targets the app's hostname, never an IP address, so the mapping keeps working if the app's inbound IP changes (for example if the app is deleted and recreated in another resource group, or an IP-based TLS binding is removed). Scaling changes the app's outbound addresses, not its inbound IP. DNS does not allow a CNAME at the zone apex, which is the only reason the apex uses an A record. When you use an A record, point it at the app's inbound IP shown in the portal; the outbound IP addresses are what the app uses for its own calls and do not receive traffic. Microsoft recommends the TXT record in every case because it proves ownership and prevents subdomain takeover, where someone else claims a dangling CNAME that still points at a deleted app.

Migrating a live domain without downtime. When a name is already serving traffic elsewhere, you cannot repoint it first and configure the app later without an outage. Instead: create the TXT asuid.<subdomain> record first, so App Service can verify ownership while the CNAME still points at the old server; add the custom domain in the app and bind its certificate; and only then repoint the CNAME to the app. Users arrive at an app that already serves the name with a valid certificate. The certificate for this cutover must be an uploaded PFX or a Key Vault import: an App Service managed certificate can only be issued once the name already points at the app, so it can replace the imported one after the CNAME moves, not before.

To serve a custom domain over HTTPS you add a certificate to the app and create a TLS/SSL binding that ties it to the domain. Both need the Basic tier or higher.

Choose by renewal needs. A single host name with a free self-renewing certificate is the managed certificate. A wildcard that renews itself cannot be a managed certificate, so it is an App Service certificate with the wildcard SKU (or your own wildcard kept in Key Vault). A certificate your security team issues and renews in Key Vault belongs in the app as a Key Vault import, because an uploaded PFX is a snapshot that never sees the renewal.

SNI SSL versus IP-based SSL bindings.

Every modern browser supports SNI, so SNI is the default choice. IP-based SSL is an inbound feature only; it does not give the app a fixed outbound address. Turn on HTTPS Only and set the minimum TLS version (see General settings) to finish securing the domain.

App Service has two kinds of backup: automatic backups that the platform takes for you, and custom backups that you configure to your own storage account. Both are available on Basic tier and above (on Basic, only the production slot), and neither exists on Free or Shared.

Both capture the app's configuration and file content, and you can restore either to the same app, another app, or a slot. That makes automatic backups the quick answer to accidental deletion on any Basic-or-higher app, even one where nobody ever configured backups. Custom backups are the answer when backups must land as files in storage the company controls, on its own schedule or retention.

Custom backups to a firewalled storage account. Custom backups write to storage with a SAS token, not a managed identity. If the storage account's firewall admits only a virtual network, the backup traffic must come from that network: the app needs virtual network integration with a subnet the firewall allows, and you turn on Backup/restore over virtual network integration in the backup configuration. Without that option the backup still leaves through the public path and is blocked by the storage firewall. Linked databases are not backed up over the virtual network.

App Service networking features each work in one direction only: some control who can reach the app (inbound), others control how the app reaches other things (outbound). Matching the feature to the direction is the whole skill.

Outbound: virtual network integration. When the app must reach a database, storage account or API that accepts traffic only from a subnet, enable virtual network integration with a dedicated, delegated subnet. It does not change how customers reach the app. By default only private traffic is routed into the network; turning on outbound internet traffic routing (route all) sends the app's internet-bound calls through the network too. Combine that with a NAT gateway holding a static public IP on the integration subnet and every outbound call leaves from that one dedicated address, which is what a downstream firewall that only admits known addresses needs. Private endpoints and IP-based SSL never change outbound addresses.

Inbound: private endpoint versus access restrictions. A private endpoint gives the app a private IP in your virtual network, but on its own it does not close the public endpoint. To make an app private-only, add the private endpoint and disable public network access. Access restrictions only filter traffic arriving on the public endpoint; they cannot give the app a private address.

Accepting traffic only from your Front Door. To lock an app to one Azure Front Door profile, add an access restriction that allows the AzureFrontDoor.Backend service tag with an X-Azure-FDID header filter set to your profile's ID. The service tag alone admits every customer's Front Door; the header narrows it to yours. (Private Link from Front Door to the origin is a Front Door Premium feature, so it is not an option on Standard.)

Deployment slots are live apps running in the same plan with their own hostname and configuration, for example a staging slot alongside production. Slots need the Standard tier (up to 5) or Premium (up to 20), and because they share the plan's instances, adding a slot never adds compute.

The point of a slot is the swap. You deploy a new version to staging, test it on the staging hostname, and swap it into production with zero downtime. A swap runs in a fixed order:

1. App Service applies the target slot's (production's) slot-specific settings, such as sticky app settings and connection strings, to the source slot's (staging's) instances, which restarts them.
2. It waits for every source instance to restart and warm up (it sends requests to the app, or to the paths you define for application initialization). If an instance fails, the swap is abandoned and production is untouched.
3. Only then does it switch the routing, so production traffic lands on the already-warm instances.
4. The build that was in production now runs in the source (staging) slot, with staging's settings applied.

Because the old build ends up in staging, rollback is another swap. Swap with preview (multi-phase swap) stops after step 1: the staging code runs with production's settings so you can validate it, and you then complete or cancel the swap before any traffic moves.

Some configuration swaps with the app's content, and some is slot-specific and stays with its slot. You decide for app settings and connection strings by marking them as deployment slot settings (sticky); the rest is fixed by the platform.

Mark environment-specific values, such as a staging database connection string, as slot settings so each environment keeps its own. Note that production's domains, bindings and IP allow list do not travel with the new build; they stay on the production slot and simply serve whatever build is in it.

Managed identities are per slot. Each slot has its own system-assigned identity, and creating a slot with configuration cloned from production does not clone the identity. A Key Vault reference that works in production therefore is denied access from a new slot until you give that slot its own identity and grant it access to the vault.

Testing in production (traffic routing). In the Deployment slots pane you can set a traffic percentage for a slot, for example 10 percent to a staging slot. App Service routes that share of requests arriving on the production URL to the slot, with no change for users and no extra resources. A routed visitor is pinned with the x-ms-routing-name cookie so they stay on the same slot for their session. You can also opt people in or out explicitly with a query string: ?x-ms-routing-name=self sends a visitor back to production, and ?x-ms-routing-name=<slot-name> sends them to that slot, while everyone else keeps the percentage split.