Azure App Service is a managed platform for web applications and HTTP APIs. Azure operates the underlying hosts and runtime integration while you manage code, configuration, identity, networking, scaling, deployment, monitoring, and data. Deployment slots let supported plans warm and validate a release before swapping it into production.
Lab: 40 minutes · Cost: the App Service plan is billed while allocated; custom domains, certificates, networking, and logs can add cost · Cleanup: delete the lab resource group.
The plan supplies regional compute capacity and pricing tier. One or more apps run on that plan. The web app owns hostname, runtime, configuration, identity, deployment, and application settings. Apps on the same plan share capacity and failure/cost boundaries.
Use separate plans when workloads require independent scaling, isolation, region, operating system, or cost ownership.
Ways to build
Choose the Azure tool you want to use. The underlying resource stays the same.
Search App Services → Create → Web App. Choose code or container publishing, runtime stack, operating system, region, plan, and pricing tier. After deployment:
A slot is a live app with its own hostname. Deploy to staging, run health and smoke tests, warm caches, then swap. Mark environment-specific settings as deployment slot settings so database endpoints and secrets do not cross environments during swap.
A swap is not a database rollback. Use backward-compatible schema changes and an independent data migration plan.
Inbound private endpoint and outbound VNet integration solve different directions. Do not assume enabling one provides the other.
Declare the plan, web app, identity, application settings (without plaintext secrets), health check, private endpoint, DNS, VNet integration, diagnostics, alerts, and slot. Terraform equivalents are azurerm_service_plan, azurerm_linux_web_app, slot resources, role assignments, and private networking.
Use what-if or terraform plan, then deploy through a protected environment with approval for production.
Scale up by choosing a larger tier; scale out by increasing instances. Autoscale on meaningful signals and set minimum instances for availability. Keep the app stateless, store sessions externally, handle graceful shutdown, use retries with jitter for transient dependencies, and set timeouts.