What do a rented virtual machine, a managed app runtime, and a web-based email inbox have in common? They are all cloud services, yet they hand you wildly different amounts of control. That gap is exactly what the three standard cloud service models describe. Knowing which model a product belongs to tells you who patches the operating system, who owns the database backups, and who gets paged at 3 a.m. when something breaks.
This guide walks through concrete cloud service model examples for each layer, shows where the boundaries blur, and explains how to use the labels without being misled by them.
The Three Service Models, Defined
The most widely cited taxonomy comes from the U.S. National Institute of Standards and Technology. Its special publication SP 800-145, published in September 2011, defines Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS), alongside four deployment models: private, community, public, and hybrid. That document remains the reference point most architects and auditors still use.
The three models stack by abstraction level. IaaS sits at the bottom, closest to raw hardware. PaaS sits in the middle, covering runtimes and deployment tooling. SaaS sits on top as a finished application. NIST frames this as a layered abstraction rather than a strict hierarchy, which matters later when products straddle two categories.
A quick way to remember the split: with IaaS you manage the operating system and up. With PaaS you manage only your code and data. With SaaS you manage only your account settings.
| Model | What the provider runs | What you manage | Typical user |
|---|---|---|---|
| IaaS | Servers, storage, networking, virtualization | OS, middleware, runtime, apps, data | Infrastructure and ops teams |
| PaaS | Everything above plus runtime and scaling | Application code and data | Developers |
| SaaS | The entire application stack | Users, configuration, data entry | Business users |
Infrastructure as a Service Examples
IaaS means renting compute, storage, and networking as virtual resources. You get administrative control over the operating system, which is both the appeal and the burden.
Amazon EC2 is the canonical example. It launched in August 2006 and lets teams spin up virtual machines on demand. Google Compute Engine is another standard entry, offering virtual machines inside Google’s network. Both give you a blank machine and a bill that scales with what you run.
Practical examples of where IaaS fits:
- Lift-and-shift migrations of legacy applications that assume a specific OS configuration.
- Workloads needing custom kernels, unusual networking setups, or licensed software tied to a machine.
- Temporary high-performance clusters for batch jobs that run for days, then disappear.
The common mistake with IaaS is treating rented machines like owned hardware. Teams forget that patching, backup verification, and capacity planning are still their job. If you are sizing a new deployment, this walkthrough of planning capacity for a new cloud service covers the sizing questions that surface before the first invoice arrives.
A second trap is sprawl. Virtual machines multiply quietly, and orphaned instances keep billing long after a project ends. Inventory discipline matters as much in IaaS as in any on-premises data center, which is why a pre-migration inventory checklist is worth reading even if you are only adding a handful of instances.
Platform as a Service Examples
PaaS removes the operating system from your problem list. The provider supplies the runtime, the scaling logic, and the deployment pipeline. You push code; the platform figures out where it runs.
Google App Engine, which entered public preview in April 2008, is a long-standing example. Heroku, launched in 2007, is another, built around the idea that deployment should be a single push. Both abstract away servers entirely, and both impose opinions about how applications should be structured.
Where PaaS earns its keep:
- Teams without dedicated operations staff who still need production-grade reliability.
- Applications with predictable runtime requirements, such as a standard web framework and a managed database.
- Projects where developer time costs more than infrastructure, which is most projects.
The trade-off is constraint. PaaS platforms support specific languages, specific build processes, and specific add-on services. Step outside those rails and you either fight the platform or migrate down to IaaS. A useful rule of thumb: if your application needs a custom kernel module or a database version the platform does not offer, PaaS will cost you more in workarounds than it saves in operations.
Software as a Service Examples
SaaS is the model most people meet first, often without realizing it. The provider runs everything, and you log in through a browser.
Salesforce is frequently described as an early SaaS pioneer, having launched in 1999, though the “first SaaS product” label is contested and best treated as marketing shorthand. Microsoft 365 and Google Workspace are everyday examples: email, documents, and calendars delivered entirely as services.
SaaS fits when the requirement is standard. Payroll, customer relationship management, ticketing, and collaboration tools all have mature SaaS options that would be wasteful to rebuild. The evaluation criteria shift too. Instead of asking about CPU and memory, buyers ask about data residency, export options, single sign-on support, and what happens to their data if they leave.
That last question deserves real weight. SaaS lock-in is rarely about the software itself; it is about the data and the workflows built around it. Before committing, confirm you can extract your data in a usable format and that the vendor’s identity and access controls meet your security baseline. Articles on enterprise AI and cloud security are a reasonable starting point for framing those questions.
Where the Boundaries Blur
The tidy three-layer picture breaks down quickly in real product catalogs, and pretending otherwise causes bad architecture decisions.
Serverless functions are the clearest example. AWS Lambda, launched in November 2014, is often classified as PaaS and often as a separate Function as a Service (FaaS) model. Both descriptions appear in reputable sources. Neither is wrong; the categories simply were not designed for a product where you deploy a function and never see a server at all.
Managed databases sit awkwardly between IaaS and PaaS. You do not patch the database engine, but you do choose its size and tune its parameters.
Container platforms blur the line further. A managed Kubernetes service handles the control plane while you own the workloads, which reads as PaaS in some respects and IaaS in others.
NIST anticipated this. SP 800-145 explicitly notes that the definition is meant to evolve and that cloud characteristics are not binary. Treat the labels as descriptive shorthand, not as legal categories with fixed edges.
Several additional models have been proposed outside NIST’s core three, including Anything as a Service (XaaS), Desktop as a Service (DaaS), and Database as a Service (DBaaS). They are useful vocabulary, but they are not part of the original taxonomy, and vendors sometimes stretch them for positioning.
How to Classify a Product in Practice
When a vendor’s marketing page is ambiguous, three questions settle it quickly.
- Who patches the operating system? If you do, it is IaaS. If the provider does, move to question two.
- Do you deploy code or configure an application? Deploying code points to PaaS. Configuring a finished product points to SaaS.
- What breaks your day? If a failed patch or a full disk is your problem, you are in IaaS territory. If a failed deployment is your problem, you are in PaaS. If a failed login is your problem, you are in SaaS.
This matters beyond vocabulary. Service model determines your shared responsibility split, your incident response obligations, and often your compliance evidence. A team that thinks it bought PaaS but is actually running unmanaged virtual machines will discover the gap during an audit, not before.
There is also an organizational dimension. Large estates rarely fit one model cleanly, and teams often need to split workloads across cloud accounts to keep ownership and billing boundaries aligned with the service model each workload uses. Mixing IaaS, PaaS, and SaaS in one account is normal; mixing them without clear ownership is where trouble starts.
Common Mistakes and What Actually Works
A few patterns show up repeatedly in real deployments.
Choosing the model before the workload. Teams sometimes decide “we are a PaaS shop” and then contort an application that genuinely needs machine-level control. Start with the workload’s requirements, then pick the model that fits.
Underestimating the operational tail of IaaS. Rented servers still need patching, monitoring, and backup testing. The bill is lower than owning hardware, but the labor is not zero.
Overestimating PaaS portability. Managed runtimes are convenient until you need to leave. Check whether the platform’s proprietary services are load-bearing in your architecture.
Treating SaaS as fire-and-forget. Configuration drift, unused licenses, and stale integrations accumulate. SaaS reduces infrastructure work; it does not eliminate governance.
What works in practice is a simple inventory: for every system, record its service model, its owner, and the boundary of provider responsibility. That single table resolves most arguments about who should be fixing what. Broader guidance on cloud infrastructure and architecture can help frame the inventory across a mixed estate, and reading a cloud region announcement critically is useful when a provider’s expansion changes your latency and residency assumptions. (Cloud computing)
Conclusion
The three cloud service models remain a genuinely useful lens, more than a decade after they were formalized. IaaS examples like Amazon EC2 and Google Compute Engine hand you control and responsibility in equal measure. PaaS examples like Google App Engine and Heroku trade flexibility for speed. SaaS examples like Salesforce, Microsoft 365, and Google Workspace deliver finished software and shift the operational burden entirely to the provider.
The labels are not perfect. Serverless functions, managed databases, and container platforms all straddle categories, and additional models like DaaS and XaaS sit outside the original framework. That fuzziness is fine as long as you use the models for what they are good at: clarifying who owns which layer, and making the shared responsibility boundary explicit before an incident forces the conversation.
Frequently Asked Questions
What are the three main cloud service models?
The three standard models are Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). They were formalized in NIST Special Publication 800-145 in September 2011. IaaS provides virtual machines and networking, PaaS provides managed runtimes for deploying code, and SaaS provides a complete application.
What is an example of IaaS?
Amazon EC2, launched in August 2006, is the most commonly cited IaaS example, offering rentable virtual machines. Google Compute Engine is another. In both cases the customer manages the operating system, middleware, and application, while the provider manages the underlying hardware and virtualization.
What is an example of PaaS?
Google App Engine and Heroku are standard PaaS examples. Both supply a managed runtime, scaling, and deployment tooling so developers can push code without provisioning servers. The trade-off is that the platform constrains which languages, build processes, and services you can use.
Is serverless the same as PaaS?
It depends on who you ask. Serverless platforms such as AWS Lambda, launched in November 2014, are classified as PaaS by some sources and as a separate Function as a Service (FaaS) model by others. The classification is genuinely disputed, which is why the model labels are best treated as descriptive rather than definitive. (What is serverless computing?)
What is an example of SaaS?
Microsoft 365 and Google Workspace are everyday SaaS examples, delivering email, documents, and calendars through a browser. Salesforce, launched in 1999, is often described as an early SaaS pioneer, though that “first” claim is contested and should be attributed rather than stated as fact.
Why do the service model boundaries blur?
Because real products do not fit neatly into three boxes. Managed databases, container platforms, and serverless functions all combine characteristics of two models. NIST itself notes that its definition is meant to evolve and that cloud characteristics are not binary, so the categories work best as shared vocabulary rather than strict rules.
