Cloud computing services explained: IaaS, PaaS, and SaaS
People throw around IaaS, PaaS, and SaaS as if everyone was in the room when they were defined. Here is the plain version: the three letters describe how much of the stack the provider runs for you, and once that clicks, the whole cloud gets a lot easier to read.
New to cloud? CAMPUX is a free, build-first course. Start here →
Cloud computing services deliver computing, storage, databases, and networking over the internet, and they come in three main models: Infrastructure as a Service (IaaS) gives you virtual machines and networks; Platform as a Service (PaaS) gives you a managed place to run code; and Software as a Service (SaaS) gives you finished applications. That single sentence is the map. The rest of this note walks the territory, with real Azure and AWS examples so the words stop being abstract.
What "cloud computing services" means
Before the cloud, running an application meant owning the whole stack: a building with power and cooling, physical servers, the operating systems on them, and finally your software on top. If traffic doubled, you bought more servers and waited weeks for them to arrive. Cloud computing services replace that with things you rent by the hour or the request from a provider like Microsoft Azure or Amazon Web Services. You stop owning the bottom of the stack and start renting exactly the layer you need.
The three models are just three places to draw the line between what you manage and what the provider manages. Draw it low and you get a lot of control and a lot of chores. Draw it high and you get almost no chores and almost no control. IaaS, PaaS, and SaaS are three standard places to draw that line, moving from most work on your side to least.
An old restaurant analogy makes this stick. Making pizza at home means you handle everything — dough, oven, the kitchen itself. Buying a take-and-bake pizza means the shop made the pizza but you supply the oven and the table. Ordering delivery means someone else makes it, drives it, and you only bring the plates. Dining out means you bring nothing but yourself. IaaS is take-and-bake, PaaS is delivery, and SaaS is dining out. Each step up hands one more layer to somebody else.
IaaS: infrastructure you control
Infrastructure as a Service rents you the raw building blocks: virtual machines, storage disks, and virtual networks. The provider runs the physical hardware, the data center, and the layer that turns one big machine into many virtual ones. Everything from the operating system up is yours to install, patch, secure, and babysit.
The clearest example is a virtual machine. On Azure you create an Azure Virtual Machine; on AWS the equivalent is Amazon EC2. In both cases you pick an operating system image, size the CPU and memory, attach a disk, and a few minutes later you have a server you can log into — one that no forklift ever delivered. Object storage such as Azure Blob Storage or Amazon S3 sits in the same family: raw capacity you build on top of.
IaaS is the model that feels most like the old data center, which is exactly why teams reach for it when they are moving an existing application to the cloud without rewriting it, or when a compliance rule says they must control the operating system themselves. The trade is honest: you keep the control, so you keep the patching, the security hardening, and the 2 a.m. reboot.
PaaS: a managed runtime
Platform as a Service moves the line up. Now the provider also runs the operating system, the patches, and the language runtime, and hands you a managed place to deploy your code. You bring the application and its data; you do not think about the server underneath it at all.
On Azure the headline example is Azure App Service: you push a web app written in .NET, Node, Python, or Java, and it runs, scales, and gets patched without you ever opening a shell on the host. The AWS counterpart is AWS Elastic Beanstalk, which takes your code and provisions and manages the machines behind the scenes. Managed databases fit here too — Azure SQL Database and Amazon RDS give you a running database engine without a server to maintain.
The reason PaaS is popular is simple: most teams do not want to be in the server-maintenance business. They want their code online. PaaS deletes an entire category of work — no operating-system updates, no capacity planning for the base machine — in exchange for living inside the platform's supported languages and conventions. For a brand-new application that fits those conventions, that is usually a trade worth making.
SaaS: finished software
Software as a Service is the top of the ladder. There is no code to deploy and no server to think about, because the product is a finished application you sign into and use. The provider runs absolutely everything below the login screen.
You already use plenty of it. Microsoft 365 — Outlook, Word, Excel, Teams in the browser — is SaaS: Microsoft runs the servers, the storage, and the updates, and you just work. Salesforce is the textbook business example, a customer-relationship platform your sales team logs into every day without anyone on your side owning a server. Gmail, Dropbox, and Zoom are the same idea. When you "buy" SaaS, you are buying a login and a subscription, not infrastructure.
The catch mirrors the benefit. You gave up the chores, so you also gave up deep control. You configure the product within the knobs it exposes, and you live with its release schedule and its limits. For the enormous number of problems where a finished product already exists — email, chat, expense reports, CRM — that is exactly what you want.
The three models compared
Laid side by side, the pattern is easy to see: as you move from IaaS to SaaS, the "you manage" column shrinks and the "provider manages" column grows.
| Model | You manage | Provider manages | Azure example | AWS example |
|---|---|---|---|---|
| IaaS | Operating system, patches, runtime, your app and data | Physical servers, storage, networking, virtualization | Azure Virtual Machines | Amazon EC2 |
| PaaS | Your app and its data, plus some configuration | Everything below your code: OS, runtime, servers, scaling | Azure App Service | AWS Elastic Beanstalk |
| SaaS | Your data, users, and settings inside the app | The entire stack, including the application itself | Microsoft 365 | Salesforce |
Read any row left to right and it answers the only question that matters when someone says "it's PaaS": where does my job stop and the provider's job start.
The three letters are not products. They are three places to draw one line — the line between your chores and the provider's.
How to choose the right model
A useful default is to hand off as much as you can. Start at the top and work down only when you hit a wall: if a SaaS product already solves the problem, use it and move on, because nothing you build will run email better than a team whose whole job is email. If you are deploying your own application and it fits a managed platform, reach for PaaS and let the provider carry the servers. Drop to IaaS only when you genuinely need control of the operating system — a legacy app that will not run anywhere else, unusual software you must install yourself, or a compliance rule that demands it. Every step down the ladder buys control and costs time, so pay only for the control you will actually use.
Two newer patterns sit alongside this ladder rather than replacing it. Serverless — Azure Functions, AWS Lambda — is PaaS taken to its logical end: you deploy a single function and are billed only while it runs, with no idea a server exists. Containers land in between; a managed service like Azure Kubernetes Service or Amazon EKS still asks you to think about the cluster, so it behaves more like IaaS with strong PaaS conveniences layered on. When someone hands you a new service, the fast way to place it is to ask the same question the table asks: how much of the stack am I still responsible for?
Knowing where that line falls is also the daily work of the people who run these systems. If you want to see how the models show up in a job, the notes on what a cloud DevOps engineer does and what DevOps actually means pick up right where this one leaves off.
Questions people also ask
What are the three types of cloud computing services?
The three types are Infrastructure as a Service, Platform as a Service, and Software as a Service. IaaS rents you raw building blocks like virtual machines, storage, and networks. PaaS gives you a managed place to run your own code without touching the servers underneath. SaaS is finished software you sign into and use, such as email or a CRM.
What is the difference between IaaS, PaaS, and SaaS?
The difference is how much the provider manages for you. With IaaS you manage the operating system, patches, and everything you install, while the provider runs the physical hardware. With PaaS the provider also manages the operating system and runtime, so you only bring your code and data. With SaaS the provider manages everything, and you just use the application.
Is Microsoft 365 SaaS or PaaS?
Microsoft 365 is Software as a Service. You sign in and use finished applications like Outlook, Word, and Teams in the browser, and Microsoft runs all the servers, updates, and storage behind them. You never manage an operating system or a runtime, which is what separates SaaS from PaaS.
Which cloud service model should I use?
Pick the model that hands the most work to the provider while still meeting your needs. If a finished SaaS product already does the job, use it. If you are deploying your own application, PaaS lets you skip server maintenance. Choose IaaS only when you need deep control over the operating system, such as for a legacy app or a strict compliance requirement.