The 3 cloud service models, in one sentence each
Cloud computing rests on a simple idea: rent computing resources instead of owning them. But 'renting' can mean very different things depending on what's included. IaaS, PaaS and SaaS describe three levels of abstraction, from closest to the hardware (IaaS) to closest to end use (SaaS).
These three models aren't competitors: they coexist, and a given organization typically uses all three in parallel for different needs. The reference point for comparing them remains the historical model: 'on-premises' computing, where the company owns and operates everything itself, from the physical server up to the application.
IaaS — Infrastructure as a Service
IaaS provides virtualized compute, storage and networking resources, billed on usage. The provider owns and operates the data centers and physical hardware; you manage everything running on top of that, starting with the operating system.
This is the model that offers the most control and flexibility — and demands the most in-house operational skill. Still, it's far faster to set up than buying physical servers: a virtual machine can be provisioned in minutes, not weeks.
- Examples: Amazon EC2, Microsoft Azure Virtual Machines, Google Compute Engine, IBM Cloud
PaaS — Platform as a Service
PaaS provides a complete platform for developing, deploying and running applications: servers, networking, storage, operating system, databases and development tools, all managed by the provider.
You no longer manage virtual machines or an operating system: you deploy code, and the platform takes care of the rest — scaling, system patches, availability. It's the model that speeds up the development cycle the most, at the cost of more limited technical customization than IaaS.
- Examples: Heroku, AWS Elastic Beanstalk, Google App Engine, Azure App Service
SaaS — Software as a Service
SaaS is a complete application, hosted and managed by the provider, accessible directly from a browser or client app. Neither the infrastructure, the platform, nor even the application itself is your responsibility.
It's the most widespread model today: most of the business software used day-to-day is now SaaS. You're not paying for technical capacity, but for functional use — a seat, a license, a data volume.
- Examples: Salesforce, Dropbox, HubSpot, Google Workspace, Microsoft 365
The pizza analogy, to make it stick
A widely used metaphor, popularized by Albert Barron (IBM) in 2014, compares cloud models to different ways of getting a pizza.
On-premises, you do everything yourself: you buy the ingredients, you have your own oven, table and drinks. IaaS is like a take-and-bake pizza: you no longer manage the ingredients or the recipe, only the oven and the baking. PaaS is a pizza delivered ready to eat: all you have to do is set the table. SaaS is dining out: everything is taken care of, from the oven to doing the dishes — all you do is eat.
This image simplifies a lot, but it captures the essential point: at each step, an additional layer of management is delegated to the provider, in exchange for more limited control.
Who manages what: the technical stack, layer by layer
The key concept for telling the three models apart isn't the technology used, but how responsibilities are split between you and the provider. This split has a name: the shared responsibility model, central to memia's Azure, AWS and Google Cloud guides.
General rule: the higher up the stack you go (IaaS → PaaS → SaaS), the more operational and security responsibility shifts to the provider — and the less technical leverage you have to intervene.
What the provider always manages, regardless of the model
Three layers remain consistently the cloud provider's responsibility, even in IaaS:
- Physical security of data centers (access controls, environmental controls)
- The physical network (routers, switches, cabling)
- The virtualization layer (hypervisor) that runs the virtual machines
The operating system layer: the IaaS → PaaS tipping point
In IaaS, you're responsible for the operating system installed on your virtual machine: updates, security patches, configuration, hardening. This is often underestimated — many cloud security incidents come from an unpatched OS, not a flaw at the provider's end.
In PaaS, this responsibility moves entirely to the provider. You no longer touch the OS or the runtime (your programming language's execution engine): you only manage your application code and its configuration.
The application layer: the PaaS → SaaS tipping point
In PaaS, the application itself — its code, business logic, functional updates — remains your responsibility. In SaaS, even this layer shifts to the provider: they develop, test and deploy new features for the software you use.
What you always manage, regardless of the model
Conversely, two responsibilities remain yours even in SaaS, the most 'managed' model:
- Your data (content, classification, regulatory compliance)
- Access configuration for your data (who can see what, which permissions are granted)
IaaS: you manage the operating system. PaaS: you manage the code. SaaS: you manage the data and its access. Everything else belongs to the provider.
How to choose between IaaS, PaaS and SaaS
The choice isn't made in the abstract, but based on the need, the skills available in-house, and the level of control actually required. A poor choice costs you either in unnecessary operational complexity (too much control for a simple need) or in a lack of flexibility (not enough control for a specific need).
IaaS makes sense when...
You have specific infrastructure needs (particular hardware configuration, legacy software, precise regulatory constraints), a team capable of managing servers, or a need for fine-grained control over the execution environment.
- Migrating an existing system that requires close-to-hardware control
- Workloads with very specific performance or configuration requirements
- Teams that already have systems administration skills
PaaS makes sense when...
You want your team to focus on code rather than infrastructure, you're building an application with frequent deployment cycles, or you don't have in-house systems administration skills.
- Application development with frequent deployments (several times a week or day)
- Small development teams without a dedicated systems administrator
- Need for automatic scaling without manual server management
SaaS makes sense when...
You need a standard business function (CRM, email, file storage, accounting) with no particularity justifying custom development, and speed of implementation matters more than deep customization.
- Business functions common to most organizations (HR, finance, communication)
- Need to get started immediately, without a development phase
- No internal resources to maintain a piece of software long-term
Cross-cutting criteria worth considering
Beyond the technical need, three cross-cutting criteria often weigh more heavily than the technology itself in the final decision.
- The budget model (CapEx vs OpEx): cloud turns an investment into a recurring operational expense regardless of the model chosen — but the predictability of that expense varies significantly between usage-billed IaaS and per-seat SaaS.
- In-house team maturity: a poorly mastered PaaS or SaaS doesn't deliver the promised gains. Adopting a more abstract model without training teams on how it works just moves the problem rather than solving it.
- Compliance requirements: some regulated sectors (healthcare, finance, public sector) impose a level of control or data localization that naturally points toward IaaS, or even on-premises, for certain specific workloads.
There's no 'default' model to systematically favor. A mature organization evaluates each project individually, weighing the technical need against the three cross-cutting criteria above, rather than applying a single policy across its entire IT estate.
An organization typically uses all three models at once
In practice, companies don't pick 'one' model: they combine all three based on their needs, and that's not a sign of indecision — it's the norm, not the exception.
A concrete example
Take a mid-sized company with 200 employees. It uses Microsoft 365 or Google Workspace for office productivity and email (SaaS), Salesforce for its CRM (SaaS), a platform like Azure App Service or Heroku to host its in-house business application (PaaS), and a handful of virtual machines (IaaS) for a legacy piece of software that can't yet be migrated to a more modern architecture.
That same company might add a serverless function (FaaS) to process nightly data exports — too occasional a need to justify a dedicated virtual machine or a full PaaS application. The choice is made project by project, not at the organization-wide level.
None of these choices is 'better' than another in the abstract: each addresses a different need, with a level of control matched to that specific need. A common mistake is trying to standardize on a single model for the sake of simplicity — at the cost of a poor fit for some projects.
Serverless (FaaS): an increasingly blurry boundary
Serverless (FaaS — Functions as a Service, like AWS Lambda or Azure Functions) sits between PaaS and an even higher level of abstraction: you no longer manage the concept of a 'server' at all, only functions triggered by events, billed per execution rather than reserved capacity. Some classifications place it within PaaS, others treat it as its own category.
SaaS remains the most widely used public cloud model: according to Zylo's 2026 SaaS Management Index, the average organization manages 305 SaaS apps, and large enterprises manage nearly 700. New layers are also emerging, such as platforms exposing capabilities directly to AI agents — a trend worth watching rather than a model to master today.
Zylo, SaaS Management Index 2026The most frequent points of confusion
Four mistakes come up regularly when people first encounter these models:
Confusing PaaS and SaaS
A development platform 'as a service' is not ready-to-use software. PaaS always requires developing and deploying code; SaaS doesn't. Many tools market themselves as 'SaaS' when they actually require near-PaaS technical configuration — checking this before comparing offers avoids unpleasant surprises.
Underestimating residual responsibility in IaaS
The cloud doesn't automatically secure your operating system. In IaaS, OS security patches remain your responsibility — a common misconception is believing the provider 'handles security' as a whole, when they only handle their share of the shared responsibility model.
Forgetting about lock-in risk
The higher up you go toward SaaS, the structurally harder it becomes to switch providers (data, integrations, proprietary formats). It's a criterion to factor in from the initial choice, not after the fact — migrating a SaaS CRM after three years of use costs far more than properly evaluating it upfront.
Believing one model is objectively 'better' than another
IaaS, PaaS and SaaS aren't a quality hierarchy, but a range of trade-offs. SaaS isn't 'more advanced' than IaaS: it's a different choice, suited to a different need. The right model is the one that matches the level of control you actually need, not the one that looks the most modern.
'Cloud' doesn't mean 'secure by default', regardless of the model. The shared responsibility model means you always retain some responsibility — minimal in SaaS, but never zero (your data and its access remain yours).
Where to find IaaS, PaaS and SaaS at the major providers
The three major cloud providers offer services across all three categories, under different names for similar logic.
Azure, AWS, Google Cloud
At Azure, IaaS maps to Azure Virtual Machines, PaaS to Azure App Service (or Azure Functions for serverless), and SaaS to Microsoft 365 or Dynamics 365. At AWS, IaaS is built on Amazon EC2, PaaS on AWS Elastic Beanstalk (or Lambda for serverless), and SaaS is mostly found through the AWS Marketplace, which hosts packaged third-party software. At Google Cloud, IaaS maps to Compute Engine, PaaS to App Engine (or Cloud Functions for serverless), and SaaS to Google Workspace.
What about European cloud providers?
The same IaaS/PaaS/SaaS split applies to European cloud providers like OVHcloud or Scaleway, which offer IaaS offerings (compute instances) and managed services close to PaaS. The shared responsibility logic remains identical: the model you choose determines what you manage, regardless of the provider or its geographic location.
What does change, however, are the secondary criteria: data location, applicable legal framework, portability if you switch providers. That topic — choosing between major US providers and European alternatives — is beyond the scope of this article: it's covered in detail in memia's dedicated cloud sovereignty guide.
IaaS, PaaS, SaaS: a concept tested in (almost) every entry-level certification
Understanding IaaS, PaaS and SaaS is a near-universal prerequisite for entry-level cloud certifications, regardless of provider. It's usually one of the very first concepts covered, even before platform-specific services — because it structures the entire way you think about the cloud: once these three models are clearly distinguished, it becomes much easier to understand why a given service exists and at which level it sits.
A concept shared across the 3 major providers
Azure Fundamentals, Google Cloud Digital Leader and AWS Cloud Practitioner each dedicate an explicit domain to core cloud concepts, which systematically includes IaaS/PaaS/SaaS, alongside deployment models (public, private, hybrid) and the CapEx/OpEx concepts covered above.
Useful well beyond a certification
This concept goes far beyond the scope of an exam: it structures conversations between technical and business teams, helps you read an existing architecture, and guides decisions when choosing a new tool or service. It's one of the rare cloud concepts that stays identical regardless of provider — an investment that doesn't go stale.
Further reading
Frequently asked questions
IaaS, PaaS, SaaS: what's the essential difference?
The difference is about what you manage versus what the provider manages. In IaaS, you manage the OS and everything running on it. In PaaS, you only manage your code. In SaaS, you only manage your data and its access — the application itself is entirely handled by the provider.
Is serverless (FaaS) a form of PaaS or something else?
Serverless (Functions as a Service, like AWS Lambda or Azure Functions) is often presented as an evolution of PaaS: you deploy functions triggered by events, never managing a server or a persistent runtime. Some classifications place it within PaaS, others treat it as its own category.
Which model is cheapest?
There's no universal answer: it depends on usage volume, commitment length, and the cost of in-house operational time. IaaS may look cheaper per unit but requires systems administration time. SaaS has a predictable per-user/month cost but can get expensive at scale. The right calculation includes total cost, not just the provider's bill.
Can you switch models later?
Technically yes, but migration cost increases with the level of abstraction. Moving from one IaaS to another IaaS is relatively straightforward (they're virtual machines). Moving from one SaaS to another SaaS often involves losing data or proprietary features. That's why it's worth anticipating lock-in risk from the initial choice.
Do AWS, Azure and Google Cloud offer all 3 models?
Yes, all three major providers cover the full spectrum: virtual machines (IaaS), managed application platforms (PaaS), and ready-to-use software like office suites (SaaS). Choosing a provider and choosing a model are two separate decisions.
Is SaaS always more secure than IaaS?
Not necessarily more secure — but SaaS transfers more operational responsibility to the provider. A poorly configured IaaS setup (unpatched OS, loosely restricted access) can be less secure than a properly configured SaaS. Security depends as much on the model as on how each party fulfills its share of responsibility.
What does CapEx vs OpEx have to do with IaaS/PaaS/SaaS?
All three cloud models turn a capital expense (CapEx — buying servers) into an operational expense (OpEx — paying a subscription or usage fee). That's true for IaaS as much as SaaS, but the extra abstraction layer of PaaS and SaaS also reduces internal operational costs (less systems administration time).
Is on-premises still part of the picture today?
Yes. Many organizations keep part of their infrastructure on-premises, often for regulatory reasons, latency, or because an existing system hasn't been migrated yet. This is called a hybrid architecture, combining on-premises with one or more cloud models.
What is XaaS ('Everything as a Service')?
XaaS is an umbrella term covering all 'as a service' models: IaaS, PaaS, SaaS, but also FaaS (functions), DBaaS (databases), DaaS (desktops), and other more specialized variants. The principle stays the same: delegate a layer of technical management to the provider, in exchange for a subscription or usage-based billing.
Do you need to know IaaS/PaaS/SaaS for a cloud certification?
Yes, it's a foundational concept present in nearly all entry-level cloud certifications (Azure Fundamentals, Google Cloud Digital Leader, AWS Cloud Practitioner). memia's Azure, Google Cloud and AWS guides cover this concept in their first decks.