---
{
  "title": "IaaS, PaaS, and SaaS",
  "summary": "Compare IaaS, PaaS, and SaaS through concrete maintenance, identity, application, and data responsibilities rather than treating the labels as complete contracts.",
  "topic": "networking",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    5
  ],
  "aliases": [],
  "sources": [
    {
      "title": "AWS: Shared Responsibility Model",
      "url": "https://aws.amazon.com/compliance/shared-responsibility-model/"
    },
    {
      "title": "NIST: Definition of Cloud Computing",
      "url": "https://csrc.nist.gov/pubs/sp/800/145/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

Infrastructure as a Service exposes resources such as virtual machines, storage, and networks. Platform as a Service manages more of the runtime and platform. Software as a Service provides a complete application. These labels are learning aids, not precise substitutes for service documentation. Security ownership changes with the service: customers may manage operating systems in IaaS, while SaaS shifts much infrastructure work to the provider but leaves identity and data decisions with the customer.

## In practice

A team patches the guest operating system on a virtual machine. For a hosted document application, it instead focuses on account permissions and sharing policy.

## A common misunderstanding

SaaS does not mean the customer has nothing to secure.

## Check your understanding

Why examine the exact service documentation?

**Think it through:** Responsibilities vary within each model and can depend on optional features and customer configuration.

## Compare the same application at three layers

Imagine a fictional academy runs a timetable application. With an infrastructure service, the team might manage a guest operating system and application stack. With a managed application platform, more runtime operation moves to the provider. With a complete hosted timetable product, the team mainly configures the application and its use.

These are learning examples, not universal promises. Individual products can expose optional components or responsibilities that do not fit a simple three-row chart. Read the exact service documentation before assigning an operational task.

## Ask who can make each change

For the timetable, identify who patches the relevant software, replaces credentials, configures access, and restores data. “The provider handles security” leaves the most important customer decisions unclear.

A SaaS customer may not patch the provider's operating system but can still expose a private timetable through incorrect sharing. An IaaS customer may configure a strong firewall while leaving its guest application unmaintained. Different layers create different tasks without making one label automatically safe.

## Evaluate integration as well as the product

Suppose the hosted timetable connects to the academy's identity provider and exports records to another system. Those integrations introduce service identities, tokens, data movement, and lifecycle dependencies beyond the main application's interface.

Document who owns them and how permissions are removed when an integration is retired. A managed product cannot automatically know every business decision about the academy's data.

For a paper exercise, create a responsibility table for the three illustrative arrangements. Use operating-system maintenance, application updates, identity policy, data classification, and recovery as rows. Mark uncertain boundaries for documentation review rather than guessing. Then explain one configuration mistake possible in each arrangement. The goal is comparing the work left with the customer, including integrations and evidence, instead of ranking service models as secure or insecure by name.

## Keep exploring

- [[cloud-shared-responsibility]]
- [[cloud-computing]]
- [[cloud-identity]]