Cloud Service Models

Definition: A taxonomy of cloud computing service delivery models, categorized by how much of the infrastructure and software stack — hardware, virtualization, OS, runtime, and application — is managed by the cloud provider versus the customer. The three classic tiers, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), were formalized by NIST in 2011 (Special Publication 800-145), though the underlying practices predate the term: Salesforce is commonly credited with pioneering SaaS in 1999, and Amazon’s 2006 launch of EC2 is generally seen as the moment IaaS became a mainstream commercial product. A fourth model, Function as a Service (FaaS) / serverless, emerged later as a further abstraction beyond PaaS, removing even the notion of a long-running server process the customer thinks about.

How It Works

IaaS (Infrastructure as a Service): provider manages physical servers, networking, and the hypervisor; user manages the OS, runtime, and application (AWS EC2, GCP Compute Engine, Azure VMs) — see Virtual Machines (VMs). Maximum control, maximum operational responsibility.
PaaS (Platform as a Service): provider manages the OS, patching, runtime, and often the database; user manages only application code and configuration (Render, Railway, Heroku). Trades some control for dramatically less operational overhead.
SaaS (Software as a Service): provider manages the full application end-to-end; the user just consumes it (Google Workspace, Salesforce, Slack). No infrastructure management at all.
FaaS / Serverless: event-driven code execution with zero server management and no idle compute cost — you pay per invocation/duration, not per provisioned hour (AWS Lambda, Cloudflare Workers) — see Serverless Computing and Cold Starts.
Each layer up the stack (IaaS → PaaS → SaaS) trades control and customization for reduced operational burden; this is often visualized as a “pizza as a service” stack where the cloud provider takes over progressively more of the layers you’d otherwise run yourself (networking, OS, runtime, data, application).
The Shared Responsibility Model formalizes where the provider’s obligations end and the customer’s begin — in IaaS the customer is responsible for OS patching and application security; in SaaS the provider owns nearly everything except data and access configuration.
BaaS / MBaaS (Backend as a Service): a related, narrower model that bundles a managed backend — authentication, database, storage — behind an SDK for client apps to call directly (Firebase, Supabase), often layered on top of a provider’s own FaaS/PaaS underneath.

Why It Matters

Guides cost optimization, operational headcount needs, and shared security responsibility decisions — choosing the wrong layer means either paying for control you don’t need (running raw EC2 for a CRUD app) or hitting a wall on customization you do need (trying to force a SaaS tool to do something only custom infrastructure can).
Directly determines the failure modes a team is responsible for debugging: an IaaS outage might be your misconfigured auto-scaling; a SaaS outage is entirely the vendor’s problem to fix.
Talent and hiring needs follow the model — IaaS requires platform/SRE engineers fluent in networking, OS internals, and capacity planning, while SaaS needs none of that, just configuration and access owners.
Time-to-market usually improves the higher up the stack you go, since undifferentiated heavy lifting (patching, scaling, high availability) is already handled by the provider rather than built in-house.
Compliance and audit scope shrink as responsibility moves to the provider — a SOC 2 or ISO 27001 audit for a SaaS-heavy stack leans heavily on the vendors’ own certifications, while an IaaS-heavy stack puts far more of the audit surface on the customer’s own controls.

Under the Hood: The Boundary of the Shared Responsibility Model

The shared responsibility model is usually summarized as the provider securing “of the cloud” (physical data centers, hardware, the hypervisor, and the internal workings of managed services) while the customer secures “in the cloud” (everything they configure on top) — but where exactly that line sits moves with each service model, and the details matter more than the slogan. For IaaS (a raw EC2 instance), the line sits just below the guest OS: the provider guarantees physical security, hypervisor isolation, and network fabric integrity, while the customer is on the hook for OS patching, firewall/security-group configuration, IAM policy, and data encryption — an unpatched EC2 instance is a customer failure, not an AWS one. Move to PaaS (a managed database like RDS, or a platform like Elastic Beanstalk) and the line shifts upward: the provider now patches the OS and manages the runtime or database engine itself, so the customer’s remaining responsibility narrows to access control, data, and application-level configuration — an internet-exposed RDS instance with a weak master password is still entirely the customer’s failure, even though AWS patches the underlying database software for them. At SaaS (Google Workspace, Salesforce), responsibility narrows further still to essentially just identity and access configuration plus the data the customer puts into the system. This is precisely why the overwhelming majority of real-world cloud security incidents trace back to customer misconfiguration rather than provider failure: the customer’s slice of the model keeps shrinking as you move up the stack, but it never actually reaches zero.

Comparison: Well-Known IaaS vs PaaS vs SaaS Examples

	IaaS (e.g. AWS EC2)	PaaS (e.g. Render, Heroku)	SaaS (e.g. Salesforce, Slack)
Customer manages	OS, runtime, app code, data, scaling	app code, config, data	just data and settings, no code
Provider manages	physical hardware, hypervisor, network	+ OS, patching, runtime	everything, including the application itself
Time to first deploy	hours to days	minutes to hours	already running — just sign up
Customization ceiling	near-unlimited	limited to the platform’s supported stacks	limited to the app’s configuration/extension points
Typical buyer	platform/infrastructure teams	product teams without dedicated ops	any business user
Pricing model	per-second/hour of provisioned capacity	per instance/plan tier, often usage-tiered	per seat/user, usually monthly or annual

Common Pitfalls

Vendor lock-in when building heavily around proprietary cloud provider FaaS/PaaS features (e.g., deeply coupling to AWS Step Functions or Azure-specific bindings), making a future migration expensive.
Choosing PaaS/SaaS for cost savings early on without modeling how pricing scales — many PaaS platforms are cheaper than IaaS at low traffic but cross over to being far more expensive at high, sustained scale.
Underestimating the “undifferentiated heavy lifting” IaaS still leaves on your plate: OS patching, backup strategy, and scaling logic don’t happen automatically just because you’re “in the cloud.”
Assuming “SaaS means secure”: the shared responsibility model still leaves the customer on the hook for access control, MFA enforcement, and data classification even in pure SaaS.
Mixing models without a clear boundary — running some services on raw EC2 and others on Lambda within the same team multiplies the operational surface (two very different deployment, monitoring, and debugging playbooks) without a strong reason.
Assuming FaaS/PaaS pricing is always cheaper: at high, sustained, predictable load, reserved IaaS capacity is very often cheaper than pay-per-invocation serverless pricing.
Treating the shared responsibility model as fixed rather than per-service — a single cloud account routinely mixes IaaS, PaaS, and SaaS, so the “who patches what” answer has to be tracked service by service, not assumed once for the whole stack.

Code Example

# render.yaml — a PaaS deployment descriptor (Render)
# Contrast with an IaaS VM: no OS to choose, no patching, no server to size
services:
  - type: web
    name: api
    env: node
    plan: standard
    buildCommand: npm install && npm run build
    startCommand: npm start
    envVars:
      - key: NODE_ENV
        value: production
      - key: DATABASE_URL
        fromDatabase:
          name: api-db
          property: connectionString
    autoDeploy: true
databases:
  - name: api-db
    plan: standard

Best Practices

Match the model to the team’s actual operational capacity, not the model with the most control — control you don’t use is just overhead.
Model total cost of ownership across the full traffic range you expect, not just at current scale, since crossover points between models can be steep.
Treat the shared responsibility model as a checklist, not an assumption — explicitly document what the provider covers and what your team covers for every service in use.
Avoid mixing models per-service without a documented reason, since each additional model multiplies the monitoring, debugging, and on-call playbooks the team must maintain.
Revisit the choice periodically — a workload that started on PaaS for speed may outgrow it and justify the operational cost of moving to IaaS, or vice versa.

FAQ

Is Kubernetes IaaS or PaaS? It’s commonly described as sitting between the two — it runs on top of IaaS (VMs) but gives application teams a PaaS-like deployment experience (declarative deploys, scaling, service discovery); see Kubernetes (K8s).

Where does serverless (FaaS) fit relative to PaaS? FaaS is a further abstraction beyond PaaS — PaaS still has a long-running server process the platform manages, while FaaS removes even that concept, billing per invocation instead of per provisioned instance.

Does using SaaS eliminate the need for a security team? No — it shrinks the customer’s share of responsibility but never eliminates it; identity and access configuration, data handling, and third-party app integrations remain the customer’s job even in pure SaaS.

Can one company use all four models at once? Yes, and most do — a typical stack runs some workloads on raw IaaS (specialized compute), the main application on a PaaS, internal tools bought as SaaS, and event-driven glue code as FaaS, choosing per-workload rather than committing to a single model company-wide.

History

Salesforce is commonly credited with launching the first mainstream SaaS product in 1999, delivering CRM entirely through a browser instead of installed software.
Amazon Web Services launched EC2 in 2006, generally regarded as the moment on-demand IaaS became a mainstream commercial product rather than an internal-only capability.
Google App Engine (2008), and later Heroku, popularized PaaS by abstracting away server management for web application deployment.
NIST formalized the IaaS/PaaS/SaaS definitions in Special Publication 800-145 (2011), giving the industry a standard vocabulary; FaaS/serverless emerged as a distinct further category after AWS Lambda’s 2014 launch.
BaaS/MBaaS platforms (Parse in 2011, later Firebase and Supabase) popularized a mobile- and frontend-first variant of PaaS, bundling auth, database, and storage behind a client SDK rather than a server deployment target.

Example

A startup uses AWS Lambda (FaaS) to resize user image uploads automatically on S3 bucket events, paying only per invocation, while running its main web app on Render (PaaS) so the team never touches an OS patch — reserving raw EC2 (IaaS) only for a specialized GPU workload that needs full hardware control. As the company grows, its steadiest, highest-traffic service eventually gets pulled back down to reserved EC2 capacity, since the PaaS convenience premium stops being worth it once traffic is large and predictable enough to plan around.

Referenced by

Dig deeper

Spot an error in this note?