09.02 · Foundations

Service Models

IaaS, PaaS, SaaS, FaaS — four ways to draw the line between what the provider runs and what you build on top.

The shared responsibility model told you who owns each layer. The service model tells you how high in the stack the provider's responsibility goes by default. Picking a service model is the single biggest decision you'll make in a cloud project — it determines how much you control, how much you have to operate, and how the cost curve looks at scale.

NIST SP 800-145 formally defines three service models: IaaS, PaaS, SaaS. The industry has since added a fourth that NIST didn't anticipate — FaaS, the serverless function model — which behaves like an extreme version of PaaS. All four show up in real architectures, and most enterprises run a mix.

Pizza-as-a-service · the classic framing
A standard way to explain the four models without touching cloud vocabulary.
On-Prem
Made at home
You buy the dough, sauce, cheese, oven, and electricity. You knead, top, bake, and clean. Everything is yours and works exactly the way you want — if you have the time, money, and skill.
IaaS
Take-and-bake
You buy a pre-made pizza from the grocery store. They handle ingredients and assembly; you provide the oven, the table, the drinks, and you watch the timer. Most control, most ongoing work.
PaaS
Pizza delivery
They bake the pizza and bring it to your door. You provide the table, drinks, and atmosphere. You decided what toppings you wanted; they handled everything that gets the pizza to that decision.
FaaS
Pizza by the slice
You walk into the shop and pay only for the slice you eat. No setup, no leftover, no commitment. The shop runs the whole operation; you just show up when hungry. Cheapest per-slice if you're not eating much.
SaaS
Dine at the restaurant
They make the pizza, set the table, pour your drink, clean up afterward. You choose what you want from a menu and pay for the experience. Least control, least operational burden.

The four models, in detail

Click each model to see what you control, what you give up, real provider examples, and where security responsibility sits by default.

SERVICE MODEL DETAIL · IaaS You rent the machine. They run the metal.

You control

    Provider runs

      Real-world examples

        Best for · Watch out for

          Cost model
          Per-hour VM
          Scaling
          Manual / ASG
          Cold start
          N/A
          Lock-in
          Low

          Where each model wins

          There is no universally "best" model. They sit on a spectrum from maximum control at the IaaS end to maximum convenience at the SaaS end. Pick the rightmost option that still gives you the control your problem actually needs.

          Where each model sits on the spectrum
          Highlighted cell shows which model wins on each axis. Lower-control models trade flexibility for operational simplicity.
          Maximum control
          IaaS
          PaaS
          FaaS
          SaaS
          Maximum convenience
          Lowest ops burden
          IaaS
          PaaS
          FaaS
          SaaS
          Highest ops burden
          Fastest to deploy
          IaaS
          PaaS
          FaaS
          SaaS
          Slowest to provision
          Cheapest at low scale
          IaaS
          PaaS
          FaaS
          SaaS
          Expensive at idle
          Cheapest at huge scale
          IaaS
          PaaS
          FaaS
          SaaS
          Per-seat tax never stops
          Least vendor lock-in
          IaaS
          PaaS
          FaaS
          SaaS
          Most vendor lock-in
          Most security surface
          IaaS
          PaaS
          FaaS
          SaaS
          Smallest you-own surface

          The security boundary

          Each service model draws the provider/customer security boundary at a different layer in the stack. The further "up" the model abstracts, the less surface area you operate — but the more you depend on the provider's security and the less visibility you have when something goes wrong.

          IaaS: you patch the OS, harden the runtime, configure the firewall, run the EDR. Most surface area, most control, most work. A bad bucket policy is on you; a bad hypervisor CVE is on the provider.
          PaaS: you write the app and configure the platform. The provider patches the runtime, the OS, and the host. You give up the ability to tune the runtime in exchange for never patching it again. A SQL injection in your code is still on you.
          FaaS: you write a single function. The provider runs everything — OS, runtime, scaling, network. You lose almost all operational surface and gain almost no operational visibility. When something breaks at the platform layer, your only recourse is the provider's status page.
          SaaS: you configure the application. The provider builds, runs, patches, and incident-responds the whole thing. Your security work shifts entirely to identity, access control, conditional access, integration scopes, and data classification. The "application" surface area is now their problem.

          When to pick what

          Three rough rules cover most real decisions:

          1. Pick the rightmost model that still gives you the control you need. If SaaS does the job, use SaaS. If you actually need to tune the JVM heap, that's a PaaS or IaaS conversation. Most "we need IaaS for control" arguments turn out, on inspection, to be PaaS workloads with extra ceremony.

          2. Match the cost curve to the load shape. Steady high load → IaaS with reserved instances is cheapest. Spiky low-baseline load → FaaS pays for itself by charging zero at idle. Predictable mid-load with a small team → PaaS gets you out of the patching business. A bunch of seats using a standard tool → SaaS is the right answer 99% of the time.

          3. Be honest about your team's operational capacity. IaaS requires an SRE or platform team. PaaS requires application engineers who understand the platform's quirks. FaaS requires people who can debug distributed event-driven systems. SaaS mostly requires administrators. None of these are free; they just shift where the headcount lives.

          The point

          Service models are about where the line of responsibility goes. IaaS gives you the most stack to control and the most stack to defend. SaaS gives you the smallest stack to operate and the smallest stack you can see into when things go wrong.

          Most cloud projects use two or three models simultaneously: an IaaS-hosted legacy system, a PaaS database, FaaS for the event-driven glue, and SaaS for everything that isn't differentiating. The skill is knowing which workload belongs in which model — not picking one and using it for everything.

          Default to the right. Use SaaS where you can, FaaS where you should, PaaS where you must, and IaaS where you have no choice.

          References

          Formatted in APA 7. Pattern: Author(s). (Year). Title (Identifier). Publisher. URL. Alphabetized by first author's last name.

          1. Amazon Web Services. (n.d.). Types of cloud computing. https://aws.amazon.com/types-of-cloud-computing/
          2. Barron, A. (2014, July 30). Pizza as a service [LinkedIn post]. LinkedIn. https://www.linkedin.com/pulse/20140730172610-3993265-pizza-as-a-service/
          3. Cloud Native Computing Foundation. (2022, April 29). CNCF serverless overview 2.0. https://www.cncf.io/blog/2022/04/29/cncf-serverless-overview-2.0/
          4. Google Cloud. (n.d.). What is IaaS? https://cloud.google.com/learn/what-is-iaas
          5. Mell, P., & Grance, T. (2011). The NIST definition of cloud computing (NIST Special Publication No. 800-145). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-145
          6. Microsoft. (n.d.). What is IaaS? Azure cloud computing dictionary. https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-iaas/