App Service and Azure Functions

An App Service plan is the set of compute resources (VM size, region, OS) that one or more Web Apps run on; the plan’s tier determines its features and scaling limits, while its SKU (size) determines its VM size within that tier. The tiers a new reader is most likely to choose among:

A Web App is the application resource that runs on an App Service plan. It can run from source code that the platform builds for a supported language runtime, or from a container image — either way, az webapp up and az webapp create are the two entry points, aimed respectively at a quick source-code deploy and an explicit, scriptable create.

az webapp up inspects the current directory, infers a runtime stack (or an already-built container context), and creates whatever is missing (resource group, App Service plan, Web App) in one command — convenient for a first deploy or a demo, less suitable for a repeatable pipeline because it makes naming and sizing decisions on the reader’s behalf:

az webapp create is the explicit form, used once the plan already exists (as created above) and the image or runtime is known ahead of time. For a container image, --container-image-name names the image (optionally with a registry prefix and tag); the older --deployment-container-image-name and --docker-custom-image-name flags are deprecated in favor of it:

Pulling a private image from acrbookshelf needs credentials; the recommended path is a managed identity with AcrPull rather than the registry’s admin username/password, matching the identity-based pattern covered in Identity and Access and Azure Container Registry:

A deployment slot is a separate, fully live instance of a Web App — with its own hostname — running under the same App Service plan. The usual pattern is a staging slot that receives a new deployment and warms up while production keeps serving traffic, followed by a swap that exchanges the two slots' routing (and, depending on configuration, their app settings) with no cold start on the side that becomes production. Standard tier and above support up to five slots (Premium adds more); Basic and below support none.

References: Set up staging environments in Azure App Service, az webapp deployment slot reference.

Autoscale (in Standard tier and above) adds or removes instances of a plan based on metric rules (CPU percentage, memory, HTTP queue length) or a schedule, within a configured minimum/maximum instance count. It is the App Service equivalent of the scaling rules covered for Container Apps in Container Apps: Scaling, Jobs and Dapr, applied at the plan level rather than per container revision.

A Linux Web App can run one or more sidecar containers alongside the main application container — for a log shipper, a service-mesh proxy, or a local cache — sharing the same network namespace so the sidecar reaches the main container over localhost. This is the same shape of problem Container Apps solves natively (see Container Apps); App Service’s sidecar support exists for workloads already committed to App Service that need one auxiliary process without moving the whole application to Container Apps.

App Service’s built-in authentication and authorization feature — commonly called Easy Auth — lets a Web App require sign-in and validate tokens at the platform level, before a request reaches the application code, using Microsoft Entra ID or another OpenID Connect/OAuth2 identity provider. In the current portal this is the Authentication blade (an older configuration surface remains reachable as Authentication (Classic) for apps that already used it); this page introduces it only as it applies to App Service and Functions, since Identity and Access already covers Microsoft Entra ID, app registrations and service principals in depth.

Azure Static Web Apps hosts a static front end (built by a CI workflow it generates, typically GitHub Actions or Azure Pipelines) together with an optional serverless API backed by Azure Functions, fronted by a global CDN with free managed TLS certificates. Two tiers exist: Free, for personal projects and evaluation with no SLA, and Standard, billed per app with an SLA and higher bandwidth/custom-domain limits, intended for production workloads. This page does not develop Static Web Apps further — it is a distinct product from App Service Web Apps, aimed specifically at static/JAMstack front ends rather than general server-side applications.

An Azure Functions app is a set of individually invoked functions, each started by exactly one trigger (HTTP request, a message landing on a Service Bus queue/topic, a timer schedule, a new blob, a Cosmos DB change feed entry, and others) and optionally reading or writing data through input and output bindings (a Cosmos DB document, a Storage queue message, a SignalR message) declared rather than hand-written against each service’s SDK. Bindings are what let a function connect to Service Bus, Cosmos DB or Storage with a few lines of declarative configuration instead of the client-construction code shown for those SDKs elsewhere in this section.

Three hosting plans back a Function App, trading cold-start behavior and always-on cost against scaling control:

Flex Consumption is the current, generally available recommendation for new event-driven Function Apps that want scale-to-zero economics without the classic Consumption plan’s cold-start and concurrency limitations; the classic (non-Flex) Consumption plan on Linux is retiring on 30 September 2028 and Microsoft’s guidance is to create new apps on Flex Consumption rather than classic Consumption from this point on. Premium remains the right choice when every invocation must run inside a virtual network with no cold start at all and a steady baseline load justifies always-on billing; Dedicated fits a Function App that must share an existing App Service plan’s already-provisioned capacity with a Web App.

Azure Functions for .NET has historically offered two hosting models for function code: the in-process model (function code runs inside the same process as the Functions host) and the isolated worker model (function code runs in its own worker process, communicating with the host over gRPC). Support for the in-process model ends on 10 November 2026 — apps on it keep running afterward but stop receiving security and feature updates — so any assumption that in-process is the default or the simpler option no longer holds: the isolated worker model is Microsoft’s current recommendation for every new .NET Function App, and existing in-process apps should migrate before that date. Non-.NET language workers (Java, Node.js, Python, PowerShell) are unaffected by this distinction; the isolated worker model is specific to .NET’s two hosting modes.

The isolated worker model’s practical differences: full control over the dependency-injection container and middleware pipeline (rather than reusing the host’s own), support for .NET versions the in-process model cannot run (including .NET versions released after the .NET the Functions host itself targets), and a small amount of manual model binding that the in-process model previously handled implicitly through the host’s own types.

References: Differences between in-process and isolated worker process .NET Azure Functions, Guide for running functions on .NET in the isolated worker model.

Durable Functions is an extension that lets an orchestrator function coordinate multiple other functions as a stateful workflow, checkpointing progress so the orchestration survives process restarts and scale events without the application managing that state itself. In the isolated worker model, an orchestrator takes a TaskOrchestrationContext parameter (from the Microsoft.DurableTask package) and calls activities through it (context.CallActivityAsync<T>(…​)) instead of the in-process model’s IDurableOrchestrationContext; the orchestrator function itself must remain deterministic (no direct I/O, no DateTime.Now, no unmanaged randomness) since the platform may replay it from its checkpointed history.

The recurring patterns, all expressed the same way in the isolated worker model:

References: Durable Functions overview, Function chaining pattern, Fan-out/fan-in pattern scenarios, HTTP APIs in Durable Functions, Monitor pattern, Human interaction pattern.

Both App Service and Functions can connect to Storage, Service Bus, Event Hubs, and several other bindings using a managed identity instead of a connection string, matching the credential-chain pattern already covered in Identity and Access. For Functions specifically, the trigger/binding configuration references an identity-based connection by a settings prefix instead of embedding a secret:

Not every trigger/binding type supports identity-based connections yet (a handful of third-party or legacy bindings still require a connection string), so check the specific binding’s reference page before assuming the pattern above applies unmodified.

References: Configure an identity-based connection, Tutorial: connect to host storage with an identity instead of a secret.

Azure Functions Core Tools (func) runs the Functions host locally for development and testing, and drives deployment from a developer machine or CI runner:

local.settings.json holds local-only configuration (connection strings, AzureWebJobsStorage for local development) and must never be committed — it is excluded by the scaffolded .gitignore by default.

References: Develop Azure Functions locally using Core Tools, Azure Functions Core Tools repository.

A Function App can also run as a container hosted directly on Azure Container Apps (via the Microsoft.App resource provider, setting kind=functionapp on the Container App) rather than on one of the three Functions- specific plans above — the same triggers and bindings apply, but scaling, networking and observability follow Container Apps' own model (KEDA-driven scaling rules, Dapr, revisions) instead of the Functions host’s built-in scale controller. This is the right choice when a function genuinely needs to run alongside other Container Apps workloads in the same environment (sharing a virtual network, Dapr components, or a scaling rule vocabulary already used elsewhere) — Container Apps and Container Apps: Scaling, Jobs and Dapr cover that platform’s own concepts in depth, and Deploying Microservices on AKS covers the further step of running comparable event-driven workloads directly on AKS.

References: Azure Functions on Azure Container Apps overview, Azure Container Apps hosting of Azure Functions.

Quarkus applications reach some of the same serverless/event-driven ground covered here (functions, cold-start optimization, deploying to a FaaS platform) from the JVM side; see Serverless and Cloud Functions. ASP.NET Core applications deployed as Web Apps rather than Functions follow the deployment concerns (publish profiles, containers, CI/CD) covered in Deployment, which this page does not repeat.