IaaS, PaaS and SaaS: Where the Line Actually Falls

Three acronyms describing how much of the stack someone else operates. The useful question is what you are still responsible for.

11 March 2026 2 min read

The three service models describe a single variable: how much of the stack the provider operates. Everything else — pricing, control, portability, responsibility — follows from that.

Who operates what

Layer	On-premises	IaaS	PaaS	SaaS
Application	You	You	You	Provider
Runtime	You	You	Provider	Provider
Operating system	You	You	Provider	Provider
Virtualisation	You	Provider	Provider	Provider
Hardware	You	Provider	Provider	Provider
Data centre	You	Provider	Provider	Provider

Read down your column: everything marked “you” is something you patch, monitor, back up and are responsible for when it fails.

Infrastructure as a service

Virtual machines, storage volumes, networks. You get a machine and everything above the hypervisor is yours.

Maximum control and the lowest unit cost.
You own OS patching, security configuration, monitoring and backups.
Highly portable — a Linux server is a Linux server anywhere.
Every provider in this catalogue sells this, from Hetzner to AWS.

Platform as a service

You supply code or a container; the platform runs it. App Service, App Engine, App Platform, Cloud Run and managed databases all sit here.

No OS to patch, no servers to monitor.
Constrained to what the platform supports.
Higher unit cost, usually lower total cost once operational time is counted.
Portability varies — a container platform is portable, a proprietary runtime much less so.

Managed databases are the clearest case where PaaS is worth the premium: the operational work it removes is exactly the work that is expensive to do badly.

Software as a service

A finished application you use. Email, CRM, monitoring platforms, source hosting.

Nothing to operate at all.
You still own your data, your access control, and the decision about what you put in it.
Integration and export are where the real evaluation lies.
Per-seat or per-usage pricing that grows with the organisation.

What stays yours regardless

This is the part people get wrong. Moving up the stack does not transfer everything:

Your data, its classification and its protection.
Who has access, and removing access when people leave.
Your application code and its vulnerabilities.
Configuration — a misconfigured SaaS permission is your problem.
Compliance obligations that apply to you rather than to the provider.
Backups, unless the provider explicitly guarantees them at the level you need.

A public storage bucket on a managed platform is a configuration failure, not a provider failure. See cloud compliance basics.

Choosing per component

The models are not a ladder to climb. A typical sound architecture mixes all three:

SaaS for anything that is not your differentiator — email, monitoring, source hosting.
PaaS for the database and for running application containers.
IaaS for workloads with specific requirements, or where cost dominates.
The principle: operate what makes you distinctive, buy the rest.

Common questions

Is serverless PaaS?

Broadly yes — sometimes called function as a service, it is a further step where you supply a function rather than an application. The responsibility split is the same idea taken further.

Is a managed database PaaS or IaaS?

PaaS. The provider operates the engine, the OS and the hardware; you own the schema, the queries and the data.

Which is cheapest?

IaaS per unit of compute, generally. Total cost depends on operational time, which is why PaaS often wins for small teams and IaaS at scale.

Does SaaS mean my data is safe?

It means the provider operates the software. Your data protection still depends on your access configuration, and on whether you have an export you could restore.

Where to go next

See choosing a deployment target and managed versus self-hosted cost.

AWS Google Cloud Microsoft Azure