What do you actually own when you “move to the cloud”? That question sounds simple until someone asks who patches the database, who owns the encryption keys, and who gets the call at 2 a.m. when a node dies. The answer depends almost entirely on which cloud service model you picked, and plenty of teams pick one without realizing what they signed up for. (What is cloud computing?)
This guide walks through the three main models, where the dividing lines sit, and the practical traps that catch people in real deployments. It sticks to the widely used definitions rather than vendor marketing, because the definitions are where most confusion starts.
Where the definitions come from
The most cited reference is the U.S. National Institute of Standards and Technology, whose NIST definition of cloud computing set out three service models back in 2011: Software as a Service, Platform as a Service, and Infrastructure as a Service. Alongside them it listed five essential characteristics and four deployment models. Nearly every vendor deck since has been a remix of that document.
There is also an international vocabulary standard, ISO/IEC 17788, which defines cloud service categories in similar terms. The two frameworks broadly agree, but they are not identical word for word. That matters more than it sounds: when a contract says “PaaS,” the legal meaning may not match what your architect means. Good practice is to state which definition a project is using, in writing, before anyone signs.
The three models, side by side
The cleanest way to understand the models is to ask who manages what. In every case the provider runs the physical hardware, the network, and the data center. Everything above that line is negotiable.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical hardware and data center | Provider | Provider | Provider |
| Virtualization | Provider | Provider | Provider |
| Operating system | You | Provider | Provider |
| Runtime and middleware | You | Provider | Provider |
| Application code | You | You | Provider |
| Data and access control | You | You | Shared |
Read that table again, because the bottom rows are where the surprises live. Moving down the table does not remove responsibility. It moves responsibility, and it usually moves it in ways that are easy to overlook.
Infrastructure as a Service
IaaS hands you virtual machines, storage, and networking as raw building blocks. You choose the operating system, install the runtime, patch everything, and manage scaling yourself. NIST describes it as provisioning processing, storage, networks, and other fundamental computing resources where the consumer does not manage the underlying cloud infrastructure but controls the operating system and deployed applications.
The upside is control. The downside is that you have effectively rented a data center and inherited a data center’s chores. Teams consistently underestimate the operational load here: patch cycles, image maintenance, and the slow drift of configuration across environments. A useful discipline is to inventory exactly what you are taking on before the first server spins up, which is the same exercise described in this guide to what to inventory before a cloud migration.
Platform as a Service
PaaS gives you a managed environment for running code. The provider handles the operating system, runtime, scaling, and often the database and message queues. You bring the application and its configuration.
This is the sweet spot for most product teams. You stop maintaining servers and start shipping features. The trade-off is reduced control: you generally cannot install arbitrary kernel modules or tune the host, and you inherit the provider’s supported language versions and upgrade timetable. That last point causes real friction. A runtime version going end-of-life on the provider’s schedule can force an application upgrade on someone else’s calendar.
Software as a Service
SaaS is finished software you log into. The provider runs everything: infrastructure, platform, application, and updates. You configure users, permissions, and integrations.
NIST frames SaaS as the consumer using the provider’s applications running on cloud infrastructure, without managing the underlying stack. The catch is that “no management” is not “no responsibility.” Data classification, access reviews, and integration security stay firmly with you. Most serious breaches in SaaS environments are not provider failures. They are misconfigured sharing settings and stale accounts.
The shared responsibility model, in plain terms
The phrase shared responsibility model describes how duties split between provider and customer. It is industry shorthand rather than a formal NIST term, and it is where a lot of assumptions break down.
A rough rule: the provider is responsible for security of the cloud, and you are responsible for security in the cloud. In IaaS, that means you own the guest operating system, its patches, and its firewall rules. In PaaS, you own application code, secrets, and data access. In SaaS, you own identity, permissions, and how data leaves the system.
Three mistakes come up again and again in practice:
- Assuming the provider backs up your data. Many services replicate for durability but do not offer point-in-time recovery unless you enable and pay for it.
- Treating identity as the provider’s problem. Single sign-on, multi-factor authentication, and joiner-mover-leaver processes are yours in every model.
- Skipping the exit plan. Teams rarely ask how they would leave until they need to.
That third point now has regulatory weight in Europe. The EU Data Act, Regulation (EU) 2023/2854, includes cloud switching provisions under the EU Data Act aimed at reducing lock-in across IaaS, PaaS, and SaaS. If your organization operates in the EU, contract terms around switching and data portability deserve a close read rather than a skim.
How to choose without overthinking it
The decision usually comes down to a handful of questions. Answer them honestly and the model tends to pick itself.
| Question | Points toward |
|---|---|
| Do you need kernel-level control or custom networking? | IaaS |
| Is your team small and shipping fast the priority? | PaaS |
| Is this a standard business function (email, CRM, HR)? | SaaS |
| Do you have strict data residency or licensing constraints? | IaaS or private deployment |
| Can you absorb a provider-driven upgrade schedule? | If no, lean toward IaaS |
A pattern that works well in practice is mixing models deliberately rather than standardizing on one. Most mature estates run SaaS for commodity functions, PaaS for custom applications, and a modest amount of IaaS for the awkward workloads that fit nowhere else. The complexity cost of mixing is real, but so is the cost of forcing everything into one shape. Splitting workloads across separate accounts or subscriptions is a related decision worth planning early, as covered in this piece on when to split workloads across cloud accounts.
Practical tips that save real pain
Model the cost before the architecture. Serverless and PaaS pricing scales with usage in ways that are hard to predict. A workload that is cheap at low volume can become expensive at steady high volume, and the reverse is also true. Capacity planning deserves its own exercise; this walkthrough on planning capacity for a new cloud service covers the numbers side.
Watch data transfer alongside compute. Egress and cross-region traffic often drive most of the bill in distributed designs. A structured approach to tracking cloud data transfer costs prevents the quarterly shock.
Read region announcements carefully. New regions and new instance families arrive with caveats about feature availability. Learning how to read a cloud region announcement helps separate genuine availability from a press release.
Write down who patches what. A one-page responsibility matrix, signed off by both sides, resolves more arguments than any architecture diagram. It also makes audits far less painful.
Test the exit once. Restore a backup into a different environment, export your data in a usable format, and time how long it takes. The first attempt is always slower than expected, and finding that out during a calm week beats finding it out during an incident.
Do not confuse serverless with a fourth model. Function as a Service and serverless computing are widely used terms, but they sit outside the classic three-model taxonomy and are usually described as a refinement of PaaS. Treating them as a separate category tends to confuse procurement more than it helps.
Where the standard models fall short
The three-model framing is useful but imperfect. It does not cleanly describe container platforms, database-as-a-service offerings, or edge computing, all of which blend layers. Vendor documentation often invents its own vocabulary, which is why two teams can argue for an hour about whether a managed Kubernetes service is IaaS or PaaS and both be partly right.
The honest answer is that the models are a communication tool, not a law of physics. Use them to align expectations about who does what, then get specific about the actual service in front of you. For teams building out a broader estate, the architecture material at 9481.org’s cloud infrastructure section and the security guidance in enterprise AI and cloud security go deeper on the operational side. (Cloud computing)
Conclusion
The cloud service model question is really a question about boundaries. IaaS gives you the most control and the most work. PaaS trades control for speed. SaaS trades nearly everything for convenience. None is inherently better, and most organizations end up using all three.
What separates smooth deployments from painful ones is rarely the model choice itself. It is whether someone wrote down the responsibilities, checked the exit route, and planned the costs before the first invoice arrived. Pick the model that fits the workload, document the split, and revisit it when the workload changes. That habit is worth more than any single architectural decision.
Frequently asked questions
What is the difference between IaaS, PaaS, and SaaS in one sentence?
IaaS rents you raw infrastructure you manage yourself, PaaS gives you a managed platform where you only run your code, and SaaS delivers finished software you simply log into and configure.
Which cloud service model is most secure?
None is automatically more secure. Security depends on how well responsibilities are executed. IaaS gives you more control over hardening but more surface to get wrong. SaaS removes infrastructure risk but concentrates risk in identity and configuration. The shared responsibility split matters more than the model label.
Is serverless the same as PaaS?
Not officially. Serverless and Function as a Service are usually described as a refinement of PaaS rather than a separate category in the standard three-model taxonomy. Practically, serverless removes more operational work than classic PaaS, but the responsibility boundary is similar: you still own code, secrets, and data access.
Can a company use more than one cloud service model at once?
Yes, and most do. A typical estate runs SaaS for email and HR, PaaS for custom applications, and some IaaS for workloads needing low-level control. The main cost is operational complexity, so it helps to set clear rules about which model fits which type of workload.
Who is responsible for patching in each model?
In IaaS, you patch the guest operating system, runtime, and applications. In PaaS, the provider patches the operating system and runtime while you handle dependencies and application code. In SaaS, the provider patches the application, but you remain responsible for user access, permissions, and integrations.
How do I avoid lock-in with a cloud service model?
Start with portability in mind: keep data in open formats, avoid provider-specific features where they are not worth the trade-off, and test an export before you need one. In the EU, cloud switching provisions under the EU Data Act add contractual expectations around portability that are worth reviewing with legal counsel.
