On this page
TL;DR
The real choice between IaaS, PaaS, and SaaS is one question: how much do you want to manage versus hand off? Learn where each line falls so you pick the right control-versus-convenience trade-off per app.
The only question that matters: who manages what?
Every cloud service sits somewhere on one spectrum: how much of the stack do you operate, versus how much does the provider operate for you? At one end you manage almost everything (more control, more work). At the other, you manage almost nothing (less work, less control). IaaS, PaaS, and SaaS are just three points on that line.
Who this is for
Beginners deciding how to host an app, or anyone who's nodded along to these acronyms without being 100% sure of the difference.
The pizza analogy that makes it click
Think of it as 'pizza as a service': how much of dinner do you make yourself, and how much is done for you?
On-prem: you buy flour, own the oven, do everything. IaaS: the provider supplies the kitchen and oven (servers, storage, network), you still assemble and bake (OS, runtime, your app). PaaS: they cook it too; you just say what you want (deploy your code, they handle servers, scaling, patching). SaaS: you don't cook at all; you just use the finished product (Gmail, Slack, Notion).
Who manages each layer
Here's the same idea as the layers you're actually responsible for. ✅ = you manage it, ☁️ = the provider does.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Your application & data | ✅ you | ✅ you | ☁️ provider |
| Runtime & dependencies | ✅ you | ☁️ provider | ☁️ provider |
| Operating system & patching | ✅ you | ☁️ provider | ☁️ provider |
| Servers, storage, network | ☁️ provider | ☁️ provider | ☁️ provider |
| Example | EC2, a bare VM | App Runner, Heroku, Vercel | Gmail, Slack |
When to choose each
Choose IaaS when…
You need full control, custom OS tuning, specific networking, legacy software, or you're running something the managed platforms don't support. The cost is that you now own patching, scaling, and uptime. Great power, great pager duty.
Choose PaaS when…
You want to ship product, not babysit servers. You push code; the platform builds, runs, scales, and patches it. Perfect for most web apps, APIs, and startups. The trade-off: you live within the platform's supported runtimes and limits.
Choose SaaS when…
The problem is already solved by someone else. Don't build an email server, a CRM, or a payroll system, buy the SaaS. Build only what's actually your differentiator.
Pro tip
Default to the highest level that fits. Most teams over-choose IaaS, then drown in ops work that a PaaS would have handled. Reach for IaaS only when you have a concrete reason PaaS can't meet.
The same app, two ways
Deploying a Node app on IaaS means provisioning and maintaining a server yourself:
# You rent a bare VM... then YOU do all of this, forever:
ssh ubuntu@your-server
sudo apt update && sudo apt upgrade -y # patching = your job
sudo apt install -y nodejs nginx # runtime = your job
# configure nginx, TLS certs, a process manager,
# log rotation, firewall, auto-restart, scaling...The same app on a PaaS is usually a config file and a push, servers, scaling, TLS, and patching are the platform's problem:
# Describe what you want; the platform runs it.
service: my-api
runtime: nodejs20
build: npm ci && npm run build
start: npm start
instances:
min: 2 # platform handles scaling + restarts
max: 10Where to go next
The whole article in 4 lines
- It's one spectrum: how much you manage vs how much the provider manages.
- IaaS = you get raw infrastructure and run everything on top (max control, max work).
- PaaS = push code, the platform runs it (ship fast, less control).
- SaaS = use a finished product. Default to the highest level that fits your need.
- Related lesson: Compute Models, the IaaS building blocks.
- Next read: Compute Models: VMs vs Containers vs Serverless.
- See it in context in the Cloud Engineer path.
You need to host or solve something. Which service model should you reach for?
Check your understanding
1. In the "pizza as a service" analogy, what distinguishes IaaS from PaaS?
2. What default does the article recommend when choosing a service level?
Frequently asked questions
What actually changes between IaaS, PaaS, and SaaS?
They are three points on one spectrum of how much of the stack you operate versus how much the provider operates for you. With IaaS the provider gives you servers, storage, and network while you handle the OS, runtime, and app; with PaaS you just push code and the platform runs, scales, and patches it; with SaaS you use a finished product and manage almost nothing.
When should I choose IaaS over PaaS?
Reach for IaaS only when you have a concrete reason PaaS cannot meet, such as needing full control of the operating system, custom networking, or running legacy or specialised software the managed platforms do not support. The cost is that you then own patching, scaling, and uptime yourself.
What is the safest default when picking a service level?
Default to the highest level that fits your needs, because most teams over-choose IaaS and then drown in operations work that a PaaS would have handled for them. Move down to IaaS only when you hit a specific limitation that the managed platform cannot satisfy.
Should I ever build my own email, CRM, or payroll system?
No, if the problem is already solved by a SaaS product, buy it instead of building it. Spend your engineering effort only on what is actually your differentiator, and let services like Gmail, Slack, or Notion handle the commodity problems.
Was this article helpful?
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths, with real terminal labs, production scenarios, and structured lessons.