What is PaaS in Azure?
Platform as a Service is the layer where you hand Azure your code or your data and stop caring about the machine underneath. The trick is not memorizing the definition — it is knowing when to reach for it instead of a VM.
New to cloud? CAMPUX is a free, build-first course. Start here →
PaaS (Platform as a Service) in Azure means you deploy your code or your data and Microsoft runs the servers, operating system, patching, and scaling underneath. App Service, Azure SQL Database, Functions, and Container Apps are the headline examples. You get a platform to build on; you never log into the box or install a security update.
That last sentence is the whole test. If you never sign into the underlying server and never apply an OS patch, you are using PaaS. If you do — if there is a machine you SSH into, a kernel you own, updates you schedule — you are on IaaS, which in Azure usually means a virtual machine. Everything below flows from that one line.
The three layers, without the pizza metaphor
The cloud gets sliced into three service models by how much of the stack the provider runs for you. From most-you-manage to least:
- IaaS — Infrastructure as a Service. Azure gives you a virtual machine, a network, a disk. You own the OS, the runtime, the patching, the scaling. Maximum control, maximum chores.
- PaaS — Platform as a Service. Azure runs everything up to the runtime. You bring the application code or the database schema and nothing below it. Less control, far fewer chores.
- SaaS — Software as a Service. A finished product you log into. Microsoft 365, GitHub, Dynamics. You build nothing; you just use it.
PaaS is the middle seat, and it is where most modern application work lives. We cover the full split in Class Four — IaaS, PaaS, and SaaS; this note goes deeper on the middle one specifically, because that is where the day-to-day decisions get made.
PaaS is a trade: you give up control of the machine to get rid of the machine.
The headline Azure PaaS services, grouped by what they host
PaaS is not one product. It is a category, and the fastest way to hold it in your head is by what each service is built to run. Here is the working set, the ones that come up on real projects and in real interviews.
| What you're hosting | Azure service | Use it when |
|---|---|---|
| Web apps & APIs | Azure App Service | You have a standard web app or REST API in .NET, Node, Python, Java, or PHP and want it deployed, patched, and auto-scaled without touching a server. |
| Azure Functions | Your code runs in short bursts on a trigger — an HTTP call, a queue message, a schedule — and you want to pay only for the runs, not for idle time. | |
| Azure Static Web Apps | You have a front-end build (React, Vue, plain HTML) plus a light API, and want global hosting with CI/CD from your repo baked in. | |
| Containers | Azure Container Apps | You containerized your app but do not want to run and patch a Kubernetes cluster. Scale-to-zero, built-in ingress, no control plane to babysit. |
| Azure Container Instances | You need a single container running fast for a job or a burst, with no orchestration at all. | |
| Databases | Azure SQL Database | You want a managed SQL Server engine — backups, patching, and high availability handled — while you keep the schema, queries, and tuning. |
| Azure Cosmos DB | You need a globally distributed NoSQL store with low-latency reads and writes and elastic scale, without running database servers. | |
| Messaging & events | Azure Service Bus | Your services need reliable, ordered queues and topics to talk to each other without being online at the same moment. |
| Azure Event Hubs | You are ingesting a firehose — telemetry, clickstreams, logs — at millions of events and need a managed pipe to catch it. | |
| Caching | Azure Cache for Redis | You want a managed in-memory cache in front of a slower database, without running Redis nodes yourself. |
Notice the pattern in the right-hand column. Every "use it when" is really the same sentence in different clothes: the workload fits a common shape, and I would rather ship than operate. That shape-fit is the real decision, and it is the part the definition articles skip.
People argue about whether Azure Blob Storage is PaaS. It is a managed service you consume through an API and never patch, so it behaves like PaaS in every way that matters to you. Microsoft files storage under its own bucket, but for the "who runs the server" test, storage passes. We treat it in Class Twelve — Storage Accounts.
The decision that actually matters: PaaS or a VM
This is the part a hiring manager listens for, and it is where most study material goes quiet. Knowing that App Service is PaaS is a flashcard. Knowing when to put your app on App Service instead of a VM is the job.
The honest framing is a trade between control and operational burden. A VM hands you everything — the OS, the ports, the disk, root access — and in exchange hands you the chores: patching, hardening, monitoring the machine, scaling it, replacing it when it dies. PaaS takes those chores away and, in the same motion, takes away the control. You cannot install an arbitrary kernel module on App Service. You cannot pick the exact OS build. You live inside the platform's shape.
So the question is never "which is better." It is "how much of that control do I need for this workload?" Most of the time the answer is: less than you think.
| Reach for PaaS when… | Reach for a VM (IaaS) when… |
|---|---|
| Your app is a standard web app, API, function, or managed database. | You need a specific OS version, kernel access, or low-level networking. |
| You want patching, scaling, and high availability handled for you. | You run legacy or licensed software that must be installed on the host. |
| Your team is small and time on undifferentiated ops is time lost. | You are lifting-and-shifting an existing server as-is, no rewrite. |
| You want to scale to zero or scale out on demand automatically. | A compliance or vendor requirement forces full control of the machine. |
A useful default: start on PaaS, and let a real constraint push you down to a VM. Do not start on a VM because it feels safer or more "real." A VM feels like control until the first CVE lands and the patch is now your Saturday. Every server you run is a server you own the security of, forever. PaaS is Microsoft agreeing to own most of that for you. That is not a small favor — the shared-responsibility line moves in your direction the moment you leave the VM behind.
What PaaS does not do for you
The convenient half of the pitch is loud; the honest half is quieter. PaaS runs the platform. It does not make the decisions.
- You still own the app. Azure patches the OS under App Service. It does not fix your bug, your slow query, or your leaked secret. The code is yours.
- You still own the data. Azure SQL Database keeps the engine alive and backed up. The schema design, the indexing, the query that does a full table scan at 9 a.m. — still you.
- You still own the config. PaaS has a hundred knobs — the App Service plan tier you pick, the scaling rules, the networking, the identity. Choosing them wrong costs money or opens a hole. Managed does not mean decided.
- You still own the bill. Auto-scale is convenient right up until it scales and you did not set a ceiling. Managed platforms make it easy to spend without noticing.
This is the CAMPUX line in one sentence: PaaS removes the toil, not the judgment. The engineer who understands what the platform is doing on their behalf — and what it is quietly leaving on their desk — is the one who gets trusted with the production account.
Do you patch the OS? If no, it's PaaS. Do you never see a server at all, just a finished app you log into? That's SaaS. Do you own the whole machine? That's IaaS. Keep that ladder in your head and every Azure service sorts itself in about three seconds.
Common questions
Is Azure App Service PaaS or IaaS?
App Service is PaaS. You deploy a web app or API and Azure runs the operating system, the web server, patching, and scaling for you. You never sign into the underlying VM — you do not manage one. That is the defining line: if you never patch the OS, it is PaaS.
Is Azure SQL Database PaaS or SaaS?
Azure SQL Database is PaaS. Microsoft runs the database engine, backups, patching, and high availability, but you still own the schema, the queries, the data, and the tuning. SaaS would be a finished application you just log into, like Microsoft 365 — you build nothing.
When should I use PaaS instead of a virtual machine?
Use PaaS when your workload fits the platform's shape — a standard web app, an API, a managed database, an event-driven function — and you would rather ship features than patch servers. Reach for a VM when you need a specific OS, kernel-level software, legacy dependencies, or control the platform will not give you. The question is not which is better; it is how much control you need.
What are the main examples of PaaS in Azure?
The headline PaaS services are Azure App Service for web apps and APIs, Azure Functions for event-driven code, Azure Container Apps for containers without a cluster, and Azure SQL Database and Cosmos DB for managed data. Service Bus, Event Hubs, and Azure Cache for Redis round out the messaging and caching side.