Cloud service models

IaaS, CaaS, PaaS, FaaS and SaaS: how much of the stack you hand to a provider, from renting bare virtual machines to just using someone else’s application.

How it works

Every application sits on the same stack of layers: a data center with servers, storage and network; a virtualization layer that splits servers into virtual machines; an operating system; a runtime and middleware (language version, libraries, web server); the application code; and its data. A service model says where the line falls between the layers the provider runs and the layers you run. With infrastructure as a service (IaaS) you rent virtual machines, storage and networks and run everything from the operating system up: NIST’s definition gives the consumer control over “operating systems, storage, and deployed applications”. Containers as a service (CaaS) moves the line up a step: you hand over container images, and the provider runs the hosts and clusters they land on, as AWS Fargate does. Platform as a service (PaaS) takes the runtime too: you deploy code built with “programming languages, libraries, services, and tools supported by the provider”, and the provider runs the network, servers, operating systems and storage. Functions as a service (FaaS) shrinks the unit to a single function that runs when an event arrives, and the platform scales it per request. Software as a service (SaaS) hands over the application itself: you use the provider’s application and change only “limited user-specific application configuration settings”. Whatever the model, your data, your users and who may access what stay yours. That split is the shared responsibility model, which AWS sums up as security “of” the cloud (the provider) versus security “in” the cloud (you).

Think of it as

Getting dinner. On premises you own the kitchen, buy the food and cook. IaaS is renting a fully equipped kitchen: the building, power and stove belong to someone else, but you shop, cook and clean. PaaS is a meal kit delivered to that kitchen: you still cook, but the ingredients arrive prepared. FaaS is ordering one dish at a time and paying per plate. SaaS is a restaurant: you pick from the menu and can ask for no onions, but you never touch the stove. In every case, what you eat and who sits at your table is still your call.

Reach for it when

Choosing where to run a workload: each step up removes work you would otherwise do, such as patching the guest operating system on EC2 or rebuilding runtimes, so pick the highest model whose limits the workload can live with
Moving an existing server as it is, with its operating system and configuration: Google suggests IaaS for lift-and-shift migrations
Reviewing security or compliance: AWS, Microsoft and Google all tie the customer’s share of the controls to the service model, so map each service you use to one
Comparing offers across clouds that use different product names for the same kind of service

Think twice when

Treating the labels as exact: providers file similar services differently. Google lists GKE under PaaS and Microsoft lists Azure Functions under PaaS, and CaaS and FaaS aren’t in NIST’s definition at all
Assuming a higher model makes security the provider’s job: in every model you keep your data, identities and access policies, and in IaaS the guest operating system and firewall rules are yours too
Expecting the same control you have on a VM from a platform that removed it: PaaS and FaaS run only the languages and runtimes the provider supports, and SaaS lets you change settings, not code

A real example

A team runs a small web API and looks at what each model would leave on its plate. On EC2 (IaaS) it owns the guest operating system, including updates and security patches, plus the security group rules. On Fargate (CaaS) AWS secures the instances and runtime under the containers, and the team rebuilds its image when the base image gets a fix. On Elastic Beanstalk (PaaS) it uploads code, and the service provisions the instances, load balancing, health monitoring and scaling. On Lambda (FaaS) with the Auto runtime update mode, Lambda applies runtime patches to the function itself. For the help desk it buys instead of builds (SaaS), the team only configures single sign-on, roles and settings. Across all five, deciding who can read the data and keeping it classified and encrypted stays with the team.

More on cloud service models

Narrower ideas that build on this one.

What each provider calls it

AWS: IaaS: Amazon EC2. CaaS: Amazon ECS and EKS on AWS Fargate. PaaS: AWS Elastic Beanstalk. FaaS: AWS Lambda. SaaS: products sold through AWS Marketplace
Google Cloud: IaaS: Compute Engine. CaaS: Cloud Run (Google files GKE under PaaS). PaaS: App Engine. FaaS: Cloud Run functions. SaaS: Google Workspace and SaaS products in Cloud Marketplace
Azure: IaaS: Azure Virtual Machines. CaaS: Azure Container Apps. PaaS: Azure App Service. FaaS: Azure Functions. SaaS: Microsoft 365, Dynamics 365
Open source & others: IaaS: OpenStack. CaaS: Kubernetes with Knative Serving. PaaS: Cloud Foundry, Dokku. FaaS: OpenFaaS, Knative Functions

Who runs which layer#

Read each column from the top. “You” means your team configures, patches and monitors it; “Provider” means the cloud does; “Shared” means both have a part. The line moves up one layer or so with each model.

Layer	On-premises	IaaS	CaaS	PaaS	FaaS	SaaS
Data, users and access policies	You	You	You	You	You	You
Application code	You	You	You	You	You	Provider (you change settings)
Network controls (firewall rules, segmentation)	You	You	You	Shared	Shared	Provider
Runtime and middleware (language version, libraries)	You	You	You (inside your image)	Provider	Provider	Provider
Operating system	You	You (guest OS)	Shared (provider: hosts; you: image base)	Provider	Provider	Provider
Capacity and scaling	You	You	Shared	Shared	Provider	Provider
Virtualization (hypervisor)	You	Provider	Provider	Provider	Provider	Provider
Servers, storage, network hardware, data center	You	Provider	Provider	Provider	Provider	Provider

IaaS, PaaS and SaaS columns follow NIST SP 800-145 and Microsoft’s responsibility matrix, which marks customer data, identities and configuration as the customer’s in every model, network controls as shared in PaaS and Microsoft’s in SaaS, and the operating system as Microsoft’s in PaaS and SaaS.
CaaS follows AWS’s Fargate docs (no servers or clusters to provision, scale or pack) and the EKS best practices guide (with Fargate, AWS secures the instance and runtime under your pods). FaaS follows Lambda’s runtime management page: Lambda patches managed runtimes, but with container images you rebuild from the latest base image yourself.
Capacity and scaling: Fargate removes choosing server types and deciding when to scale clusters;Elastic Beanstalk scales the environment you configure; Lambda manages compute resources for you. Network controls in CaaS: the EKS guide leaves network security largely to the customer.
Cloud Foundry’s own overview draws the same stack for traditional IT, IaaS and PaaS: in PaaS the provider manages everything except applications and data.

Five models, one line moving up#

Each model has its own page in this section or nearby. The products named are examples, not a complete list.

Infrastructure as a service (IaaS)

you start at the OS

You provision “processing, storage, networks, and other fundamental computing resources” and run any software on them, operating systems included (NIST). In practice that means virtual machines, covered on the Virtual machines page: EC2, Compute Engine, Azure Virtual Machines, or OpenStack in your own data center.

Containers as a service (CaaS)

you start at the image

You upload, start, stop and scale containers without managing the hosts under them. TechTarget places it between IaaS and PaaS, usually as a subset of IaaS, because the unit is a container rather than a VM. See Containers and Container orchestration: ECS or EKS on Fargate, Cloud Run, Azure Container Apps.

Platform as a service (PaaS)

you start at the code

You deploy an application written with languages and tools the provider supports; you don’t manage the network, servers, operating systems or storage, but you control the app and possibly the hosting environment’s settings (NIST). See Platform as a service: Elastic Beanstalk, App Engine, Azure App Service, Cloud Foundry, Dokku.

Functions as a service (FaaS)

you start at a function

You upload a function that runs in response to an event; the platform starts it, scales it and bills for requests and compute time. Google says FaaS has a shared responsibility list similar to SaaS. See Serverless functions (FaaS): Lambda, Cloud Run functions, Azure Functions, OpenFaaS.

Software as a service (SaaS)

you start at the settings

You use the provider’s application through a browser or an API and control only limited configuration (NIST). Building one is mostly about multi-tenancy: many customers on one system without seeing each other. See Software as a service.

The labels blur#

NIST calls its service models “a simple taxonomy that is not intended to prescribe or constrain any particular method of deployment”, and real products cross the lines. Cloud Run runs “your code, function, or container”, so it is CaaS, PaaS or FaaS depending on what you hand it, and Cloud Run functions are now deployed as services on Cloud Run. Elastic Beanstalk, a classic PaaS, provisions EC2 instances in its Standard mode or runs on EKS clusters in its Cluster mode.

The providers’ own lists disagree too. Google files GKE, a managed Kubernetes service, under PaaS next to App Engine and BigQuery; Microsoft files Azure Functions, Azure SQL Database and Azure Storage under PaaS. So for any one service, ask the question the table asks (which layers do I still patch, scale and secure?) rather than trusting the acronym.

Often confused with

Virtual machines Containers Container orchestration Serverless functions (FaaS)Platform as a service (PaaS)Software as a service (SaaS)Serverless architecture

Where it came from1961–2014

Renting computing as a service is an old idea. At MIT’s centennial in 1961, John McCarthy predicted that “computing may someday be organized as a public utility just as the telephone system is”, and in the following decades IBM and other mainframe makers sold time-sharing to banks and large firms. In the late 1990s application service providers hosted software for customers, and on February 7, 2000, salesforce.com launched its hosted CRM at an event themed “The End of Software”.

The cloud as we know it arrived in layers. In August 2006 Amazon put EC2 into beta: “resizable compute capacity in the cloud” that booted servers in minutes, gave “complete control” of them, and charged only for capacity used. In April 2008 Google previewed App Engine, which ran web applications on Google’s infrastructure and “takes care of the infrastructure stack”, so developers wrote code and Google handled scaling. One rented machines; the other rented a platform.

With every vendor using “cloud” differently, NIST’s Peter Mell and Timothy Grance published SP 800-145 in September 2011: five essential characteristics, three service models (SaaS, PaaS, IaaS) and four deployment models, meant as “a means for broad comparisons”. Each model is defined by what the consumer does and doesn’t control, which is why the provider security pages map onto it. Newer layers have been added informally since: AWS Lambda, previewed in November 2014, ran code in response to events and billed per 100 ms, and container services filled the gap between VMs and platforms.

Why it’s built this way

Define each model by what the consumer controls, not by the technology: NIST wanted a baseline for comparing services and deployment strategies that would not “prescribe or constrain” how anyone builds them, so each definition lists what the consumer does “not manage or control”.
Rent whole virtual servers first: EC2 aimed to make “web-scale computing easier for developers” by giving them complete control of resizable capacity, booted in minutes and paid for by use, rather than a new programming model.
Hide the infrastructure behind a fixed platform: App Engine’s goal was to make a web app easy to start and then easy to scale to millions of users, so it bundled storage on Bigtable and GFS with automatic scaling and load balancing, within set quotas.
Bill for requests and compute time instead of servers: Lambda managed the compute resources itself and charged only for requests served and compute time, metered in 100 ms increments, so a function could scale from a few requests a day to thousands per second.

Timeline

1961
John McCarthy suggests computing could become a public utility
2000
salesforce.com launches hosted CRM with “The End of Software”
2006
Amazon EC2 enters beta: virtual servers by the hour (IaaS)
2008
Google App Engine preview: apps on Google’s infrastructure (PaaS)
2011
NIST SP 800-145 defines SaaS, PaaS and IaaS
2014
AWS Lambda preview: code that runs on events (FaaS)

Sources19

Improve this page on GitHub