IaaS vs PaaS vs SaaS: Cloud Service Types Explained

A cloud service type describes how the responsibility for running technology is split between you and the cloud provider. Every application depends on a stack of layers: physical hardware and connectivity, network and storage, the virtualization host, the operating system, the runtime and middleware, and finally the application and its data. On premises you own every layer. Cloud service types let the provider take over the lower layers so you can focus on what matters to you.

There are three main types, and they form a ladder. Infrastructure as a Service (IaaS) hands you the lowest layers as a service but leaves the operating system and everything above it to you. Platform as a Service (PaaS) adds the operating system, middleware, runtime and development tools, so you manage your application and data. Software as a Service (SaaS) delivers a finished application that the provider runs; you use it.

Two things change together as you climb the ladder. The provider does more and you do less, and you give up flexibility in exchange for ease. In Microsoft's words, IaaS is the most flexible category of cloud service, while SaaS is the least flexible but the easiest to get up and running. Choosing a type means deciding how much control you need versus how much work you want to hand off.

Other "as a service" labels exist but are not one of these three types. Desktop as a Service (DaaS), such as Azure Virtual Desktop, delivers hosted Windows desktops and apps that users connect to; it is neither a platform for deploying your own code nor a finished business application. Serverless computing, such as Function as a Service (for example Azure Functions), runs your code without you managing servers; Microsoft describes it as PaaS-like, because the provider manages the infrastructure while you supply the code. Deployment models (public, private, hybrid cloud) are a separate idea again: they describe where resources run, not who manages which layer.

Infrastructure as a Service (IaaS) rents you fundamental computing resources over the cloud: virtual machines, storage, and networking. The provider maintains the physical hardware, internet connectivity and physical security of the datacenter, plus the virtualization host. Everything else is your responsibility: installing, configuring, patching and maintaining the operating system; network configuration (for example the address ranges, subnets and firewall rules of your virtual networks); database and storage configuration; installing runtimes and middleware; deploying your applications; and managing your data.

IaaS gives you the most control of the three types, and that control comes with the most work. Because you own the operating system, you can choose a specific OS or OS version, install your own software agents into the OS, add custom drivers and change OS-level settings such as the registry. No PaaS or SaaS offering gives you that OS-level access.

Two details catch people out:

• Azure tooling does not move OS responsibility to Microsoft. Features such as Azure Update Manager or automatic VM guest patching help you schedule and apply OS updates, but you choose to enable and configure them, and the guest operating system remains yours to keep secure.
• Scaling features do not change the type. Azure Virtual Machine Scale Sets add and remove VM instances automatically, but every instance still runs an operating system that you manage. It is still IaaS.

The classic Azure example of IaaS is Azure Virtual Machines: you provision a virtual server, choose its operating system, and manage it yourself. Running a database engine such as SQL Server on Azure Virtual Machines is also IaaS, because you still patch the Windows or Linux OS beneath it.

Platform as a Service (PaaS) provides a managed environment for building, deploying, and running applications. The provider maintains the infrastructure and the operating system, middleware, runtime, development tools and, where offered, analytics services. You do not install, patch or license operating systems or database engines; there is no OS for you to sign in to. You manage your application code and your data, plus who can access them.

"Your application" includes everything you bundle into it. If your team packages an open-source library or framework with its code, that package is part of your app, and you update it when a vulnerability is reported, even though the provider patches the operating system and platform underneath. PaaS also removes OS patching, not application maintenance: you still deploy each new version of the app you run and apply its upgrades. Only SaaS takes application upgrades off your hands.

Azure examples of PaaS include:

• Azure App Service for hosting web apps and APIs, with built-in scaling.
• Managed databases: Azure SQL Database, Azure SQL Managed Instance and Azure Database for MySQL flexible server. You work with databases and data; Microsoft maintains the servers, OS and engine patching.
• Azure Container Apps, which runs your containers without you managing hosts or their OS. You still build, deploy and update the container image that holds your application.

None of these services gives you access to the host operating system: you cannot install agents or drivers into it or pick its version. With Container Apps you control only what goes into your own image. If a requirement needs control of the operating system itself, PaaS is ruled out and IaaS is the fit.

Network settings in PaaS are shared. Microsoft runs the network beneath the platform, but you decide how your app or database is reached: its firewall rules, private endpoints and virtual network integration are yours to configure.

Software as a Service (SaaS) is a finished application delivered over the internet. The provider runs the whole stack, including the application itself: it fixes defects in the application's code and rolls out new versions and updates. You typically pay a subscription and use the app through a browser or client.

What stays with you is set out in Microsoft's description of SaaS:

• Your data: the information you put into the system.
• Identities and access: which users have access and what they can do. This holds even when the sign-in service is itself run by a provider. If staff sign in to a SaaS app with accounts from your organization's Microsoft Entra ID tenant, creating and disabling those accounts (for example when someone leaves) is your job, not the SaaS vendor's.
• Devices: which devices are allowed to connect, and their security posture.

Configuring a finished application is still SaaS. Choosing workflows, branding, notification settings or custom fields in an app's admin console uses options the vendor built; you are not writing or hosting code, so it does not make the service PaaS.

SaaS examples include Microsoft 365 for email, documents and collaboration, and Dynamics 365 for business applications such as customer relationship management (CRM). SaaS is the least flexible type, since you cannot change how the software is built or hosted, but it is the quickest to adopt.

The quickest way to place a service is to ask who manages the operating system: you (IaaS) or the provider (PaaS and SaaS). The second question separates PaaS from SaaS: who maintains the application? The table compares the three types layer by layer. "Provider" means the cloud provider manages that layer; "You" means the customer does.

Data, accounts and devices stay with you in every type. That is the cloud service type view of the shared responsibility model, covered in the lesson on cloud computing.

A service type describes how you consume a workload, not what the workload is. The same database engine or business application can be run as IaaS, PaaS or SaaS, and the responsibility split follows the type you pick, not the product name.

Read each row from left to right to see what you stop doing. Moving SQL Server from VMs to Azure SQL Database ends OS patching and engine patching for you, while your databases, data and access remain yours. Moving an app from VMs to App Service ends OS patching but you still deploy and upgrade the app; moving to the vendor's hosted edition ends both, and your data and user accounts are what you keep.

Picking a service type comes down to how much control a workload needs and how much you want to manage. Microsoft lists these scenarios for each type.

Choose IaaS for lift-and-shift migration (moving existing on-premises servers to the cloud with few changes) and testing and development environments you create and tear down quickly. It is also the answer whenever a workload needs OS-level control: a particular OS version, custom drivers, registry settings, or agents installed in the operating system.

Choose PaaS for a development framework: developers build or customize cloud applications on a managed platform without patching servers, and get scaling and tooling built in. PaaS also fits analytics or business intelligence, where a team uses managed tools to analyze and mine its own data, find insights and patterns, and builds its own solution on top, without installing or maintaining analytics servers.

Choose SaaS for ready-made business software: email and messaging, business productivity applications, and finance and expense tracking; other common examples are payroll and CRM. The trigger is that users need working software, not something to build.

When a scenario lists several workloads, decide each one separately and pick the type with the least management effort that still meets that workload's requirements. One company can end up using all three types at once, because each workload is judged on its own requirements rather than the company choosing a single type.

Work through these situations with two tests: who manages the operating system, and who maintains the application?

Scenario 1. A retailer is closing its datacenter and must move a line-of-business server to Azure quickly, unchanged, with its own OS hardening settings. Which type? A lift-and-shift that keeps OS control is IaaS (Azure Virtual Machines). The retailer still owns the OS, its virtual network rules and storage configuration.

Scenario 2. A start-up is writing a new mobile back end and wants automatic scaling with no servers to patch. Which type? PaaS (for example App Service). The start-up still owns its code, the libraries it ships, its data and its releases.

Scenario 3. A charity needs a donor CRM that volunteers can use next week, with no IT staff to run it. Which type? SaaS. The charity still controls its donor data, who has accounts, and which devices may connect.

Scenario 4. A school hosts a third-party library catalogue system on its own VMs and is weighing two moves: redeploying the same software to a PaaS host, or subscribing to the vendor's hosted edition. What changes with each? The PaaS move takes the operating system off the school's hands, but the school still installs each new release of the catalogue software. The SaaS move hands both the platform and the application releases to the vendor; the school keeps its catalogue data and the user accounts.