IaaS, PaaS, SaaS and serverless
Summary: these acronyms describe how far the provider's responsibility goes and where yours begins. The higher you go in abstraction — from IaaS to SaaS — the fewer things you manage, but the less you control. This lesson clarifies each level, presents the shared responsibility model and gives a clear rule for choosing.
1. The pizza analogy
It is the classic analogy, and it works remarkably well.
What the analogy teaches: there is no "best" level. You choose according to the control you actually need and the time you want to devote to operations.
2. Who manages what — the complete stack
Here is the precise distribution of responsibilities, layer by layer.
Note the essential constant: your data remains your responsibility at all levels, including in SaaS. The provider ensures the availability and encryption of the infrastructure, but who accesses what and what your data contains is always up to you.
3. IaaS — Infrastructure as a Service
4. CaaS — the often forgotten intermediate level
This level does not appear in the original NIST definition, but it has become central since 2016.
Concrete recommendation for 2026: for a modern containerized web application, a service like Google Cloud Run, AWS Fargate or Azure Container Apps often offers the best simplicity / control / portability ratio. You supply a Docker image, the provider manages everything else, and your image remains movable elsewhere.
5. PaaS — Platform as a Service
Very frequent mistake to avoid: choosing IaaS "because you want to keep control", then spending the next six months rebuilding by hand what the PaaS offered immediately — scaling, certificates, zero-downtime deployments, centralized logs. Ask yourself honestly: what control do you actually need?
6. Serverless and FaaS
Precision about the name: the term serverless is misleading. There obviously are servers — you simply do not manage them and do not pay for their idle time. A fairer formulation would be "without server management".
The economic calculation to know: serverless is very economical with low or irregular traffic, and can become more expensive than a permanent container beyond a certain constant volume. The tipping point depends on the case, but the order of magnitude often sits around a few million monthly invocations.
7. SaaS — Software as a Service
Useful arbitration rule: build what differentiates your company, buy everything else as SaaS. Nobody wins a market thanks to their internal email server.
8. The summary table
| Model | You supply | Provider manages | Control | Operational burden | Dependence |
|---|---|---|---|---|---|
| Owned server | Everything | Nothing | Maximum | Maximum | None |
| IaaS | OS + app + data | Hardware, virtualization | High | High | Low |
| CaaS | Image + data | Machines, orchestration | Medium-high | Medium | Low |
| PaaS | Code + data | OS, runtime, scaling | Medium | Low | Medium |
| Serverless | Function + data | Absolutely everything else | Low | Very low | High |
| SaaS | Data + configuration | Everything | Minimal | None | High |
The two columns to look at together: operational burden and dependence. CaaS occupies a particularly interesting position — medium operational burden and low dependence, thanks to the portability of container images.
9. The shared responsibility model
It is the most important security notion of the cloud, and the most misunderstood.
The most important empirical finding of this lesson: the very large majority of data leaks in the cloud do not come from a provider flaw. They come from customer-side configuration mistakes:
- A storage space left publicly accessible — the most frequent and most documented cause.
- An access key committed to a public Git repository.
- A role with administrator rights granted to a service that does not need them.
- A database exposed on the internet without a password.
- A virtual machine not updated for two years.
The line of responsibility moves with the model: the higher you go towards SaaS, the more the provider assumes. In IaaS, OS updates are entirely your problem. In PaaS, they no longer are.
10. How to choose — decision tree
Question 4 is the one where people get it wrong the most. Many answer "yes" by habit and end up with a system administration burden they had not anticipated. Ask yourself: "do I really need to compile a kernel module, or am I answering yes by reflex?"
Remember in 30 seconds
- The acronyms describe how far the provider's responsibility goes.
- IaaS = a bare virtual machine, you manage the OS. PaaS = you supply only the code. SaaS = a ready application.
- CaaS (managed containers) is the intermediate level that is often the best choice: little operations, low dependence.
- Serverless = you pay per invocation. Excellent with irregular traffic, expensive with heavy constant traffic.
- Your data remains your responsibility at all levels, including in SaaS.
- Shared responsibility: the provider secures the cloud, you secure what is in the cloud.
- Most leaks come from customer configuration mistakes: public storage, a key in Git, overly broad rights.
- Arbitration rule: build what differentiates you, buy the rest as SaaS.