The models describe who runs what
The distinction is about division of labour. In every case the provider runs the physical hardware; what changes is how far up the stack their responsibility goes and where yours begins.
| Model | Provider runs | You run |
|---|---|---|
| IaaS | Hardware, virtualisation, networking | Operating system, runtime, application, data |
| PaaS | Everything up to the runtime | Application and data |
| SaaS | The entire stack | Your data and configuration only |
IaaS: maximum control, maximum work
Infrastructure as a Service gives you a virtual machine and leaves the rest to you. Compute instances on any provider are the canonical example.
You choose the operating system, install what you need, and are responsible for patching, hardening, monitoring and backups. That control is genuinely valuable for unusual requirements, legacy software and cost optimisation, and it is genuinely a lot of ongoing work.
PaaS: deploy code, skip the server
Platform as a Service takes the operating system off your plate. You deploy an application and the platform handles the runtime, scaling and patching underneath it. Managed databases, container platforms and application platforms all sit here.
The trade is flexibility. The platform decides how things run, and workloads that do not fit its assumptions are awkward. It usually costs more per unit of compute, which often still works out cheaper once you count the time not spent on maintenance.
SaaS: someone else’s application
Software as a Service is a finished application you configure rather than build. Google Workspace is a straightforward example: you are not running mail servers, you are administering users.
There is no infrastructure decision to make, and correspondingly little you can change.
Most real systems mix all three
The layers are not exclusive. A typical stack runs application containers on a managed platform, stores data in a managed database, keeps one virtual machine for a legacy component that will not containerise, and uses a hosted service for email.
The useful question is not which model to standardise on, but which layer each individual component belongs at.
Choosing per component
- Pick IaaS when you need specific control, have unusual requirements, or the cost difference at scale justifies the operational work.
- Pick PaaS when the component is ordinary and your time is better spent elsewhere.
- Pick SaaS when the problem is genuinely solved and building it yourself adds nothing.
The most common expensive mistake is running IaaS out of habit and absorbing years of maintenance on something a managed service would have handled.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Object Storage: When to Use It and What It Really Costs
- Hardening SSH on a New Cloud Server
- Alibaba Cloud vs OVHcloud: Which Cloud Account Should You Buy?
- DigitalOcean vs Linode: Which Cloud Account Should You Buy?
Frequently asked questions
IaaS is usually cheapest per unit of compute and most expensive in engineering time. Total cost depends heavily on what your time is worth.
Moving from IaaS to PaaS usually means reworking deployment and sometimes the application. It is easier to reconsider before building than after.
Yes. The provider runs the engine, patching and backups; you own the schema and the data.
