Cloud Service Models Explained

In this chapter, we introduce the definition of service models according to NIST. The concept of a service model is central to planning a cloud adoption process. In 2011, NIST classified three service models for cloud resource management:

• Software as a Service (SaaS)
• Platform as a Service (PaaS)
• Infrastructure as a Service (IaaS)

Software as a Service (SaaS)

The consumer can use the provider’s applications running on a cloud infrastructure.

These applications are accessible from various client devices through a thin client interface, such as a web browser (e.g., web-based email) or an application program interface (API).

The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, storage, or even individual application functionalities, except for limited user-specific application settings.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastructure applications created or acquired using programming languages, libraries, services, and tools supported by the provider.

The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, or storage, but has control over the deployed applications and, possibly, configuration settings for the application hosting environment.

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to provision processing, storage, networking, and other fundamental computing resources where the consumer can deploy and run arbitrary software, which can include operating systems and applications.

The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications and, possibly, limited control of selected networking components (e.g., host firewalls).

Service Model Insights

Service models implicitly introduce a responsibility matrix dictated by contractual agreements specific to each model.

A comparative analysis of service models and the ISO/OSI stack helps clarify the impact of the service model on the cloud adoption journey.

• IaaS: The cloud provider typically ensures service availability up to layer 4 of the ISO/OSI stack (Transport layer).
• PaaS: The guaranteed level varies between layer 4 and layer 5, sometimes extending to layer 6.
• SaaS: Services are typically maintained at layer 6, and in specific cases where no user interaction occurs through a web or mobile application, it can reach layer 7.

The division of responsibility between the cloud provider and the consumer plays a crucial role in defining the service model.

Another key aspect to consider is scalability expectations in the cloud. Opting for an IaaS model does not necessarily take full advantage of the cloud’s scalability capabilities. In fact, scalability responsibility falls on the hosted content within the IaaS service, which may result in classical scalability limitations, potentially leading to higher operational costs rather than reduced expenses.

While it is relatively easy to classify cloud resources managed through IaaS models, this becomes more complex with PaaS and SaaS models.

Many complex cloud resources are delivered via hybrid service models, such as PaaS/IaaS or PaaS/SaaS.

For example:

• Recognizable SaaS solutions include Salesforce CRM, Microsoft 365, and Google Workspace, all of which offer complex suites of SaaS-based solutions.

Below, we provide a deeper insight into each service model.

IaaS

Classic IaaS services include basic network resources (firewalls, VPNs, etc.).

Virtual machines (VMs) not managed by the cloud provider also fall under IaaS. This is one of the most comparable cloud services to traditional IT system management, making it one of the most considered options in lightweight cloud adoption strategies.

The cloud provider guarantees hardware operation, including both physical and logical security.

The security responsibility is typically covered up to layer 4 of the ISO/OSI stack.

The consumer is responsible for configuring and managing the operating system and any additional application software installed on the VM.

A hybrid case between IaaS and PaaS is a VM with a managed operating system. Here, the provider manages OS updates and security patches autonomously but does not enforce version changes until official support ends. However, the provider does not assume responsibility for third-party applications installed by the consumer.

IaaS/PaaS and PaaS

PaaS is the first service model that truly defines cloud computing, though finding purely PaaS-classifiable resources can be challenging.

Many cloud resources use hybrid service models (IaaS/PaaS), including Kubernetes and Red Hat OpenShift.

Some databases are offered as PaaS services, where the consumer only defines:

• DDL (Data Definition Language): Schema structures, stored procedures, functions, and user permissions.
• DML (Data Manipulation Language): CRUD (Create, Read, Update, Delete) operations.

Notable PaaS database services include Azure Database and AWS Aurora.

Other pure PaaS services include Azure Functions and AWS Lambda.

In a pure PaaS model, the consumer relinquishes control over the cloud resource’s state, which is contractually managed by the provider. The responsibility matrix is clear: the consumer is only responsible for the functional and application layer.

SaaS

SaaS is one of the most widely adopted cloud service models in the public cloud.

Consider the early free webmail providers, available for more than two decades.

SaaS encompasses social media services and widely used B2C sales platforms, some of which are expanding into enterprise solutions (e.g., WhatsApp for Business).

The boundary between SaaS and PaaS is sometimes ambiguous, and even cloud providers themselves may struggle to classify services technically, often relying on marketing terminology instead.

Examples of Paid SaaS Services

Azure:

• Microsoft 365: A well-known SaaS application that allows users to access cloud-based productivity tools such as email, calendars, and document management.
• Microsoft Dynamics.
• Microsoft Business Central.
• Microsoft Teams.
• Microsoft Chat GPT: One of the most widespread AI-driven prompt services powered by OpenAI.
• Microsoft Copilot: A productivity acceleration service leveraging OpenAI technology.

AWS:

• AWS Elastic Beanstalk: A plug-and-play platform supporting multiple programming languages and environments.

Google Cloud Platform (GCP):

• Google Mail: One of the most widely used free and paid email services.
• Google Workspace: A suite of productivity tools used worldwide.
• Google Gemini: Emerging as an AI-integrated service within Google’s productivity offerings, with promising integration into BigQuery .
• BigQuery: Google’s serverless, multi-cloud data warehouse , offered as a SaaS solution. It integrates machine learning algorithms to provide real-time insights into business processes.

This classification helps organizations understand which service models best fit their operational and strategic needs when adopting cloud computing.

Ambiguity in Service Model Interpretation

In personal-use solutions, many cloud services function as pure SaaS, offering a fully managed experience with minimal user-specific customization.

However, in enterprise environments, these services evolve into hybrid models, providing organizations with extensive customization and control over service configurations.

While activating a solution like Microsoft 365 or Google Workspace may be simple, its enterprise-level deployment introduces significant complexity. Advanced setup demands strong networking and security expertise to ensure full-service functionality while maintaining corporate compliance.

Additionally, enterprise versions often offer API-based integrations, allowing deep customization and automation. As a result, responsibility for service management shifts from solely the provider to a shared responsibility model, where both the provider and the consumer play key roles in governance and maintenance.

Extending Cloud Service Models

---

In the initial chapters of this section, we introduced fundamental concepts regarding cloud service and distribution models.

IaaS, PaaS, and SaaS—delivered via public cloud providers—are the primary service models offered by major cloud vendors.

However, hybrid cloud and cloud-native solutions are evolving, creating new service opportunities.

For example, as a software provider, I may have shifted from installing my product on customers’ local machines to offering it as a web service, with only lightweight local applications mimicking the traditional desktop experience.

In parallel, we have defined the key roles in the cloud supply chain and the cloud consumption chain, introducing the responsibility matrix (RACI) as a simplified representation of service responsibility management.

The cloud is continuously evolving, introducing increasingly complex cloud resources designed to address specific consumer needs—sometimes creating new demands through marketing strategies.

For example, instead of offering my software as a web service, I might distribute it as a cloud marketplace product:

• The customer downloads my product, which is automatically deployed in their cloud environment.
• The software runs within their cloud but sends me usage analytics on how the customer interacts with my service.

Alternatively, I might offer a dedicated cloud ecosystem for each client, running on my own cloud infrastructure.

As these hybrid models emerge, cloud providers are launching more specialized solutions to prevent customer migration based on cost optimization alone.

At the center of this strategy is data.

If I offer a unique service that no competitor provides—even at an acceptable price—my customers will find it very difficult to switch to another provider.

To reinforce customer retention, public cloud providers are introducing hybrid PaaS/SaaS services that are native to their specific cloud platform and not easily replicable on other clouds.

Impact on IT Operations and Organizational Restructuring

We have already seen how cloud consumption structures introduce specialized roles, leading to a reorganization of IT operations.

Figure 30 attempts to illustrate how the cloud service market is adapting to this growing complexity.

In Figure the term “hyperscaler” is used to represent a primary public cloud provider.

Hyperscalers collaborate with telecommunications providers, ensuring the first level of service—data transport, which corresponds to the lower layers of the ISO/OSI model.

Above this, we find:

• The three primary cloud service models (IaaS, PaaS, SaaS).
• Infrastructure as Code (IaC), enabling automated cloud ecosystem lifecycle management.
• DevSecOps operations, which integrate with the Cloud Architecture COE and FinOps COE to mediate service deployment.

What If an Organization Has a Low Cloud Maturity Level?

Some enterprises may be unable to fully implement cloud-native operations, due to:

• Low cloud maturity
• Cultural gaps that cannot be easily addressed within the budget of a single business project

In these cases, cloud services allow organizations to outsource the creation and management of a dedicated cloud ecosystem tailored to a specific business project.

This is known as Business Process as a Service (BPaaS).

BPaaS allows businesses to adopt cloud services incrementally, while preparing for future cloud-native transformations.

Holistic Vision

Choosing among IaaS, PaaS, and SaaS is not a purely technical decision; it’s an orchestration of technology, organization, finance, risk, and portability. The “right” model is the one that best aligns these lenses for a specific business outcome—now and as it evolves.

The big picture

• Value speed vs. control: PaaS/SaaS accelerate delivery by abstracting infrastructure; IaaS maximizes control at the cost of more operational burden.
• Shared responsibility ≠ zero responsibility: As you move from IaaS → PaaS → SaaS, what you manage changes, but governance and data accountability remain yours.
• Data gravity rules: Application code can be portable; data creates inertia. Plan for data lifecycle, residency, and egress from day one.

Four lenses to decide

1. Architecture & Ops
   • IaaS: bespoke environments, full control over OS/network; demands solid IaC, GitOps, and runbooks.
   • PaaS: managed runtimes/databases, faster releases; design to provider SLOs/limits and use 12‑factor practices.
   • SaaS: consume capabilities (e.g., email, CRM, analytics) with minimal ops; integration and identity become first‑class work.

2. Organization & Roles
   • Define a RACI: who’s Accountable for uptime, security, backups, cost?
   • Create a Platform Team (even small) to offer “golden paths” and guardrails for IaaS/PaaS users.

3. Risk, Compliance & Security
   • Treat identity (IAM), encryption, logging, and backup/restore as non‑negotiable baselines across all models.
   • Map data classification to service choice (e.g., regulated data may require private networking, KMS ownership, or specific regions).

4. FinOps & Unit Economics
   • IaaS: variable costs + idle risk → rightsize, schedule, and autoscale.
   • PaaS: managed scaling; watch per‑request/GB‑second style pricing.
   • SaaS: per‑seat/per‑usage; model over 3–5 years and include egress/integration costs.

When to prefer each model (rule of thumb)

• SaaS for commodity capabilities (email, docs, ITSM, CRM, analytics UI). Demand: export formats, APIs, clear exit plan.
• PaaS for differentiated apps where speed matters (functions, containers, managed DBs). Demand: SLOs, scaling policy, quotas.
• IaaS for specialized workloads (legacy, low‑level tuning, strict isolation). Demand: automation (IaC), hardening, cost guards.

Guardrails that travel with you

• Policy‑as‑code (tagging, budgets, SCPs/OPA), secrets management, immutable builds, observability SLOs, DR patterns (RTO/RPO defined).
• Standardize on containers + IaC even when using PaaS, to keep future options open.

Reducing vendor lock‑in (pragmatically)

• Favor open interfaces (e.g., S3‑compatible storage, OpenAPI for services).
• Decouple domain logic from provider SDKs behind adapters.
• Keep data export pipelines and schema ownership internal.
• Track a short reversibility doc: what would it take to move in 90 days?

Decision checklist (copy/paste)

• Exit strategy (export formats, data volumes, notice periods)?
• Data class & residency? Encryption & key ownership?
• Required SLOs (latency, availability) and RTO/RPO?
• Who is Accountable for uptime, security, and cost?
• 12‑month run rate vs. 36‑month TCO (incl. egress & staff time)?
• What business KPI does this service impact?