IaaS vs PaaS vs SaaS: Differences, Examples, and When to Use Each

The three cloud service models differ in how much of the technology stack you manage versus how much the provider manages. Infrastructure as a Service (IaaS) hands you virtual machines, storage, and networking and leaves the operating system and everything above it to you. Platform as a Service (PaaS) adds a managed operating system and runtime so you only write and deploy code. Software as a Service (SaaS) removes even that, delivering a finished application you simply use. Picking the right one comes down to a single question: how much of the stack does your team actually need to control? This service-model spectrum is a separate axis from deployment model — you can run IaaS, PaaS, or SaaS within a public, private, or hybrid environment — and the two are easy to conflate on exam day.

What each model actually gives you

Infrastructure as a Service rents the raw building blocks of computing — virtual machines, virtual networks, and storage — while the customer installs, configures, and patches the guest operating system and anything running on it. Azure Virtual Machines, Azure Virtual Network, and unmanaged Azure Storage accounts are IaaS. This model looks the most like running your own datacenter, except Microsoft owns the physical hardware, the racks, the power, and the virtualization layer beneath your VM.

Platform as a Service supplies a ready-made runtime, operating system, and middleware so developers deploy application code directly, without provisioning or patching servers. Azure App Service, Azure SQL Database, and Azure Functions are PaaS. The provider handles OS patching, runtime updates, and often automatic scaling, which is why PaaS is the default choice for teams building new custom applications who don’t want an operations burden.

Software as a Service delivers a complete, ready-to-use application that customers access over the internet, typically through a browser, with the vendor handling every layer beneath it — infrastructure, platform, and the application itself. Microsoft 365 and Dynamics 365 are the textbook Azure-ecosystem examples. The customer’s only real work is managing users, licenses, and data inside the finished product.

The management-responsibility spectrum

The single fact that resolves almost every exam question on this topic is where operating-system control sits. IaaS gives the customer full guest OS access — installing custom drivers, applying kernel-level hardening, or running a specific antivirus agent all require IaaS, because PaaS and SaaS abstract the OS away entirely. Move up the stack and that control shifts to the provider, along with the patching burden.

	IaaS	PaaS	SaaS
Customer manages	OS, runtime, apps, data	Apps and data only	Data and user access only
Provider manages	Physical hardware, virtualization	+ OS, runtime, patching	+ Application itself
OS-level / kernel access	Yes	No	No
Typical use case	Lift-and-shift migration, custom OS or driver needs	New custom app development	Ready-made business function (email, CRM, ERP)
Azure examples	Virtual Machines, Virtual Network	App Service, Azure SQL Database, Functions	Microsoft 365, Dynamics 365

Choosing the right model for a migration or new build

Three questions settle most real-world decisions:

Are you moving an existing workload with minimal changes, or building something new? A lift-and-shift migration that must preserve a specific operating system configuration, a legacy driver, or an installed antivirus agent belongs on IaaS — the destination virtual machine can replicate the source environment almost exactly. A brand-new application with no such constraints is usually cheaper to operate on PaaS, since nobody has to patch the OS or babysit the runtime.

Does the team need to write custom code at all? If the answer is no — you just need email, a CRM, or an HR system that already exists — SaaS is the fit. If the answer is yes, you’re choosing between IaaS and PaaS based on how much infrastructure control that code requires.

Does the workload need something a managed runtime doesn’t support? Kernel-level drivers, an unsupported middleware version, or direct filesystem access to install a mandated security agent are the classic reasons engineering teams reject PaaS in favor of IaaS, even when PaaS would otherwise reduce their workload. If a managed database engine covers your needs, though, Azure SQL Database (PaaS) removes patching and backup work that SQL Server on a virtual machine (IaaS) would leave with your team.

Understanding the shared responsibility model makes this decision concrete: it maps exactly which security and management tasks move from customer to provider as you go from IaaS to PaaS to SaaS, which is the same axis this whole comparison runs on.

Blended and edge cases

Not every Azure service sits cleanly in one bucket. Azure Kubernetes Service (AKS) is a common exam trap: Azure manages the Kubernetes control plane (a PaaS trait), but your team still sizes, configures, and patches the virtual machine node pools that run your containers (an IaaS trait). That makes AKS a hybrid — PaaS for orchestration, IaaS for the underlying compute. Comparing App Service, Functions, and container options covers where each managed-compute service lands on this spectrum in more detail.

Serverless offerings like Azure Functions are classified as a specialized form of PaaS rather than a fourth category — the provider still owns the OS and runtime, it just also handles scaling to zero and per-execution billing automatically.

How the AZ-900 exam tests this

• Scenario matching by constraint, not by name. A stem rarely says “which is IaaS?” outright. Instead it describes a requirement — “needs full administrative access to install custom drivers,” “wants to write code without patching servers,” “wants a finished application with nothing to install” — and expects you to translate that requirement into IaaS, PaaS, or SaaS respectively.
• Azure service classification. Expect direct questions asking whether Azure Virtual Machines, Azure SQL Database, Azure App Service, Microsoft 365, or Azure Functions represents IaaS, PaaS, or SaaS. Memorize the anchor examples: VMs and Virtual Network are IaaS; App Service, Azure SQL Database, and Functions are PaaS; Microsoft 365 and Dynamics 365 are SaaS.
• “Most control” versus “least management effort” ranking questions. These test the same spectrum from opposite ends: IaaS has the most customer control and the most management burden; SaaS has the least of both; PaaS sits in the middle. Don’t let the wording (“most control” vs. “least effort”) trick you into picking the wrong end.
• Compliance and customization traps. A scenario where a regulator requires the customer’s own team to install and audit OS-level security software is IaaS, even if the requirement is otherwise inconvenient — no amount of “PaaS reduces overhead” reasoning overrides an explicit OS-access requirement. Similarly, customizing a SaaS product with its own built-in low-code tools doesn’t reclassify it as PaaS; the vendor still owns hosting and updates.

Ready to test this against real exam-style questions? Practice AZ-900 questions on cloud service models to check whether you can classify scenarios as fast as the exam presents them.

Quick reference

• IaaS = rented VMs, storage, and networking; customer manages OS, runtime, and apps. Examples: Azure Virtual Machines, Virtual Network.
• PaaS = managed OS and runtime; customer manages only code and data. Examples: Azure App Service, Azure SQL Database, Azure Functions.
• SaaS = finished application; customer manages only users and data. Examples: Microsoft 365, Dynamics 365.
• OS-level or kernel access (custom drivers, mandated security agents) always points to IaaS.
• Control and management burden both decrease moving from IaaS → PaaS → SaaS; they never move independently of each other.
• AKS blends the two models: PaaS for the control plane, IaaS for the node pools you patch.
• Serverless (Azure Functions) is a specialized PaaS offering, not a separate fourth service model.
• When a scenario mentions “no custom code, just a finished product,” it’s describing SaaS regardless of what infrastructure runs underneath it.