Azure IaaS vs PaaS vs SaaS, explained with the decisions they force
The three service models are an exam question with a tidy answer and a working question with a messy one. Here is both: what you rent versus what you run, then the two decisions that actually come up — a VM or App Service, and whether to move what you already have.
New to cloud? CAMPUX is a free, build-first course. Start here →
The three models differ by how much of the stack the provider runs. Infrastructure as a service hands you a machine and leaves the operating system, runtime and scaling to you. Platform as a service hands you a runtime and keeps the machine. Software as a service hands you a finished product. Everything else — the examples, the pricing, the interview answer — falls out of that one line.
What you rent versus what you run
The useful version of this is not a definition, it is a table of who owns which layer when something breaks at 2am.
| Layer | IaaS — a virtual machine | PaaS — a managed service | SaaS — finished software |
|---|---|---|---|
| Datacentre, network, hypervisor | Azure | Azure | Azure |
| Operating system and patching | You | Azure | Azure |
| Runtime and middleware | You | Azure | Azure |
| Scaling and availability | You — scale sets, load balancer, zones | Mostly Azure, built in | Azure |
| The application | You | You | Azure |
| Your data | You | You | You |
Read the last row before anything else. Your data is yours in all three models. That is the half of the shared-responsibility model people forget when they assume a managed service means someone else is responsible for a leak. Moving up the stack buys you less to maintain, not less accountability.
The same website, at three heights
One example makes the models concrete. Say you need a company website with a contact form.
On infrastructure as a service you create a virtual machine, install a web server, configure the firewall, install a TLS certificate, set up log rotation, patch the operating system monthly, and build a scale set with a load balancer if traffic ever justifies it. You control everything, including the ability to install anything you like — and you own every one of those chores forever.
On platform as a service you deploy the site to App Service and set a custom domain. The certificate, the operating system, the web server and the patching are Microsoft's problem. Scaling is a slider or a rule. You gave up the ability to install arbitrary software on the host, and in exchange you gave away most of the maintenance.
On software as a service you sign up for a hosted site builder and write your content. There is no deployment at all, and no engineering — you configure what the vendor allows and nothing else.
The decision that actually comes up: a VM or App Service
Nobody in a real job asks "should this be IaaS or PaaS" in the abstract. They ask whether this thing goes on a virtual machine or on App Service, and the answer has a strong default.
| Azure Virtual Machine | Azure App Service | |
|---|---|---|
| What you manage | Operating system, patching, runtime, web server, firewall, certificates, logging, backups — everything above the hypervisor. | Your code and its configuration. Microsoft owns the operating system, host patching, TLS and the platform. |
| Scaling | You build it: scale sets, a load balancer, health probes, and the automation to add or remove instances. | Built in. Scale up to a bigger plan or out to more instances with a rule. |
| Cost model | Pay for the VM size per second it runs, plus disks and egress, busy or idle. No permanent free tier. | Pay for the plan tier. A genuinely free tier exists for small, low-traffic apps; paid tiers add scale, slots and custom domains. |
| Deployment | Yours to build: remote in, or an image plus configuration management to make it repeatable. | Push from a repository, deploy a zip or a container, or wire CI/CD in a few clicks. Deployment slots give zero-downtime swaps. |
The over-reach that costs beginners is reaching for a VM because it feels like "real" infrastructure. It is the option with the most homework.
A virtual machine is genuinely the right answer when you need to install software the platform will not host, when the application depends on a specific operating system configuration, when a legacy component expects a real filesystem or a fixed drive letter, when licensing is tied to a machine, or when you are lifting something as-is and have no appetite to re-architect it yet. Those are real cases and they are not rare. They are just far less common than the number of VMs people deploy.
The PaaS services worth knowing by name
| What you are hosting | Service | Use it when |
|---|---|---|
| Web apps and APIs | App Service | A standard web app or API in a supported runtime, deployed, patched and auto-scaled without touching a server. |
| Event-driven code | Azure Functions | Code runs in short bursts on a trigger — an HTTP call, a queue message, a schedule — and you want to pay for runs rather than idle time. |
| Front ends | Static Web Apps | A front-end build plus a light API, with global hosting and deployment from your repository baked in. |
| Containers, no cluster | Container Apps | You containerized the app but do not want to run and patch Kubernetes. Scale to zero, built-in ingress, no control plane to babysit. |
| One-off containers | Container Instances | A single container running fast for a job or a burst, with no orchestration at all. |
| Relational data | Azure SQL or a managed open-source database | You want backups, patching and high availability handled rather than an engine to maintain. |
Moving what you already have: the IaaS-to-PaaS map
Most real estates are not a clean choice between models — they are a set of virtual machines somebody stood up years ago, and the question is which of them are worth moving. This is the mapping worth having, with the trade in both directions.
| What you have | Where it goes | What you gain | What you give up |
|---|---|---|---|
| Web server on a VM | App Service | No operating-system patching, built-in autoscale, deployment slots for zero-downtime releases, TLS and custom domains handled | No box to remote into; must run on a supported runtime; some server-level configuration and installed software is off the table |
| SQL Server on a VM | Azure SQL Database or Managed Instance | Automated backups, patching and high availability; point-in-time restore; no engine to maintain | Managed Instance narrows the gap, but some surface — agent jobs, cross-database queries, CLR — is limited or absent on the plain database |
| A scheduled-task VM | Functions on a timer trigger | Pay only when the job runs, rather than billing an idle VM around the clock for a midnight script | Execution-time limits on the consumption plan; long-running jobs need a premium plan or a rethink; cold starts on first invoke |
| A file share on a VM | Azure Files or Blob Storage | Durable, redundant storage priced per gigabyte; no disk to grow or back up | The app must use the storage API or a mounted share; assumptions about a local filesystem may need code changes |
The honest when-not-to: do not move something that is about to be retired, do not move a system nobody understands well enough to test properly, and do not move during a freeze or a peak season. A migration that saves forty pounds a month and burns a fortnight of engineering time and an outage was not a saving. Start with the machine that is costing the most or breaking the most, prove the pattern once, then repeat it.
The cost trade, stated honestly
Managed services usually look more expensive per hour and are usually cheaper in total, because the hourly rate is the only part of a VM's cost that appears on the invoice. The rest — the patching window, the person who holds the certificate renewal in their head, the scale set nobody has tested, the 2am page — is paid in engineering time and does not show up next to the compute line. That is the argument for platform services, and it is a real one.
It is not universal. At sustained high scale, a fleet of virtual machines you have tuned can beat platform pricing outright, and a workload with a stable, predictable load and an in-house team that already runs machines well may genuinely be cheaper on infrastructure. The rule of thumb: platform services win on small and medium workloads and on teams without slack, and the argument narrows as scale grows and the operations team gets stronger.
The certification wants a clean three-way split, and real estates are never one model. A typical application is platform for the web tier, platform for the database, infrastructure for the one legacy component nobody has rewritten, and software as a service for identity and email. The interview answer that lands is not "we use PaaS", it is "we default to managed services and drop to a VM where something specific requires it" — because that names a policy rather than a preference.
Common questions
What is the difference between IaaS, PaaS and SaaS in Azure?
How much of the stack Microsoft runs. Infrastructure as a service gives you a virtual machine and leaves the operating system, runtime, scaling and patching to you. Platform as a service, such as App Service or Azure SQL, gives you a managed runtime and keeps the machine. Software as a service, such as Microsoft 365, is a finished product you only configure. Your data stays your responsibility in all three.
Is Azure App Service PaaS or IaaS?
Platform as a service. You deploy code and configuration; Microsoft owns the operating system, the web server, host patching and TLS, and scaling is a setting rather than something you build. The trade is that you cannot install arbitrary software on the host or rely on machine-level configuration.
Should I use a VM or App Service?
Default to App Service and drop to a virtual machine when something specific forces it: software the platform will not host, a dependency on particular operating-system configuration, a legacy component that expects a real filesystem, machine-tied licensing, or a lift-and-shift you are not ready to re-architect. Reaching for a VM because it feels like real infrastructure is the common beginner over-reach, and it is the option with the most ongoing homework.
Is PaaS cheaper than IaaS in Azure?
Usually in total, though often not per hour. A virtual machine's invoice line omits the patching, the certificate renewals, the untested scale set and the on-call time, all of which are paid in engineering hours. At sustained high scale with a strong operations team the calculation can flip, so treat managed-first as a default rather than a law.
When should I migrate from a VM to a managed service?
When the machine is costing the most or breaking the most, and when the workload maps cleanly onto a platform service — a web server to App Service, a database to a managed database, a scheduled script to a timer-triggered function, a file share to managed storage. Do not migrate something about to be retired, something nobody understands well enough to test, or anything during a peak or a change freeze.
Is Microsoft 365 SaaS?
Yes. You do not deploy or patch anything; you configure tenants, users and policies inside a finished product. It is the clearest everyday example of software as a service, and it is also why most organizations are already running one model before they ever open the Azure portal.