IaaS, PaaS, and SaaS cloud service models

Understand the shared-responsibility boundary

The provider operates the facilities, physical infrastructure, and the portions of the service named in its documentation and agreement. The customer remains responsible for how the service is selected, configured, accessed, monitored, and used within the customer's boundary. Responsibility can also be shared. A provider can make encryption available while the customer decides key ownership, access, rotation, and recovery. A managed database can apply platform patches while the customer controls schema changes, query behavior, data quality, and recovery validation. Do not copy a generic responsibility diagram into an architecture review. Build one for the selected service and workload. Write the boundary for failure, not for the steady state. In an incident, minutes go to finding the owner. A matrix that names the owner of detection, diagnosis, communication, and recovery for each layer turns that search into a page.

The three models at a glance

Application code: Customer; Customer; Provider. Runtime and middleware: Customer; Provider; Provider. Operating system and virtualization: Customer; Provider; Provider. Data, identity, and access: Customer; Customer; Shared, with customer accountability. Configuration and use: Customer; Customer; Customer. This table is a starting point. Every provider draws the boundary differently, and configuration choices move it. Use the provider's current responsibility documentation for the services actually selected.

Infrastructure as a service

Infrastructure as a service provides compute, storage, and networking resources. The provider operates the physical environment and virtualization layer. The customer usually retains substantial responsibility for operating systems, runtime, deployment, application code, identity configuration, data, monitoring, backup, recovery, and many network controls. IaaS can suit specialized requirements, legacy workloads, and migrations that need infrastructure control. It can also preserve operating work that a managed platform would remove. Include patching, image management, capacity, high availability, and incident response in the cost and staffing estimate. Typical IaaS questions include:

Who builds and patches the machine image?
Who configures host and network controls?
How is capacity added and removed?
Which team restores the instance and application data?
How are vulnerabilities, logs, and configuration drift reviewed?

Platform as a service

Platform as a service manages more of the runtime and infrastructure layer. The customer focuses on application code, service configuration, data, access, observability, and workload-specific reliability. PaaS can reduce platform work and speed release. It also introduces service constraints, quotas, supported runtimes, deployment behavior, scaling rules, provider-specific identity, and new failure modes. A managed runtime does not remove the need for load tests, error budgets, release controls, or dependency monitoring. Typical PaaS questions include:

Which runtime and version are supported?
What happens during scaling, maintenance, and regional failure?
Which quotas can stop a release or traffic increase?
How are secrets, service identities, and network paths configured?
What evidence is available for a failed request or deployment?

Software as a service

Software as a service provides a complete application. The provider operates the product and underlying platform. The customer still owns configuration, identity integration, access review, data handling, retention choices, process design, user support, and vendor governance. Buying SaaS does not transfer accountability for the organization's use of the service or data. The customer needs an owner for tenant configuration, privileged roles, integrations, data exports, offboarding, and business continuity. Typical SaaS questions include:

Who approves users and privileged roles?
Which data enters the service and where is it stored?
How are retention, deletion, export, and legal-hold needs met?
What happens when the provider or an integration is unavailable?
How can the organization leave the service and recover its data?

Place managed data and artificial intelligence services carefully

Managed databases, warehouses, streaming systems, model endpoints, and integration platforms often sit between traditional categories. The provider can operate the service control plane and core runtime while the customer owns data design, access, workload behavior, cost controls, and the operating outcome. For a managed warehouse, the provider may handle infrastructure and service updates. The customer still defines data models, ingestion quality, permissions, workload isolation, query performance, retention, and recovery tests. For a managed artificial intelligence (AI) endpoint, the provider may operate serving infrastructure. The customer still owns model selection, input controls, evaluation, prompt or feature versions, output handling, safety review, monitoring, and the workflow decision.

Walk through one workload

Consider a reporting workload: source extracts, a managed warehouse, a transformation schedule, and a dashboard tool. Draw the responsibility line for each component. The provider operates the warehouse engine and its underlying infrastructure. The customer owns schema design, ingestion correctness, identity and access grants, query cost controls, retention, and recovery tests. The dashboard vendor operates its service. The customer owns user provisioning, report definitions, and the decision to trust a number. Then test the seams. Who notices when an extract is late? Who restores a deleted schema, and how long does it take? Who approves a new service identity with broad read access? These handoff questions expose the real boundary faster than any diagram.

Build a responsibility matrix

Create one row for every operating responsibility and one column for the customer, provider, implementation partner, and other involved team. Assign one accountable owner. Mark shared work only when the handoff and evidence are clear. Cover at least: Add the artifact that proves each responsibility. Examples include a configuration export, access-review record, recovery-test result, dashboard, runbook, or support agreement.

Identity, privileged access, and access review
Network boundaries and service exposure
Data classification, encryption, and key ownership
Runtime, dependency, and version management
Application deployment and configuration
Data quality, retention, deletion, and lineage
Backup, restore, and disaster recovery
Availability, capacity, and performance
Monitoring, incident response, and support escalation
Vulnerability and configuration management
Cost allocation, budgets, quotas, and commitments
Compliance evidence and vendor review

Compare service models with workload evidence

Start with the workload's control and reliability needs. Document data sensitivity, latency, availability, scaling pattern, integration boundary, portability requirement, delivery deadline, and available operating skill. Estimate the complete operating cost. Include platform charges, network transfer, observability, security controls, support, engineering time, migration, training, and exit work. A lower infrastructure price can still produce a higher operating cost. Test important assumptions with a representative workload. Verify performance, scaling, quota behavior, identity, network access, logging, backup, restore, and failure handling. A feature checklist does not show how the service behaves under the workload.

Review portability and exit

Portability is not a binary property. Record which parts can move: application code, data, schema, configuration, identity mapping, observability, deployment process, and operating knowledge. Provider-specific services can be the right choice when their benefit exceeds the expected exit cost. Define the exit path before a critical system depends on the service. Include data export, format, transfer time, contract timing, key access, retained backups, and the team that can operate the replacement. Test the exit at small scale before it is needed. Export a sample dataset, restore it into the replacement target, and time the operation. An untested exit path also weakens the negotiating position at renewal.

Common failure modes

Backup assumed. The provider protects service availability. Customer-initiated restore, retention period, and point-in-time recovery remain customer configuration in many services.
Quota surprise. A default quota blocks a scaling event during the highest-traffic week.
Console drift. Manual changes bypass the reviewed configuration path.
Identity sprawl. Service accounts accumulate privileges nobody reviews.
Exit never tested. The export format exists on paper. Nobody has restored from it.

Keep the matrix current

Review responsibility after a service change, new integration, regional expansion, incident, ownership change, or contract renewal. Provider features and boundaries change. The customer configuration can drift even when the service model label stays the same. Use the matrix in incident reviews. If an action had no clear owner or evidence, update the design and runbook. Keep the matrix near the architecture diagram and the runbook, not in a procurement folder. The team that answers alerts at night should be able to read who owns each layer without opening a contract.

Use a selection checklist

BluePi's history spans cloud infrastructure, data platforms, and AI systems. Across these layers, the useful question remains the same: who operates each part, how is it measured, and what happens when it fails?

The service-specific responsibility boundary is documented.
Every important control has one accountable owner.
Shared responsibilities include a handoff and evidence artifact.
Reliability, recovery, and support paths are tested.
Identity, data, network, and key boundaries are explicit.
Cost includes operations, support, transfer, and exit work.
Portability requirements are tied to a realistic exit scenario.
The review date and service version are recorded.

Why the method still applies

The labels have moved. Managed data services, container platforms, and AI endpoints blurred the old service-model boundaries. The responsibility method has not: name each responsibility, assign one owner, and demand evidence for who holds it. That transfers to whatever model names come next.

Related BluePi work

Where to read next on the same subject.