Understanding Cloud Service Models: IaaS, PaaS and SaaS

IaaS, PaaS and SaaS are not product categories. They are three places to draw one line: the line where your responsibility stops and the provider’s begins. Everything useful about the comparison follows from that. Move the line further up the stack and you pay more per unit, control less, and spend fewer evenings patching. That trade is the whole decision.

The definition that still holds up

NIST published its definition of cloud computing as Special Publication 800-145 in September 2011, and fifteen years later it is still the least ambiguous description available. It sets out five essential characteristics, on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service, then three service models, software, platform and infrastructure as a service, and four deployment models.

Those characteristics are a useful filter in their own right. If a supplier calls something cloud but you have to raise a ticket to get more capacity, it fails on-demand self-service. If you cannot see your own consumption, it fails measured service. NIST even published a follow-up guide in 2017 on how to decide whether a given service qualifies and which model it belongs to, which tells you the confusion is not new.

Service models and deployment models are different axes, and conflating them causes most of the muddle in vendor conversations. You can buy IaaS from a public cloud or from a single-tenant private environment. We cover that second axis in public, private and hybrid deployment.

What changes at each boundary

Here is the boundary in one table. Read down a column to see what you are signing up to operate.

The two rows at the top are the ones people miss. Whichever model you buy, your data and your user accounts remain your responsibility. A SaaS provider will keep the application running; it will not notice that a departed employee still has access, or that someone has shared a customer list with a personal address. That work does not go away, it just stops looking like IT work.

What each model costs, with real prices

Abstract comparisons are easy to agree with and useless for budgeting, so here are the actual published rates for a comparable job: running one small business web application. All figures are 2026 list prices from the vendors’ own pricing pages or trackers, captured in September 2026.

Look at the App Service and virtual machine rows together. App Service Standard costs slightly more per month than an equivalent virtual machine, and in exchange nobody on your team patches an operating system, renews a certificate by hand or gets paged about disk space. For most small businesses that is the single best value trade in the whole cloud catalogue. The VM only wins when you need something the platform will not let you install.

The SaaS row is where the arithmetic flips. Twelve users on Microsoft 365 Business Basic costs $72 a month, which is roughly one virtual machine, and it replaces a mail server, a file server, the backups for both and the person who maintained them. Nobody should be running their own mail server in 2026 unless there is a specific regulatory reason, and even then it is worth checking whether a regional SaaS tenant satisfies it.

Security: the shared responsibility line

Security responsibility follows the same line, which is why “the cloud is secure” and “the cloud is insecure” are both true depending on which row you mean. Providers secure the layers they operate, and they are generally better at it than any small business could be: physical access, hypervisor patching, network isolation, hardware lifecycle. Those are problems of scale and they have scale.

What stays with you, in every model, is identity, configuration and data. The breaches we are asked to help with are almost never a failure of the provider’s infrastructure. They are a storage bucket set to public, a service account with permanent administrative rights, multi-factor authentication left optional, or an ex-contractor whose access nobody revoked. Moving to SaaS reduces the number of things you can get wrong. It does not reduce the consequence of getting those four wrong.

Practically, that means the move up the stack should come with a tightening of access control, not a relaxation. When we take a client from self-hosted email to a SaaS tenant, the first configuration change is conditional access and enforced multi-factor authentication, before anything else, because the attack surface has moved from the server to the login page.

Where the model names stop being useful

The three-model taxonomy is now stretched well past what it was designed for, and it is worth knowing where it stops helping. Serverless functions are PaaS by most readings, but they bill per invocation rather than per instance and scale to nothing, which changes the cost model entirely. Managed databases sit awkwardly between IaaS and PaaS. Container platforms are PaaS that still expects you to understand the runtime in detail.

AI services have made this worse and more interesting. Gartner forecast worldwide AI-optimised infrastructure-as-a-service spending to grow 96% through 2026 to reach $42 billion, and separately forecast sovereign cloud infrastructure-as-a-service spending at $80 billion in 2026, a 35.6% rise. A hosted model endpoint you call by API is sold as infrastructure, behaves like a platform and is consumed like software. The label tells you nothing; the responsibility boundary still does.

Adoption of AI as a cloud service is following the money. Flexera’s 2026 State of the Cloud Report found 81% of respondents using generative AI, up from 72% the previous year and 47% in 2024, and recorded generative AI as the third most widely used public cloud service at 58% adoption. The same report put estimated wasted cloud spend at 29%, its first increase in five years, and named AI workloads as the cause. Fast adoption and poor cost control are arriving together.

Picking a model for a real workload

Forget the taxonomy and answer three questions about the workload in front of you. They resolve almost every case we see.

1. Does a product already exist that does this? If yes, buy the SaaS. Email, accounting, payroll, help desk, CRM, file sharing and video calls are all solved problems, and a custom build will cost more and do less.
2. Is it your own application? Then start at PaaS. App Service, a managed container service or a managed database removes the operational work that adds no value to your customers.
3. Does something force you lower? A specific operating system version, a kernel module, licensing that demands dedicated hardware, or software that predates containers. Then use IaaS, and treat it as a deliberate choice with a maintenance cost attached.

The failure mode we see most often is choosing IaaS by default because it looks familiar, then discovering that twelve virtual machines need patching and nobody owns the job. The second most common is choosing SaaS for something genuinely specific to the business and spending a year bending the product into shape. Both are avoidable with half an hour of honest conversation at the start.

If you want help having that conversation, Eudora does this assessment remotely for clients worldwide through our cloud solutions practice: a workload inventory, a model recommendation for each item, and the cost arithmetic written down. It pairs naturally with the on-premises comparison, and if you have already decided to go to public cloud and just need to choose a provider, the six major providers side by side is the next thing to read.

Want each workload mapped to the right service model, with the prices and the ongoing effort both written down? Get in touch with Eudora Technology to talk about your project.