Where should my code run on Azure? App Service vs Functions vs Container Apps vs AKS

Azure has nine general-purpose ways to run code, and four of them cover almost every application a Power Platform or web team builds: App Service, Azure Functions, Container Apps and Azure Kubernetes Service (AKS). Microsoft's own decision tree gets you to a candidate in a few questions; the harder part is knowing the limits and the operational load each one brings before you commit. This guide is the start of our Apps & integration column: the questions, then the tables that decide between the candidates, then where each one goes wrong.

Four questions

Microsoft's compute decision tree splits first on migrate or build new, then on what the workload needs. Reduced to the four services most teams choose between:

1. Are you moving an existing application without changing its code? Lift-and-shift goes to Virtual Machines (or Azure VMware Solution). An existing web app that already runs on a supported stack can usually land on App Service with little change. Microsoft's advice for migrations is like-for-like first; optimise later if budget and time allow.
2. Is the work event-driven: a queue message, a timer, an HTTP call that does one job? That's Azure Functions: functions as a service, scaling to zero, paid per execution, with triggers and bindings that remove most plumbing. Long-running or stateful chains use Durable Functions.
3. Do you ship containers, or many microservices? Container Apps runs containers on Kubernetes without exposing Kubernetes: service discovery, traffic splitting between revisions, scale to zero, jobs, Dapr and KEDA built in. It's where Microsoft points teams who want Kubernetes-style apps without cluster management.
4. Do you need the Kubernetes API itself? Custom operators, a service mesh, node-pool control, GPU scheduling you tune, or a workload that already ships as Helm charts: that's AKS. If you don't need the API, Container Apps is the lower-overhead choice. AKS Automatic narrows the gap by managing nodes, scaling, security defaults and upgrades for you.

App Service is the answer when it's a website, web API or mobile back end and you want the platform to handle hosting. Container Instances, Batch, Azure Red Hat OpenShift and VMware Solution fill narrower needs: a single container on demand, large parallel jobs, OpenShift, and VMware estates.

The four compared

All four are regional services. Active-active or active-passive across regions means one deployment per region plus a router such as Front Door or Traffic Manager in front, whichever you pick.

What each choice invites

App Service. The platform handles the servers, so most trouble is the app's: long requests, memory or CPU pressure, or a crash on start, which show up as 502 and 503 errors; our App Service 502 and 503 guide is the diagnosis flow. Deployment slots are the single best habit: deploy to staging, warm it up, swap, and swap back if it goes wrong. Slots need the Standard tier or above, and virtual network integration needs Basic or above.

Azure Functions. Choose the hosting plan deliberately: Flex Consumption for new serverless apps, Premium for always-warm or long-running work, and remember an HTTP-triggered function has 230 seconds to answer whatever the plan. The .NET in-process model loses support on 10 November 2026 and the Linux Consumption plan retires on 30 September 2028; both have guides in this column (the in-process migration, the hosting plans).

Container Apps. Deployment failures nearly always come from four places: the image can't be pulled, the health probes fail, the ingress target port doesn't match what the container listens on, or the managed identity lacks a role. Our Container Apps deployment failures guide is the symptom table. You don't get the Kubernetes API; if you find yourself needing it, that's the signal to move to AKS, and the containers move unchanged.

AKS. You own upgrades, node pools, networking and security baselines, and Kubernetes versions go out of support on a schedule you must follow: from 1 June 2027, AKS upgrades any cluster that stays on an unsupported version past its grace period, ignoring your maintenance window and pod disruption budgets. Upgrades fail most often on restrictive pod disruption budgets and on capacity for surge nodes; see AKS upgrade failed. Unless you need the control, start with AKS Automatic.

Mixing them

Microsoft's guidance is explicit: evaluate each component separately, and expect a complete solution to use two or more services. The common shapes:

• A web app on App Service, background work on Functions, talking through a queue. The web tier stays responsive; the queue absorbs spikes.
• Microservices on Container Apps, event handlers on Functions, with Functions scaling to zero between bursts.
• A platform team on AKS, product teams on Container Apps, because the Functions programming model and plain containers both run on either, so moving later is a redeploy rather than a rewrite.

For a Power Platform team the first question is usually smaller: a custom connector needs an HTTP endpoint, and Azure Functions behind API Management is the usual answer; our Azure + Power Platform column covers that bridge.

Sources

• Choose an Azure compute service, Microsoft Learn (the decision tree and the comparison tables)
• Choose an Azure compute option for microservices, Microsoft Learn
• Comparing Container Apps with other Azure container options, Microsoft Learn
• Azure Functions hosting options, Microsoft Learn
• Upgrade options and recommendations for AKS clusters, Microsoft Learn (platform-initiated upgrades from 1 June 2027)