Azure VM vs App Service — which should you use?

Same web app, two very different machines to run it on. One hands you the whole box and the bill of responsibilities that comes with it. The other hands you a place to put your code and takes the rest.

New to cloud? CAMPUX is a free, build-first course. Start here →

Choose App Service (PaaS) when you just want to run a web app or API and let Microsoft own the OS, the patching, and the scaling — that's the right default for most web workloads. Choose a Virtual Machine (IaaS) when you need full control of the machine: a custom runtime, a background service, non-HTTP ports, GPU or kernel-level work, or software App Service simply can't host. The honest catch: a VM's lower entry looks simpler, but you inherit every patch, every hardening step, and every 3 a.m. security update for the life of the box.

This is the IaaS-versus-PaaS decision made concrete, inside one cloud, for the one thing beginners build first: a web app that needs somewhere to live. If the abstract layers — infrastructure, platform, software — are still fuzzy, spend ten minutes on the IaaS/PaaS/SaaS class first, then come back. The rest of this note assumes you know the app runs; the question is what it runs on.

The one-line difference

A Virtual Machine is a computer Azure rents you. It boots an operating system you chose, and from the moment it's yours, everything above the hypervisor is your problem: the OS updates, the web server, the runtime, the firewall rules, the certificates, the logging. Azure keeps the physical hardware alive. You keep the machine alive.

App Service is a managed home for a web app. You hand it your code — a container, a zip, a Git push — and it runs on a fleet Microsoft patches, secures, load-balances, and scales for you. You never see the OS. You never apt upgrade anything. You get HTTPS, a deployment slot, autoscale, and health checks as features, not as things you build. In exchange, you give up the ability to do anything the platform doesn't expose.

A VM gives you the whole machine. App Service gives you a place for your app and keeps the machine to itself.

The over-reach that costs beginners

Here is the pattern I watch new engineers fall into, because it's the one I fell into. You come from a world where "get a server" is how you deploy anything. So you spin up a VM, SSH in, install the runtime, configure nginx, open a port, and feel like a real engineer. It works. You ship.

Then the invoice of ownership arrives, and it isn't dollars. It's a Ubuntu security advisory you now have to apply. It's a TLS certificate that expires and takes your site down at midnight because nothing renewed it. It's an open SSH port that a botnet finds within the hour. It's the realization that your "simple" web app now sits on a machine that is entirely your responsibility to keep patched, hardened, and monitored — for a workload that never needed a machine in the first place.

App Service would have given you HTTPS, certificate renewal, patched hosts, and no exposed SSH port on day one, for the same money. The VM didn't buy you power you were using. It bought you a maintenance job you didn't know you'd signed for. That's the tax on reaching for IaaS out of habit — and it's the single most common wrong turn in early Azure work.

VM vs App Service, side by side

When a VM is genuinely the right answer

None of this is "never use a VM." A VM is the correct tool the moment your requirement lives outside what the platform exposes. Reach for IaaS when:

• Your workload isn't an HTTP web app. App Service speaks HTTP and HTTPS, full stop. If you need a service listening on an arbitrary TCP or UDP port, a game server, a message broker, a database engine you're self-hosting — that's a machine, not a web app.
• You need the OS itself. A specific kernel version, a custom driver, GPU compute for training or inference, software that installs system-wide, or a runtime App Service doesn't offer. When you have to touch the operating system, you need to own it.
• You're lifting an existing server into Azure. A legacy app that already assumes a full machine moves fastest onto a VM. Re-platforming it into a PaaS shape is a later project, not a migration-day one.
• You need a persistent background process that isn't a good fit for App Service WebJobs or Azure Functions — long-running, stateful, always-on work that owns its own lifecycle.

For everything else — the CRUD app, the REST API, the marketing site, the internal tool — App Service is the better default. It's not the "beginner" option and the VM the "advanced" one. It's the opposite: reaching for a VM you don't need is the beginner move, and knowing you don't need it is the skill.

How the money compares

People assume the VM is cheaper because you can pick a tiny size. On the sticker, a small VM and a comparable App Service plan land in the same neighborhood per month — the pricing models differ but the order of magnitude doesn't. Where they diverge is total cost of ownership. The VM's real price includes the hours you spend patching, hardening, wiring up deployment, and building the scaling that App Service ships for free. That labor is invisible on the invoice and very visible in your week.

There's also a floor difference worth knowing. App Service has a free tier that will host a small, low-traffic app indefinitely — useful for a portfolio project or a demo. A VM has no permanent free equivalent; past the 12-month intro allowance and the standard $200 / 30-day new-account credit, a running VM bills for every second it's on, idle or not. If cost is the whole question for a tiny project, the managed tier usually wins. Prices and tiers shift — check the Azure pricing calculator before you commit, and if you're comparing across clouds, our cheapest cloud for small projects teardown goes deeper than I will here.

Certified vs. actually being able to choose

Every cert curriculum can define IaaS and PaaS. Far fewer teach you to make this call under real constraints — where the wrong choice shows up months later as a patching backlog or a bill nobody can explain. The job-ready skill isn't reciting that App Service is "platform as a service." It's walking into a design conversation and saying "this is a plain web API, it goes on App Service, and here's the one requirement that would change my mind." That sentence is worth more than the definition, and it's the thing we drill. Build the muscle properly in the compute class, then get hands-on with each in App Service and Virtual Machines — deploy the same app both ways once, and the decision stops being abstract.

Common questions