Azure App Service: Managed PaaS for Web Apps, APIs, and Mobile Backends

Running a web application requires an HTTP server, a runtime, OS patches, TLS certificate renewal, load balancer configuration, and autoscaling logic. Azure App Service handles all of that so your team ships features instead of managing infrastructure. You bring the code; the platform handles everything underneath.

App Service supports .NET, Java, Python, Node.js, PHP, and Ruby, as well as custom containers via Docker. The same service can host a public-facing website, an internal REST API, or a WebJobs background worker — all under one billing umbrella called an App Service Plan.

Real-World Scenario

A logistics company has a Django-based customer portal and a separate .NET microservice for shipment tracking. Both need HTTPS, custom domains, deployment pipelines, and the ability to scale during peak shipping seasons. Running them on App Service means the team manages two web apps within one Standard-tier Plan, shares the compute cost, and uses deployment slots to validate every release in a staging environment before a zero-downtime swap.

App Service Plans: The Billing Unit

An App Service Plan defines the compute resources (CPU, RAM, number of workers) that all apps in the plan share. Tier determines what features are available:

App Service Plan Tiers
----------------------
Free / Shared
  - Shared multi-tenant workers
  - No custom domains with SSL
  - No autoscale, no VNet

Basic
  - Dedicated workers
  - Custom domains + TLS
  - Manual scale up to 3 instances

Standard
  - Autoscaling (up to 10 instances)
  - Deployment slots (5 per app)
  - Daily backups, Traffic Manager support

Premium v3
  - Faster hardware, up to 30 instances
  - VNet Integration, Private Endpoints
  - Zone redundancy available

Isolated v2 (App Service Environment)
  - Single-tenant dedicated environment
  - Injected directly into your VNet
  - Required for max network isolation

Choosing the right tier matters more than raw instance count. A team that needs VNet Integration must be on Premium or Isolated — Standard does not offer it.

Deployment Slots

Deployment slots are live staging environments that share the same App Service Plan compute but run a separate instance of the application. The canonical pattern is:

Deployment Pipeline With Slots
-------------------------------
Code Push
    |
[GitHub Actions / Azure DevOps]
    |
Deploy to "staging" slot
    |
Run smoke tests, integration tests
    |
Swap staging <--> production (zero downtime)
    |
If issue detected: swap back (rollback in seconds)

Slot swap is atomic — Azure drains existing connections on the old production slot, then redirects new traffic to the new slot. Settings marked as “slot-specific” (like connection strings pointing to different databases) stay with the slot and do not follow the swap.

Autoscaling

App Service autoscaling works at the Plan level, not the app level. You define rules based on metrics or a schedule:

Scale-out rule:
  Metric: CPU percentage > 70% for 5 minutes
  Action: Add 2 instances
  Cooldown: 5 minutes after scale event

Scale-in rule:
  Metric: CPU percentage < 30% for 10 minutes
  Action: Remove 1 instance

Schedule override:
  Every Friday 17:00 UTC -> scale to minimum 3 instances
  Every Saturday 02:00 UTC -> return to auto mode

For unpredictable traffic spikes, HTTP queue length is often a better trigger than CPU because CPU reacts after the queue has already backed up.

VNet Integration and Private Endpoints

By default, App Service apps reach the internet via shared outbound NAT IPs. VNet Integration allows outbound traffic from the app to flow through a subnet in your VNet, so it can reach private resources like a SQL Managed Instance or an internal API without public exposure.

Outbound (VNet Integration)
  App Service App
       |
  VNet Integration subnet (delegated to Microsoft.Web)
       |
  Your VNet (10.0.0.0/16)
       |
  Private resources (SQL, Storage, Redis)

Inbound (Private Endpoint)
  Client in VNet
       |
  Private Endpoint in your subnet
       |
  App Service (no public endpoint required)

For full private access in both directions — no public internet exposure at all — combine Private Endpoints (inbound) with VNet Integration (outbound) and disable the public SCM and app endpoints.

Custom Domains and Managed TLS

Adding a custom domain takes three steps:

Add a CNAME or A record in your DNS zone pointing to the App Service default hostname.
Register the domain in the App Service custom domains blade.
Create a managed certificate (free) or upload your own.

Azure’s App Service Managed Certificates auto-renew every 180 days with no manual intervention. For wildcard certificates or certificates shared across multiple apps, upload a PFX to a Key Vault and reference it via App Service certificate binding.

Deploying a Python API to App Service

# Create the plan (Linux, Premium v3)
az appservice plan create \
  --name api-plan \
  --resource-group prod-rg \
  --sku P1V3 \
  --is-linux

# Create the web app
az webapp create \
  --resource-group prod-rg \
  --plan api-plan \
  --name shiptrack-api \
  --runtime "PYTHON:3.11"

# Deploy from local source
az webapp up \
  --resource-group prod-rg \
  --name shiptrack-api

# Create a staging slot
az webapp deployment slot create \
  --resource-group prod-rg \
  --name shiptrack-api \
  --slot staging

# Swap staging to production
az webapp deployment slot swap \
  --resource-group prod-rg \
  --name shiptrack-api \
  --slot staging \
  --target-slot production

Architecture Overview

[Users / Internet]
        |
  [Azure Front Door]  <-- global WAF + CDN
        |
  [App Service (production slot)]
  [App Service (staging slot)]     <-- internal only
        |
  [VNet Integration subnet]
        |
  [Azure SQL Database]  [Azure Redis Cache]
  (private endpoints)   (private endpoints)

Key Interview Points

Plan vs. App: The Plan is the billing and compute boundary. Multiple apps share one Plan. Scale rules apply to the Plan, affecting all apps on it.
Deployment slot swap mechanics: Traffic switches instantaneously. Session-affinity cookies help in-flight user sessions stay on the original instance during the warm-up period before swap completes.
Free managed TLS: App Service Managed Certificates are free for apex and subdomain records but do not support wildcard domains.
VNet Integration vs. Private Endpoint: VNet Integration is for outbound (app calling private resources). Private Endpoint is for inbound (clients in a VNet calling the app).
Scaling limits by tier: Free and Shared tiers share compute across Microsoft’s fleet — you cannot guarantee isolation. Standard allows dedicated workers and up to 10 instances. Premium v3 extends to 30.
WebJobs: Background tasks run alongside the web app in the same compute, triggered on a schedule or continuously, without needing a separate Azure Functions plan.

Best Practices

Use deployment slots for every production release — not just major versions.
Store secrets in Azure Key Vault and reference them via Key Vault references in app settings, not as plain-text values.
Enable Application Insights in the app for distributed tracing across API calls.
Set WEBSITE_RUN_FROM_PACKAGE=1 to deploy as an immutable package rather than extracting files to disk, which speeds startup and prevents partial file states.
Configure health check endpoints so App Service detects unhealthy instances and routes traffic away before your users notice.
Restrict SCM (Kudu) access to your deployment IP ranges using IP restrictions.