Azure Cloud Compute: Which of the Six Options a Small Team Should Actually Pick

Azure cloud compute is not one service. It is at least six ways to run the same code, from a raw virtual machine you patch yourself to a function that only exists while a request is in flight, and the choice between them is mostly about how much of the operating system you want to be responsible for. For a web app, an API or a background worker, the useful shortlist is three long: App Service if you want a managed runtime and nothing else, Container Apps if you ship a Docker image and want scaling to zero, and a Virtual Machine only when the software genuinely needs a whole box. Everything else on the compute menu exists for workloads a small team does not have yet.

The compute page on any large cloud reads like a catalogue because it is one: every option was built for a customer who needed exactly that shape. This post sorts the Azure options by what you take responsibility for, which is the question that decides the monthly bill and the number of things that can wake you up.

The six compute options, sorted by how much you own
What the responsibility line costs you in practice
Picking for a web app, an API and a worker
The cost shape, without quoting a price list
What you give up by not choosing a hyperscaler
How this fits the rest of the stack
FAQ

The six compute options, sorted by how much you own

Ordered from the most operating-system responsibility to the least:

Virtual Machines. A Linux or Windows box with a public IP. You install the runtime, the reverse proxy, the certificates, the monitoring agent and the security updates. Azure keeps the hardware alive.
Virtual Machine Scale Sets. The same box, cloned behind a load balancer with rules for adding and removing copies. Still your operating system to patch, now in multiples.
Azure Kubernetes Service (AKS). A managed Kubernetes control plane in front of node pools that are, again, VMs you are paying for. Azure runs the control plane; the cluster itself is your problem.
Container Apps. You hand over a container image and a port. Azure runs it on a managed Kubernetes you never see, scales replicas on HTTP traffic or queue depth, and can scale to zero.
App Service. You hand over code or a container, pick a runtime stack, and Azure runs it in a managed environment with deployment slots, TLS and a hostname. No cluster, no node pool.
Functions. Individual handlers that run when triggered by an HTTP request, a timer, a queue message or a blob write. You do not own a process at all, only the code inside the handler.

Batch sits to the side of that list: it schedules large parallel jobs across pools of VMs, which is what it says and nothing more, and it has no bearing on a web application. Treat it as a separate product that shares a menu.

What the responsibility line costs you in practice

The reason to sort by ownership rather than by price is that ownership is where the real cost hides. A VM is often the cheapest line item on the estimate and the most expensive thing on the team’s calendar, because someone has to apply the kernel updates, rotate the certificate, resize the disk when the logs fill it, and notice when the process died at three in the morning. None of that appears on the invoice.

App Service and Container Apps move that work to the platform. You lose the ability to install an arbitrary daemon, tune the kernel, or run two unrelated things on one box, and in exchange the deploy is a push, the certificate renews itself, and a crashed process restarts without a human. For a small team that trade is almost always right, and the moments where it is wrong are obvious: software that needs a GPU driver, a licensed product that insists on a specific OS, or a legacy service that expects to own port 25.

Kubernetes is the option people reach for too early. AKS is a good product, and it is the wrong product for one API and a worker, because the control plane, the node pool minimums, the ingress controller and the monitoring stack add up to a fixed floor before the first request arrives. It earns its place when there are many services, several teams and a platform person to own it.

Picking for a web app, an API and a worker

The common shape for a small product is a frontend, one or two HTTP services, a database and something that runs in the background. Mapping that onto the menu:

Frontend. A static build belongs on static hosting with a CDN in front, not on compute at all. Serving HTML from a VM is paying a server to do what an object store and a cache do better.
HTTP services. App Service if the runtime is a supported stack and you want the simplest possible path. Container Apps if you already build a Docker image, want scale-to-zero for low-traffic services, or need a sidecar. Both give you a hostname, TLS and logs without a proxy to configure.
Worker. Functions for short, event-driven work such as resizing an upload or sending an email when a row changes. Container Apps with a queue-based scaling rule for anything that runs longer than a few minutes or needs a persistent connection.
Database. Not compute. Use the managed database offering rather than running Postgres on a VM, for the same ownership reasons as above.

The trap in this list is the worker. Functions are cheap and pleasant right up to the moment a job needs to run for ten minutes, hold a connection open, or keep state between invocations, at which point the timeout and the cold start turn into bugs. Put anything long-running in a container that stays up.

The cost shape, without quoting a price list

Prices change and vary by region, so the useful thing to know is the shape of each bill rather than a number. A VM is a flat hourly rate for the size you chose, whether or not it does anything, plus disk and outbound bandwidth. App Service is a flat rate for the plan tier, shared across every app on that plan, which makes it cheap for several small apps and awkward for one large one. Container Apps bill on vCPU-seconds and memory-seconds actually consumed, plus requests, so an idle service costs close to nothing and a busy one costs in proportion. Functions on the consumption plan are the same idea at a finer grain.

Two lines surprise people on every provider: outbound data transfer, which is metered per gigabyte once a free allowance is used, and the things that attach to compute, such as the load balancer, the public IP, the log workspace and the container registry. On a small deployment those add-ons can exceed the compute itself. Model them before choosing, not after the first invoice.

A practical way to sanity-check the estimate is to price the same workload as a plain hosted service with a fixed monthly plan, where the vCPU, RAM and bandwidth are on the label. If the per-second cloud estimate comes out several times higher for a service that runs all day anyway, the consumption model is not buying you anything, because you were never going to scale to zero.

What you give up by not choosing a hyperscaler

It would be dishonest to present the simplest option as the best in every case. The large clouds offer regions on every continent, compliance certifications for regulated industries, private networking that spans hundreds of services, and identity integration that a company already running on that vendor will want. If the rest of the organisation lives in that ecosystem, the compute choice is partly made for you, and the right answer is App Service or Container Apps inside it.

For a team that is not in that position, the compute menu is a cost of entry rather than a benefit. Six options, each with its own pricing model, networking model and deployment tooling, is a lot of surface area for a product that needs one API, one worker and a database. A platform that offers a plan ladder with the resources printed on it, deploys from a repository, and hands you logs and rollback covers the same three needs with one decision instead of six.

How this fits the rest of the stack

Whichever compute option wins, the thing to model is the whole stack: the HTTP service, the worker, the database, the storage and the bandwidth, because the compute line is rarely the largest one. The RunxBuild hosting calculator lays those out as separate line items against fixed plan prices, which makes a per-second cloud estimate much easier to sanity-check. If the answer is a container or a Node process that runs all day, a Docker service with autoscaling between two plans you choose is the equivalent of the managed options above, with the price on the label.

Useful related references:

FAQ

What are the main Azure compute services?

Virtual Machines, Virtual Machine Scale Sets, Azure Kubernetes Service, Container Apps, App Service, Functions and Batch. They differ mainly in how much of the operating system and runtime you are responsible for, from a raw VM you patch yourself to a Function where you own only the handler code.

Should I use App Service or a Virtual Machine for a web app?

App Service, unless the application needs something a managed runtime cannot give you, such as a custom daemon, a GPU driver or a specific OS build. App Service handles TLS, hostnames, deployment slots and restarts. A VM gives you all of that to do yourself in exchange for total control.

What is the difference between Container Apps and AKS?

Both run containers on Kubernetes. Container Apps hides the cluster entirely: you provide an image and scaling rules, and it can scale to zero. AKS exposes the cluster, so you manage node pools, ingress and add-ons. AKS suits many services and a platform team; Container Apps suits a few services and no platform team.

When are Azure Functions the wrong choice?

When the work runs longer than a few minutes, needs a persistent connection, or must keep state between invocations. Functions have execution timeouts and cold starts, so long or stateful jobs belong in a container that stays running, with a queue in front if you want scaling.

How is Azure compute billed?

It depends on the service. VMs bill a flat hourly rate for the chosen size whether busy or idle. App Service bills per plan tier shared across apps. Container Apps and consumption-plan Functions bill on resources actually consumed. Outbound bandwidth and attached resources such as load balancers and log workspaces are billed separately on all of them.