Azure App Service: PaaS Web App & API Hosting

Q: App Service or a VM?

Use App Service (PaaS) for web apps and APIs where you want to just deploy code and let Azure manage servers, OS, patching, scaling, and TLS — far less operational burden. Use an Azure VM (IaaS) only when you need OS-level control, specific software, or a workload App Service doesn't support. For most web apps, App Service is faster to production and cheaper to operate.

Q: App Service or Container Apps?

App Service for traditional, always-on web apps and APIs (especially .NET) wanting a simple managed host with features like deployment slots and Easy Auth. Container Apps for containerized microservices wanting scale-to-zero, KEDA event-driven scaling, and a more cloud-native model. Both run containers; App Service is the conventional web-app host, Container Apps the serverless-microservices platform.

Q: How does authentication work in App Service?

Via "Easy Auth" — App Service can handle authentication at the platform level, integrating Entra ID, Google, Facebook, and other providers through configuration, without you writing auth code. Requests are authenticated before reaching your app. It's a quick way to add login, though for complex flows you may still implement auth in your app.

Q: What's the AWS/GCP equivalent?

AWS Elastic Beanstalk (and the newer App Runner) and Google App Engine are the comparable PaaS web-app hosts — deploy code, platform manages infrastructure. App Service is Azure's version, with especially strong .NET support and features like deployment slots. The "just deploy my app" PaaS category exists on every cloud.

Azure App Service

Azure App Service is Microsoft Azure's platform-as-a-service (PaaS) for hosting web applications, REST APIs, and backends — you deploy your code (or a container) and Azure runs it, handling the servers, OS, patching, load balancing, and scaling. It's the "just deploy my app" option: no VMs to manage, no Kubernetes to learn, no infrastructure to configure. It supports .NET, Node.js, Python, Java, PHP, and containers, and remains one of the most popular ways to run a web app on Azure.

App Service sits between raw VMs (full control, full ops burden) and serverless (Functions)/container platforms (Container Apps/AKS) — a managed application host that's simpler than orchestrating containers but gives a persistent, always-on app model. For traditional web apps and APIs, especially in the .NET/Microsoft world, it's often the fastest path from code to running in production. It parallels AWS Elastic Beanstalk / App Runner and Google App Engine.

TL;DR

App Service is PaaS — deploy code or a container and Azure runs it (servers, OS, patching, load balancing, scaling all managed).
Supports .NET, Node.js, Python, Java, PHP, and containers — "just deploy my web app/API."
Runs on an App Service Plan (the underlying compute you pay for); multiple apps can share a plan.
Scaling: scale up (bigger plan) or scale out (more instances, with autoscale rules), including scale-to-zero-ish on some tiers.
Deployment slots — staging environments (e.g. staging) you deploy to, test, and swap into production for zero-downtime releases and instant rollback.
Built-in features: authentication ("Easy Auth" via Entra ID/social), custom domains + free TLS, CI/CD integration, managed identities.
Choose it for traditional/always-on web apps; Container Apps for microservices/scale-to-zero, Functions for event-driven, AKS for full Kubernetes.

Core Concepts

The PaaS Model

You give App Service your application (deployed from git, a CI/CD pipeline, a zip, or a container image), and it handles everything below your code: provisioning compute, the OS and runtime, patching, load balancing across instances, TLS termination, and health monitoring. This removes the VM ops burden (no patching, no server config) while giving a familiar always-on web-app model — unlike serverless functions, an App Service app is a persistent process serving requests.

App Service Plans

An App Service Plan is the compute your apps run on — a set of VMs (abstracted) at a chosen tier (Free/Basic/Standard/Premium/Isolated) defining CPU, memory, features, and price. Key points:

Multiple apps share a plan — cost-efficient for several small apps.
Tier determines features — autoscale, deployment slots, VNet integration, and custom domains/TLS require higher tiers.
Scaling happens at the plan level: scale up (bigger tier) or scale out (more instances, manually or via autoscale rules on CPU/memory/schedule).

Deployment Slots: Zero-Downtime Releases

One of App Service's best features. Deployment slots are live staging environments within an app (e.g., a staging slot alongside production). You deploy a new version to the staging slot, warm it up and test it against production-like config, then swap — the staging slot becomes production instantly, with no downtime, and the old version moves to staging for instant rollback if needed.

This gives blue-green-style deployments with no infrastructure work — a major operational win over deploying directly to production.

Built-In Features

Authentication ("Easy Auth") — add login via Entra ID, Google, Facebook, etc. with configuration, no auth code — authentication offloaded to the platform.
Custom domains + free managed TLS certificates — HTTPS without cert management.
CI/CD integration — deploy from GitHub, Azure DevOps, or GitHub Actions automatically.
Managed identities — connect to SQL Database, Blob Storage, Key Vault without stored credentials.
VNet integration — reach private resources; scaling, health checks, and diagnostics built in.

App Service vs Other Azure Compute

The decision within Azure compute: App Service for traditional web apps and APIs where you want a simple, always-on managed host (especially .NET); Container Apps for containerized microservices wanting scale-to-zero and event-driven scaling; Functions for event-driven/glue code; AKS when you need full Kubernetes. App Service is often the fastest path for a conventional web app; the newer container options fit microservice and serverless architectures better.

Common Mistakes

Deploying Straight to Production (No Slots)

Deploying directly to the production slot means downtime during deploys and no easy rollback. Use deployment slots — deploy to staging, test, and swap for zero-downtime releases with instant rollback. It's a built-in blue-green capability many teams don't use. See deployment strategies.

Oversized or Always-Premium Plans

Running a high-tier plan for a low-traffic app, or one app per plan when several could share, wastes money. Right-size the tier to actual needs, share plans across small apps, and use autoscale rules so you scale out under load and back down when idle. See cloud costs.

Choosing App Service When Container Apps/AKS Fits Better

For a microservices architecture wanting scale-to-zero, event-driven scaling, or Kubernetes portability, App Service's always-on web-app model is a poor fit — Container Apps or AKS suit better. App Service shines for traditional/monolithic web apps and APIs; match the platform to the architecture.

Storing Secrets in App Settings as Plain Values

Putting connection strings and keys directly in app settings is better than in code, but use Key Vault references and managed identities so App Service pulls secrets securely and connects to resources without stored credentials. See secrets management.

Ignoring Cold-Start on Lower Tiers

Some tiers idle out apps (unloading them after inactivity), causing a slow first request. For latency-sensitive apps, use Always On (higher tiers) to keep the app warm. Know your tier's behavior so you don't ship surprise latency.

FAQ

App Service or a VM?

Use App Service (PaaS) for web apps and APIs where you want to just deploy code and let Azure manage servers, OS, patching, scaling, and TLS — far less operational burden. Use an Azure VM (IaaS) only when you need OS-level control, specific software, or a workload App Service doesn't support. For most web apps, App Service is faster to production and cheaper to operate.

App Service or Container Apps?

App Service for traditional, always-on web apps and APIs (especially .NET) wanting a simple managed host with features like deployment slots and Easy Auth. Container Apps for containerized microservices wanting scale-to-zero, KEDA event-driven scaling, and a more cloud-native model. Both run containers; App Service is the conventional web-app host, Container Apps the serverless-microservices platform.

What are deployment slots?

Live staging environments within an App Service app (e.g., a staging slot) that you deploy and test on, then swap into production instantly with zero downtime — and the old version moves to staging for instant rollback. It gives blue-green deployments with no extra infrastructure, one of App Service's standout features for safe releases.

How does authentication work in App Service?

Via "Easy Auth" — App Service can handle authentication at the platform level, integrating Entra ID, Google, Facebook, and other providers through configuration, without you writing auth code. Requests are authenticated before reaching your app. It's a quick way to add login, though for complex flows you may still implement auth in your app.

What's the AWS/GCP equivalent?

AWS Elastic Beanstalk (and the newer App Runner) and Google App Engine are the comparable PaaS web-app hosts — deploy code, platform manages infrastructure. App Service is Azure's version, with especially strong .NET support and features like deployment slots. The "just deploy my app" PaaS category exists on every cloud.