Where does serverless (e.g. AWS Lambda) actually fit on the IaaS/PaaS/SaaS spectrum — does it fit cleanly into any of those three categories at all?

Serverless compute doesn't fit cleanly into any single bucket — it's most often described as an extreme point on the PaaS end of the spectrum, since you deploy code and the provider manages everything below it (OS, runtime, scaling, and now even server provisioning itself), but it differs from traditional PaaS enough in billing model and execution model that many practitioners treat "Serverless" (or "FaaS," Function as a Service) as its own category layered on top of the IaaS/PaaS/SaaS framework rather than a fourth rung on the same ladder.

The IaaS/PaaS/SaaS framework is fundamentally about "how much of the stack does the provider manage," and serverless pushes that further than traditional PaaS in a specific way: with PaaS (say, a traditional app-hosting platform), you still think about "an instance of my application is running," even if you never touch the underlying OS — there's a persistent, addressable unit of compute you're reasoning about, even if it autoscales. With serverless/FaaS, that unit disappears entirely from your mental model: you deploy a function, and the provider handles not just the OS and runtime but the entire question of "is anything even running right now" — your code executes in response to an event, on infrastructure that's provisioned and torn down per-invocation (with some execution-environment reuse for performance), and you're billed per invocation and execution time rather than for a running instance that exists whether or not it's doing anything.

This difference matters enough in practice that it changes real architectural decisions in ways plain PaaS doesn't: cold starts become a real design consideration (there's no "always-on instance" to eliminate first-request latency by default), execution time limits shape what workloads are even viable (long-running processes don't fit the model), and the billing model changes the cost profile from steady baseline cost to usage-proportional cost, which is a genuinely different trade-off than PaaS's "provider manages runtime, but you still have persistent instances" model.

The practical answer for a spectrum diagram or interview whiteboard: serverless sits at (or past) the PaaS end for "how much operational responsibility is on you," but it's worth naming explicitly as its own point rather than squeezing it into the PaaS label, because the execution and billing model differences drive real architectural consequences that "PaaS" alone doesn't capture.

• Serverless goes further than traditional PaaS by removing even the concept of a persistent, addressable running instance from your mental model.
• It's usually placed at the extreme PaaS end of the IaaS/PaaS/SaaS spectrum, but is different enough in execution and billing model to be worth naming as its own category.
• Per-invocation billing and execution-environment lifecycle (including cold starts) are the practical consequences that make serverless a distinct architectural choice, not just "PaaS with a different name."
• The spectrum framework is a useful mental model, not a strict taxonomy — real services (serverless included) can straddle categories.

• AWS: What is serverless computing?
• AWS: AWS Lambda documentation
• Google Cloud: Serverless computing