Service Models: IaaS, PaaS, SaaS

Who manages what

Every IT service is built from the same stack of layers: a building with power, cooling and network; servers and storage; a virtualization layer; an operating system; a runtime (such as Python, Java or .NET) with middleware; the application; and at the top, the data and the people who have access to it. With your own servers on-premises, you manage every layer. The cloud service models differ only in where the line falls between what the provider manages and what you manage.

A popular analogy is "pizza as a service": make pizza at home (on-premises), buy a frozen pizza and bake it yourself (IaaS), order delivery (PaaS) or eat at a restaurant (SaaS). In each step you hand over more work and more choices. Like every analogy, it breaks down if pushed too far; the stack below is the precise version.

Infrastructure as a service (IaaS)

Infrastructure as a service (IaaS) rents you the basic building blocks: virtual machines, disks, storage and virtual networks. The provider runs the data centers, the hardware and the hypervisor; you choose and manage the operating system, patch it, install the software, configure the firewall rules and manage everything above.

• Examples: Amazon Elastic Compute Cloud (EC2) from Amazon Web Services (AWS), Azure Virtual Machines, Google Compute Engine, and the matching block storage and virtual network services.
• Good for: moving existing servers to the cloud with few changes ("lift and shift"), software that needs a specific operating system or configuration, and full control.
• Trade-off: the most control, and the most work. A cloud virtual machine (VM) needs the same updates, backups and hardening as a physical server. See Compute in the Cloud.

Platform as a service (PaaS)

Platform as a service (PaaS) gives you a ready platform to run your own application on. You upload code (or a container) and configure it; the provider manages the servers, operating system, runtime, patching and usually scaling. You no longer log in to a server, because from your point of view there is none.

• Examples: Azure App Service, AWS Elastic Beanstalk, Google App Engine. Managed databases such as Amazon Relational Database Service (RDS), Azure SQL Database and Cloud SQL are usually counted as PaaS too: you get a database, not a server (see Managed Databases).
• Good for: developers who want to spend their time on the application rather than on servers.
• Trade-off: less control over versions and configuration, platform limits, and more dependence on one provider's way of working.

Software as a service (SaaS)

Software as a service (SaaS) is a complete application that the provider runs and you use, usually through a web browser or an app, typically paid per user per month. You manage only your data, your users and the application's settings.

• Everyday examples: Microsoft 365 (Exchange Online, SharePoint, Teams), Gmail and Google Workspace, Salesforce, Zoom, Dropbox.
• Good for: standard business functions such as email, office documents, customer relationship management and payroll, where building or hosting your own adds no value.
• Trade-off: the least work and the least control. The provider decides on features, changes and the timing of updates, and moving your data elsewhere can be hard.

Functions as a service (FaaS)

Functions as a service (FaaS), also called function as a service, is often treated as a fourth model, between PaaS and SaaS. You write individual functions, small pieces of code that run in response to an event (an HTTP request, a file upload, a message, a timer), and the provider runs them only when triggered, scales them automatically and bills per call and per amount of execution time. Examples are AWS Lambda, Azure Functions and Google Cloud Run functions (formerly Cloud Functions). FaaS is the best-known form of serverless computing; see Serverless.

The names multiply beyond these four (database as a service, desktop as a service, and "everything as a service", XaaS), but they all answer the same question: which layers does the provider manage?

The shared responsibility model

Security and operations in the cloud are a shared job. The shared responsibility model divides the work between provider and customer, and the division depends on the service model. The table follows the way Microsoft and AWS present it in their documentation.

The last three rows are the important ones: no service model moves them to the provider. The provider cannot know whether a download of all your customer records is legitimate, whether a former employee's account should still exist, or whether a storage bucket was meant to be public. Most cloud data leaks start in the customer's half: a weak password without multi-factor authentication, a too-broad permission, a storage bucket opened to the internet. See Identity and Access Management and Cloud Security and Compliance.

Choosing a model

The choice is a trade between control and convenience. The further right you go in the stack, the less you can tune, and the less you have to run, patch and staff. A useful default is to pick the most managed model that still meets your requirements, and move down only for a concrete reason: a specific operating system, a legacy application, a compliance rule or a cost advantage.

Most organizations use all models at once: SaaS for email and office work, PaaS or FaaS for their own new applications, and IaaS for the systems that need it. Where these services run (public, private or hybrid) is a separate choice; see Deployment Models.

"The SaaS provider backs up my data"

Replication copies a deletion, an overwrite or a ransomware encryption to every copy within seconds. Deleted items typically go to a recycle bin or retention area for a limited time, weeks to a few months depending on the service and its settings, and are then gone for good. Deleting a departed employee's account can delete their mailbox and files with it. The provider's service agreement usually states that you are responsible for your own data, and some providers explicitly recommend a backup.

So treat critical SaaS data like any other data: decide on recovery point and recovery time objectives, check which retention the service really offers, and where that is not enough, add a separate backup, often a third-party service that copies the data out of the SaaS application. See Backup and Recovery for why sync is not backup and for the 3-2-1 rule.