Azure PaaS vs IaaS vs SaaS, explained with examples

Three words that describe one thing: how far up the stack the cloud provider manages before it hands the rest to you. The cert wants the definitions. The job wants you to pick the right one when control and cost pull in opposite directions.

New to cloud? CAMPUX is a free, build-first course. Start here →

IaaS, PaaS, and SaaS differ by one thing — who manages what. With IaaS (Azure Virtual Machines) you rent a bare machine and run the OS, patching, and runtime yourself. With PaaS (Azure App Service) you hand the servers to Microsoft and just deploy code. With SaaS (Microsoft 365) you run nothing and sign in to finished software. Same spectrum, three stops.

That's the whole model. Everything else is detail on where the handoff line sits. The trick most explainers reach for is pizza-as-a-service — dine-in versus takeout versus baking at home. It's memorable and it's useless the moment you're staring at the Azure portal deciding what to deploy. So drop the pizza. The real frame is simpler: what do you rent, and what do you run? Rent more, run less. Rent less, run more. Every one of these three is a different answer to that trade.

What you rent vs what you run

Picture the stack it takes to serve an app: the data center and network at the bottom, then the physical servers, then virtualization, the operating system, the runtime and middleware, and finally your application and its data at the top. On-premises, you own all of it — you buy the servers, patch the OS, and answer for the building's power. The three cloud models are just different heights at which the provider stops managing and you take over.

• IaaS — you rent the machine, you run the software. Microsoft owns the building, the hardware, and the hypervisor. You get a virtual machine and everything above the OS is yours: patching, the runtime, the app, the backups. Most control, most work.
• PaaS — you rent the platform, you run the code. Microsoft also takes the OS, the patching, the load balancing, and the scaling. You bring an application and a config. You never log into a server because there isn't one you're allowed to see.
• SaaS — you rent the software, you run nothing. Microsoft runs the whole stack and ships you a finished product. Your job shrinks to configuring it and managing your own data and users.

The line moves up, your responsibility shrinks, and — this is the part the definitions skip — so does your control. That's the trade the whole decision turns on. We cover exactly where these lines fall in Class Four, on IaaS, PaaS, and SaaS.

The same website, at three heights

Concrete beats abstract, so run one workload — a company website with a small API — through all three.

On IaaS, you provision an Azure Virtual Machine, pick Ubuntu or Windows Server, install the web server and runtime yourself, deploy your code, and set up TLS. When a CVE lands in the OS next month, patching it is your calendar item. In return you can install literally anything and control every setting. This is where legacy apps live — the ones that need a particular kernel version or a licensed component that only runs on a real OS.

On PaaS, you create an Azure App Service, point it at your code or a container, and it runs. The OS is patched for you. Scaling out under load is a slider or an autoscale rule, not a night of building a load balancer. You gave up the ability to log into the box — and for most web apps, that's a thing you never needed. The tradeoff is favorable precisely because you weren't using the control you surrendered.

On SaaS, you don't build the website at all — you stand up a static marketing site behind Microsoft's own tooling or, more to the point, you realize the "app" you needed was email and document collaboration, and you buy Microsoft 365 instead of running mail servers. Nobody patches Exchange because nobody's running Exchange.

Rent more, run less. The whole decision is choosing how much you're willing to run.

The gap the cert leaves open

Here's where certified and job-ready split. The AZ-900 and every fundamentals quiz will ask you to identify the model: "A team wants to deploy code without managing the underlying OS — which service model?" You circle PaaS, you get the point, you move on. That's a recall test, and it's worth passing.

The job never phrases it that cleanly. On the job the question arrives as a tradeoff with money and control on opposite ends, and nobody tells you which model is the answer. Someone says "we need to move this 2014-era app to Azure by Q3." Nobody in that room says the word IaaS. Your job is to notice that the app can't be refactored in a quarter, so PaaS is off the table, so it's a VM for now with a plan to modernize later. The model is a conclusion you reach, not a term you recite.

The senior move is a default and a reason to deviate from it: reach for the most managed option that still gives you the control you need. Start at SaaS. Can you buy this instead of building it? If yes, stop — you just saved months. If you have to build it, drop to PaaS and let the platform run the servers. Only fall to IaaS when something concrete forces your hand: an OS requirement, a licensing constraint, a piece of software that assumes a real machine, or a migration deadline that refuses a rewrite.

The cost trade, stated honestly

People assume IaaS is cheapest because a VM's hourly rate looks small. That's the sticker price, not the bill. The real cost of IaaS includes the engineer-hours to patch, secure, and operate the thing — and those hours are the most expensive line item you have. PaaS charges you more per unit of compute and gives most of those hours back. For a small team, the fully loaded cost of PaaS is frequently lower than IaaS even when the compute meter reads higher, because you're not paying a person to do undifferentiated server care.

Azure's pricing is consumption-based across all three — you pay for what you run, billed by the hour or by usage tier, and it changes often. Don't trust any specific number you read in a blog, this one included; open the Azure Pricing Calculator and price your own shape before you commit. The durable point isn't a dollar figure. It's that the cheapest-looking option on the compute meter is often the most expensive option on the payroll, and cloud cost is a topic you learn to reason about deliberately — which is the whole of Class 32 on cost management and FinOps.

Where the responsibility line matters most

One thing does not shrink as you move up the stack: your accountability for your own data and identities. On IaaS you secure a lot — the OS, the firewall, the patching. On SaaS you secure less of the machinery, but you still own who has access and what happens to your data. Microsoft secures the cloud; you secure what you put in it, at every level. That split is the shared-responsibility model, and it's the reason "we moved to SaaS so security is handled" is a sentence that gets companies breached. The provider handles their half. Your half never leaves your desk.

Common questions