IaaS vs PaaS vs SaaS: what each model means for cost, control and security
The three cloud service models differ in one thing above all: how much of the stack you still run yourself. That decides your staffing, your security work and how you pay.
The labels come from NIST, which in 2011 defined three cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). The definitions have held up. What has changed is how many products blur the lines, which makes the underlying question more useful than the label: which layers of the stack do you still manage?
The short version
| IaaS | PaaS | SaaS | |
|---|---|---|---|
| You get | Virtual machines, storage and networks | A managed runtime to deploy your own code | A finished application |
| You manage | Operating system, middleware, runtime, application, data | Your application and data | Your data, users and settings |
| Provider manages | Physical hardware, hypervisor | Hardware, operating system, runtime | Almost everything |
| Typical examples | Amazon EC2, Azure Virtual Machines, Google Compute Engine | Azure App Service, Google App Engine, AWS Elastic Beanstalk | Microsoft 365, Salesforce, ServiceNow |
| Pricing usually tracks | Compute hours, storage, data transfer | Instances or requests | Users or seats |
IaaS: most control, most work
IaaS gives you servers without the data center. You choose the operating system, patch it, harden it and run whatever you like on top.
That control is the reason to choose it. Lifting an existing application into the cloud without rewriting it, running software with specific OS requirements, or keeping full control over configuration all point to IaaS.
The cost is staff time. Under Microsoft's shared responsibility model, the operating system, network controls and applications on IaaS are all the customer's job. If your team is already stretched patching on-premises servers, moving them to IaaS changes the landlord, not the workload.
PaaS: you bring the code
With PaaS, the provider runs the operating system and runtime, and you deploy your application to it. Patching the OS stops being your problem. Scaling is usually a setting.
PaaS suits applications your team builds or maintains, especially web applications and APIs. The trade-off is less control and some lock-in: platform-specific features make it harder to move later.
SaaS: you run the settings
SaaS is the finished product. You configure it, manage users and own your data. For standard business functions such as email, CRM and IT service management, SaaS is usually the default today.
A common mistake is to assume SaaS means no security work. Microsoft's guidance is clear that data, identities, access management and configuration stay with the customer in every model. Most SaaS incidents come from those layers: weak sign-in controls, over-shared files and risky integrations.
How to choose
Start with the workload, not the model.
- If you are buying a standard business function, look for SaaS first.
- If you are running code your team writes or maintains, choose PaaS unless you need control of the operating system.
- If you are moving an existing application as it is, or need full control of the server, choose IaaS.
Most companies end up with all three. The useful exercise is a list of every cloud service you pay for, with the model it uses and the layers your team is responsible for. That list tells you where your security and operations effort actually goes.
What IT teams should do
- List every cloud service you pay for and tag it IaaS, PaaS or SaaS.
- For each IaaS workload, ask whether a PaaS or SaaS option would remove patching work.
- Check that MFA and access reviews cover your SaaS applications, not only your servers.