IaaS vs PaaS vs SaaS: Cloud Service Models Explained

You are comparing cloud options, and every vendor uses a different acronym. One proposal says “IaaS,” another says “PaaS,” and your accounting software calls itself “SaaS.” They sound similar, but they describe very different deals: how much of the technology you run yourself, how much the provider runs, and who gets the call when something breaks.

This guide explains the 3 cloud service models in plain English, shows a responsibility chart of who manages what, and helps you match each model to your workloads.

The 3 service models in one sentence each

The definitions most of the industry uses come from the US National Institute of Standards and Technology (NIST) publication SP 800-145:

• Infrastructure as a Service (IaaS): you rent processing, storage and networking, and you can run any software on it, including your own operating systems. You control the operating system, storage and applications.
• Platform as a Service (PaaS): you deploy your own applications onto a managed platform using the languages and tools the provider supports. You control your applications and some settings, but not the servers or operating systems.
• Software as a Service (SaaS): you use the provider’s finished application, usually in a browser. You manage little beyond your users and a few configuration settings.

A common analogy is food. IaaS is renting a commercial kitchen: you bring the ingredients, cooks and recipes. PaaS is a meal kit: the prep is done, and you finish the cooking. SaaS is eating at a restaurant: you just order.

The responsibility chart: who manages what

This is the part that matters most. Every cloud technology stack has the same layers, and the service model decides where the line falls between you and the provider.

This is a simplified view. Real responsibilities blur at the edges. Microsoft’s own shared responsibility matrix, for example, lists applications and network controls as “shared” in PaaS, and client devices as “shared” in SaaS. In PaaS, you write and secure your code while the provider runs the platform underneath it. In SaaS, you still configure settings, sharing rules and access.

Microsoft’s guidance is clear on one point: in every cloud model, you always retain responsibility for your data, your endpoints, your accounts and your access management. AWS uses similar language, describing the provider’s job as security “of” the cloud and the customer’s job as security “in” the cloud, with the customer’s share depending on which services it chooses.

Key takeaway: The cloud never takes over responsibility for your data or your user accounts. Whatever model you choose, you still decide who has access, turn on multi-factor authentication and protect what you store.

IaaS: maximum control, maximum responsibility

IaaS gives you virtual machines, storage volumes and networks that behave much like your own hardware, minus the physical upkeep.

Common examples: Amazon EC2, Azure Virtual Machines, Google Compute Engine, and block or object storage services.

Best for: - Moving existing applications to the cloud with few changes (“lift and shift”) - Software that needs a specific operating system, version or configuration - Teams with system administration skills who want full control

What you take on: operating system patches, security hardening, firewall rules, backups, monitoring and scaling. If you run a virtual server and never patch it, that risk is yours, not the provider’s.

Pricing model: usually pay-as-you-go by compute time, storage and data transfer, with discounts for longer commitments. Costs vary widely by size, region and usage.

PaaS: focus on code, not servers

PaaS hands developers a managed environment. They push code, and the platform handles servers, operating systems, runtime updates and often scaling.

Common examples: Azure App Service, Google App Engine, Heroku, AWS Elastic Beanstalk, and managed databases such as Azure SQL Database or Amazon RDS. Serverless function services, such as AWS Lambda and Azure Functions, sit at the far end of this spectrum. See our guide to serverless computing for how they differ.

Best for: - New web applications and APIs - Small development teams without dedicated operations staff - Projects where speed to launch matters more than fine control

What you take on: your application code, its dependencies, configuration, secrets and access controls. The provider keeps the platform patched.

Trade-offs: you work within the platform’s supported languages, versions and limits, and moving to another provider can take real effort.

Pricing model: typically based on instance size, running time, requests or database capacity.

SaaS: ready-made software

SaaS is the model most businesses use every day. You subscribe, log in and work.

Common examples: Microsoft 365, Google Workspace, Salesforce, Zoom, QuickBooks Online and Shopify.

Best for: - Standard business functions such as email, accounting, CRM, HR and e-commerce - Teams without IT staff - Anything where a well-established product already does what you need

What you take on: user accounts, permissions, sharing settings, data you put in, and integrations. You also take on vendor risk: if the vendor changes pricing or features, you adapt.

Pricing model: usually per user per month or per plan tier, sometimes with usage add-ons. Our guide on whether Microsoft 365 Copilot is worth it shows how SaaS add-ons can change the math.

Side-by-side comparison

Most businesses do not pick just 1 model. A typical company might run Microsoft 365 (SaaS), host its customer portal on a PaaS service and keep a legacy app on a virtual machine (IaaS).

How to choose the right model

Work through these questions for each workload, not for the business as a whole:

1. Does a SaaS product already do this well? If yes, use it. Building and running your own version of email, payroll or accounting rarely makes sense.
2. Are you building something custom? If yes, start with PaaS or serverless so developers spend time on features, not servers. Our platform engineering guide shows how larger teams standardize this.
3. Does it need a specific operating system, legacy software or deep configuration? If yes, IaaS is the realistic option.
4. Who will maintain it? Be honest about skills. IaaS without someone to patch and monitor servers is a security problem waiting to happen.
5. What data does it hold? Regulated data, such as health records, needs vendors that will sign the right agreements. Our HIPAA compliance guide and SOC 2 compliance guide cover what to ask for.

Where to start

If you are new to the cloud, follow this order:

1. Audit your SaaS. List every subscription, its owner and its admin accounts. Turn on multi-factor authentication everywhere.
2. Use PaaS for new custom projects. It gives you the shortest path to a running app with less operational risk.
3. Reserve IaaS for workloads that truly need it. Plan who patches, backs up and monitors each server before you create it.
4. Pick a provider deliberately. Compare the big 3 with our AWS vs Azure vs Google Cloud guide, and use a cloud migration checklist for anything you move.

New to terms like runtime, middleware or hypervisor? Our glossary has short definitions.

The bottom line

IaaS, PaaS and SaaS are 3 points on the same line. IaaS gives you the most control and the most work. SaaS gives you the least work and the least control. PaaS sits in the middle, built for developers who want to ship code without running servers. Choose per workload, default to the most managed option that meets your needs, and remember that your data and user access are always your job.

Sources

• NIST SP 800-145: The NIST Definition of Cloud Computing — official definitions of IaaS, PaaS and SaaS
• Microsoft Learn: Shared responsibility in the cloud — responsibility matrix by service model and responsibilities customers always retain
• AWS Shared Responsibility Model — security “of” vs “in” the cloud and how it varies by service