Choosing an Azure compute service

Updated October 9, 2026

Pick the Azure compute service that takes over the most work you do not need to control. Virtual Machines for full OS control or lift and shift, App Service for web apps and APIs, Functions for event-triggered code, Container Apps for containers without Kubernetes, and AKS when you need the Kubernetes API itself. The decision rule is a ladder: start at the managed end and move toward more control only when a requirement forces it, such as a custom OS, a Kubernetes-specific tool, or a legacy installer.

The ladder: what you give up at each step

Microsoft groups these services by hosting model. Virtual Machines are infrastructure as a service (IaaS): you manage the VM, Microsoft manages the hardware. App Service and Container Apps are platform as a service (PaaS): you deploy an app and the platform manages the servers. Functions is functions as a service (FaaS), where you deploy code and the service runs and scales it. More control costs more operations, and Microsoft’s guide rates operational overhead as high for VMs and AKS, low for App Service and Container Apps, and very low for Functions.

ServiceYou deployYou manageScalesChoose it when
Virtual MachinesAnythingOS, patching, runtime, networking inside the VMVirtual machine scale setsLift and shift, custom OS, software that needs an installer or specific drivers
App ServiceWeb apps, APIs, containersApp and settings, not serversBuilt-in autoscaleStandard web app or API, deployment slots, steady traffic
FunctionsFunctions (or containers)Code onlyServerless on Consumption and Flex Consumption plansShort event-driven work: queue messages, timers, HTTP triggers
Container AppsContainersContainer image and scale rulesServerless, scale rules, can scale to zeroMicroservices and jobs in containers, event-driven scale, no Kubernetes admin
AKSContainers via Kubernetes manifestsCluster configuration, upgrades, node pools (AKS Automatic takes over much of this)Pod and cluster autoscalingYou need the Kubernetes API, custom controllers, or an existing Kubernetes toolchain

Container Apps runs on Kubernetes but, per Microsoft, does not give you direct access to the Kubernetes APIs. If a requirement mentions kubectl, Helm charts of a specific operator, or the control plane, the answer is AKS. If the requirement says “without managing Kubernetes”, the answer is Container Apps. Azure Container Instances is the low-level building block: it runs a container group on demand but has no scaling, load balancing or certificates of its own.

Worked example: five workloads, five answers

  1. A company’s licensed accounting package, installed with a Windows installer, must move to Azure unchanged. Virtual Machines. Nothing else runs an arbitrary installer, and lift and shift means no code change.
  2. A new customer portal in .NET with a staging environment and a swap before release. App Service. Deployment slots are an App Service and Functions feature, and the team wants no server work.
  3. Every time a file lands in storage, resize an image. Functions. It is short, event-triggered and billed on execution rather than on a running server.
  4. Twelve containerized microservices; some should scale to zero, others scale on queue length; the team has no Kubernetes experience. Container Apps, which scales on rules such as queue depth.
  5. A platform team that already runs Helm charts and a service mesh and needs custom Kubernetes resources. AKS, because only AKS exposes the Kubernetes API and control plane.

The pattern: read the noun (installer, web app, event, microservice, cluster) and the verb that constrains it (unchanged, swap, scale to zero, custom).

Constraints that change the answer

  • Network integration. All of these support virtual network integration, but on App Service it needs the Basic tier or higher, and on Functions it needs an App Service plan, the Premium plan or Flex Consumption. A scenario with a private database and a Functions app on the Consumption plan is a trap.
  • Multiple regions. Per Microsoft’s guide, every one of these services is regional. Multi-region needs a separate deployment per region plus a router; see Azure load balancing options.
  • Stateful versus stateless. App Service is described as stateless; Functions is stateless unless Durable Functions is used; VMs, AKS and Container Apps can run stateful workloads.
  • Cluster size. Microsoft recommends six nodes for production AKS (three system, three user), which matters for cost questions with a handful of tiny services.
  • Availability design. Zones and sets apply to VMs; see availability sets vs zones.

Which exams test this

ExamHow it appearsCovered on this site
AZ-104Deploy and manage Azure compute resources: create VMs and scale sets, provision containers with Container Instances and Container Apps, and configure App Service plans, scaling and deployment slots. Configuration rather than choosing; AKS and Functions are not namedCompute resources
AZ-305Design infrastructure solutions: specify compute components for workload requirements and recommend a VM-based, container-based, serverless or batch compute solutionInfrastructure solutions
AZ-900Describe Azure architecture and services: compare compute types (containers, VMs, functions) and describe application hosting optionsArchitecture and services
AI-200Develop containerized solutions on Azure: deploy to App Service, Container Apps and AKS. Connect to and consume Azure services: build and deploy Azure FunctionsContainerized solutions, Connect to Azure services

How questions are built

AZ-305 style questions give a business paragraph and ask for the service that meets every requirement with the least administrative effort. Words that decide:

  • “Least administrative effort”, “no infrastructure management”: PaaS or FaaS, never VMs.
  • “Lift and shift”, “no code changes”, “custom software installation”: Virtual Machines.
  • “Event-driven”, “runs only when triggered”, “pay per execution”: Functions.
  • “Scale to zero”, “microservices”, “without Kubernetes expertise”: Container Apps.
  • “Kubernetes API”, “custom operators”, “kubectl”, “Helm”: AKS.
  • “Deployment slots”, “web app”: App Service.

Teams that outgrow a choice often move up one rung rather than start over, since App Service, Container Apps and Functions can all run containers. For the Kubernetes rung in depth, see Kubernetes and AKS basics and Docker basics; pipelines that deploy to any of them are in CI/CD explained.

Practice questions

Question 1. A team has twenty containerized microservices. Several must scale based on the length of a message queue and scale to zero when idle. The team has no Kubernetes experience and does not need access to the Kubernetes API. Which service minimizes administrative effort?

  • A. Azure Kubernetes Service
  • B. Azure Container Apps
  • C. Azure Virtual Machines with a scale set
  • D. Azure App Service
Show answer

Answer: B

Azure Container Apps is a managed container platform with scale rules, including queue-based scaling and scale to zero, and it hides Kubernetes management. AKS would meet the scaling need but requires cluster administration and is chosen when Kubernetes API access is required. Virtual Machines require the team to manage the OS and orchestration. App Service is optimized for web apps and does not scale to zero on queue length in the same way.

Question 2. A company must move a commercial application that ships with a Windows installer and a custom device driver to Azure without changing the application. Which compute service should you choose?

  • A. Azure App Service
  • B. Azure Functions
  • C. Azure Container Apps
  • D. Azure Virtual Machines
Show answer

Answer: D

Installing software with its own installer and driver needs control of the operating system, which only Virtual Machines (IaaS) provide, and lift and shift means no redesign. App Service and Functions run code on a managed platform where you cannot install drivers. Container Apps requires the application to be containerized, which is a change to the application.

Go deeper