App Service
App Service is a managed platform for web apps, REST APIs, and mobile backends. You deploy code in a supported runtime — .NET, Node, Python, Java, PHP — or a container, and Azure provides the host, TLS, load balancing, autoscaling, and deployment slots. You manage the application; Azure manages the platform under it.
It is the pragmatic default for a conventional web application on Azure: less operational surface than a VM or AKS, more structure than a raw function. The main decisions are which plan tier backs it and how you use slots to deploy without downtime.
App Service Plans
An App Service plan is the set of VMs your apps run on, and it is what you pay for. Tiers range from Free and Basic through Standard, Premium, and Isolated, differing in CPU, memory, instance count, and features like autoscale and VNet integration. Multiple apps can share one plan — convenient, until they contend for the same CPU and become noisy neighbors.
Scaling up means a bigger plan tier — more CPU and memory per instance. Scaling out means more instances of the same tier, available from Standard upward. Autoscale, which adjusts instance count by metric or schedule, requires Standard or higher; the Basic tier scales only by hand.
Deployment Slots
A deployment slot is a live, addressable copy of the app — typically a staging slot — with its own hostname and configuration. You deploy to staging, warm it up, verify it, then swap it with production. The swap is a routing change, so it is near-instant and reversible: if production breaks, you swap back.
Swap-with-warmup sends initialization requests to the staging instances before the swap completes, so production never serves a cold instance. This is blue-green deployment without DNS changes or a second environment to manage, and it is one of the strongest reasons to choose App Service.
Scaling
Scaling out is governed entirely by the plan tier — the Free and Basic tiers cannot autoscale, and the per-tier instance ceiling caps how far you can grow. A common surprise is hitting that ceiling under load because the app was left on a tier that was never meant to scale.
Networking and Identity
VNet integration lets an app reach private resources — a database with no public endpoint, a service behind a private endpoint — and is available on the Basic tier and higher. A managed identity lets the app authenticate to Key Vault and other services with no stored secrets, and Key Vault references let app settings resolve a secret at runtime instead of holding it in plain text.
App Service — A managed host for a conventional web app or API, code or container. Choose it for a standard long-running web workload that does not need raw Kubernetes.
Container Apps — Serverless containers that scale to zero with event-driven scaling. Choose it for microservices, event consumers, and bursty container workloads.
Functions — Per-event execution that scales to zero. Choose it for short, event-triggered tasks rather than a continuously running app.
- Packing many apps onto one undersized plan — they share CPU and memory, and one busy app starves the rest.
- Deploying straight to production instead of to a staging slot, giving up the instant, reversible swap that App Service makes free.
- Expecting autoscale on the Basic tier — autoscale starts at Standard, and Basic scales only manually.
- Storing connection strings and secrets in app settings as plain text instead of using Key Vault references with a managed identity.
- Leaving Always On off for an app that does background work or must respond instantly — the app unloads when idle and the next request pays a cold start.
- Hitting the per-tier instance ceiling under load because the app was left on a tier never sized to scale.
- Deploy to a staging slot and use swap-with-warmup so production never serves a cold instance.
- Size the plan tier for the workload and avoid crowding unrelated apps onto one plan.
- Use Standard or higher and configure autoscale by metric or schedule for production traffic.
- Reference secrets from Key Vault via a managed identity instead of storing them in app settings.
- Enable Always On for apps with background jobs or strict response-time needs.
- Use VNet integration to reach private databases and services rather than exposing them publicly.
Knowledge Check
What does a deployment slot swap give you that deploying directly to production does not?
- A near-instant, reversible cutover after warming up the new version in staging
- A permanent second production environment running at no extra cost
- Automatic horizontal autoscaling on every plan tier, including the entry-level Basic tier
- Free VNet integration on the Basic tier
An app on the Basic plan tier will not autoscale under load. Why?
- Autoscale requires Standard or higher; Basic scales only manually
- Autoscale requires a container image deployment rather than deployed code
- Basic supports only a single deployment slot per app
- Autoscale is disabled whenever Always On is off
Which workload is the best fit for App Service over Container Apps or Functions?
- A conventional, continuously running web app or REST API
- A short task triggered by a single queue message
- A bursty event consumer that should scale to zero when idle
- A batch job that runs to completion and exits
You got correct