Cloud service models explained: IaaS, PaaS, SaaS, and serverless

Cloud computing services differ in what a cloud service provider delivers and which parts of the system your team still operates. Infrastructure as a service (IaaS) supplies computing resources. Platform as a service (PaaS) supplies an environment for deploying applications. Software as a service (SaaS) supplies a finished application. Serverless services let you use managed capabilities without provisioning individual servers.

The choice affects your daily work: who installs updates, responds to application failures, controls access, restores data, and checks the bill. Start with the control your workload needs, then decide which operational tasks a provider can take over.

Three formal cloud computing service models, plus serverless

The NIST definition of cloud computing specifies three service models: IaaS, PaaS, and SaaS. Modern comparisons often add serverless as a fourth practical category. It is useful to discuss alongside the other models, but it is not a fourth model in that NIST definition.

Serverless overlaps with platform services and covers more than functions. Function as a service (FaaS) is the event-driven execution of code within that broader category. A serverless database is not a function, and a managed application platform may offer serverless execution options.

These categories help explain the service boundary. They do not establish that one product is cheaper, safer, or more scalable than another. A product's actual controls, limits, and operating terms determine whether it fits the job.

What your cloud service provider manages

A simplified technology stack includes data centers, physical hardware, networking, data storage, resource abstraction, operating systems, runtimes, applications, and data. Users, permissions, and connected devices interact with several of those layers.

In a public cloud service, the cloud provider operates the physical infrastructure included in that service. Moving from infrastructure toward managed platforms and finished software usually transfers more software operation to the provider. It also reduces the low-level choices available to the customer.

The division is not a clean line through every responsibility. For example, a provider may maintain the storage system while you decide who can read an object. It may run a database engine while you design queries and decide how long records are retained.

Microsoft's shared-responsibility guidance distinguishes provider-operated layers from customer responsibilities across IaaS, PaaS, and SaaS. Data handling, user access, service configuration, and the security of devices used to connect still need owners. Buying a more managed service does not remove those decisions.

Infrastructure as a service (IaaS): more customer control

Infrastructure as a service provides computing resources such as virtual machines, storage volumes, and virtual networks. These infrastructure services supply the computing power and connections on which you build an application. You can build a software environment on those resources instead of purchasing and maintaining the physical equipment yourself.

On a typical self-managed virtual machine, the cloud provider operates the host and virtualization platform. Your team selects and maintains the guest operating system, installs dependencies, deploys applications, configures workload networking, and protects credentials and data. Monitoring the application and planning its recovery remain part of that work.

When it fits: an application needs system-level access, a specific operating environment, custom packages or drivers, or a self-managed database or model server. GPU workloads can also need direct control over frameworks and dependencies. Hivenet's guide to GPU virtual machines explores that use case.

What to check: access privileges, supported images, storage persistence, networking options, hardware availability, and what happens when an instance stops or is deleted. IaaS can expose shared or dedicated capacity. Neither dedicated physical hardware nor a particular isolation boundary follows automatically from the label.

The trade-off: you retain more control over the software stack and more work to keep it running. Moving a compatible application between virtual machines may be feasible, but networking, identity services, images, and data still need migration work. Portability should be tested rather than assumed.

Platform as a service (PaaS): a managed cloud platform

Platform as a service provides an environment for building, deploying, and running applications. The cloud provider manages more of the underlying infrastructure, operating system, runtime, middleware, and deployment machinery. Your team supplies application code or a supported package and configures how it runs.

Microsoft Azure App Service, for example, is a managed platform for web applications, mobile backends, and REST APIs. The supported runtime, operating system, deployment method, and service plan determine the options available to a particular application.

The customer still needs to maintain application code and dependencies it supplies, configure access, protect secrets, manage data, and monitor application behavior. Provider management of the operating environment does not establish that your code is secure or that its database queries will perform well.

When it fits: the team wants to deploy an application and the platform supports its runtime, dependencies, networking, and release process. Maintaining the underlying servers would add work without providing control the application needs.

What to check: supported language versions, runtime upgrade policy, persistent storage behavior, deployment and rollback options, scaling controls, private connectivity, logs, and export paths. A platform may scale under configured rules without allowing every application component to scale independently.

The trade-off: less server administration, with more dependence on the platform's supported features. If the application requires an unsupported system component, a custom kernel change, or unrestricted host access, a managed platform may be the wrong boundary.

Software as a service (SaaS): finished applications

Software as a service provides a finished application through a browser, client application, or API. Webmail, shared documents, accounting, project management, customer relationship management, and customer-support tools are common examples.

The cloud provider operates the application and its supporting infrastructure, including the updates covered by the service. Your organization manages how people use it: accounts, permissions, sharing, data, integrations, configuration, procurement, and acceptable use. Some SaaS products also require local client software, which needs maintenance on the devices where it runs.

When it fits: an existing product solves the business need, and building or operating a replacement would add little value. A team needing shared scheduling software usually needs reliable scheduling and access controls, rather than a choice of server operating system.

What to check: administrator roles, user removal, retention, version history, recovery controls, export formats, integration permissions, and the features included in the selected plan. Confirm what happens to data when an account or subscription ends.

The trade-off: quick access to an existing application, with limited control over its features, infrastructure, and upgrade schedule. Predictable subscription fees do not guarantee a predictable total bill if seats, storage, usage, or required add-ons change.

Do not treat SaaS data as automatically recoverable. A service may retain only certain versions or exclude particular data from recovery. The distinction between synchronization and backup is especially relevant to file applications.

Serverless computing and FaaS: managed execution

Serverless computing lets customers use a managed execution or service layer without provisioning and administering individual server instances. Physical servers still perform the work. Provisioning and scaling are handled through the service's controls and limits.

Function as a service runs functions in response to events, such as an HTTP request, a file upload, a message, or a schedule. An image-upload event might trigger code that creates a thumbnail and stores the result.

The customer supplies code, dependencies, permissions, event configuration, and application logic. It must also handle errors, monitor outcomes, and understand retry behavior. Repeated events can produce repeated work unless the application is designed to handle them safely.

Runtime maintenance is not identical for every packaging method. AWS Lambda's runtime documentation explains that customers remain responsible for updating their function code and dependencies. When deploying container images, customers must rebuild and redeploy images to incorporate relevant updates. Supported-runtime lifecycles also require attention.

When it fits: event processing, short backend tasks, scheduled automation, and irregular workloads that fit the service's execution and resource limits. Serverless can also support longer-lived applications through other service types, so assess the specific product rather than applying function limits to all serverless computing.

What to check: execution duration, memory, concurrency, supported runtimes, startup latency, networking, retry behavior, observability, and how state is stored. Cold starts and concurrency limits can affect response time. Scaling the function does not necessarily increase the capacity of a database it calls.

The trade-off: less instance management, with tighter dependence on runtime and event interfaces. Billing may include requests and execution time, but “serverless” does not promise zero idle cost. For example, Lambda pricing includes provisioned concurrency, which charges for configured capacity as well as execution under that mode.

Types of cloud computing services at a glance

• IaaS: you receive infrastructure. The provider operates the physical platform; you commonly operate the guest OS and application stack. It offers broad system control for custom environments and self-managed workloads.
• PaaS: you receive an application platform. The provider operates more of the runtime and deployment environment; you manage code, data, settings, and access. It fits software development within supported cloud platform constraints.
• SaaS: you receive finished software. The provider operates the application; you manage its use, users, data, sharing, integrations, and exit arrangements. It fits an existing software product that meets the need.
• Serverless or FaaS: you receive managed capabilities or execution. The provider provisions execution resources; you manage code or service requests, permissions, events, and application behavior. FaaS fits event-driven tasks within its limits.

This comparison describes typical boundaries. A cloud computing architecture can combine several models. A managed platform can also expose a serverless deployment option, so the categories are not always mutually exclusive.

Cloud service models vs cloud deployment models

Service models describe what is delivered and who operates it. Deployment models describe who an environment serves and how cloud infrastructures are arranged.

NIST identifies public, private, community, and hybrid cloud deployment models. A private cloud serves one organization's exclusive use; it may be operated by that organization or a third party, on or off premises. A public cloud offers services for general use with controlled customer access. Community cloud serves a defined group with common requirements. Hybrid cloud connects distinct cloud infrastructures.

A private cloud can deliver IaaS or PaaS. A public cloud can offer infrastructure, platforms, finished applications, and serverless services. “Public cloud versus SaaS” therefore compares different dimensions. Neither deployment choice automatically establishes compliance, security, or an acceptable location for data.

Where other “as a service” products fit

Database, storage, backup, containers, desktops, and AI are often sold “as a service.” These names describe narrower capabilities, which may overlap the core models. They do not all constitute additional formal service models.

A managed database may transfer engine maintenance to the provider while leaving schema design, queries, permissions, and recovery settings with the customer. A container service may manage a control plane while leaving substantial work on nodes and workloads with the customer.

For example, Amazon EKS security guidance describes changing responsibilities across self-managed workers, managed node groups, and more managed execution options. The phrase “managed Kubernetes” alone does not tell you who patches every node or maintains every application dependency.

NIST's cloud-service evaluation guidance supports checking the capability against the definition and the most appropriate service model. In a purchasing decision, ask what you can configure, what the provider operates, what is measured, and what you can export when you leave.

How to choose a cloud service model

Choose the amount of provider management that fits the workload's requirements. Greater control is useful when you need it; otherwise it can become work your team must sustain without a clear benefit.

1. Define the outcome. Specify the application, input data, users, expected output, performance requirements, and acceptable interruptions.
2. Identify necessary control. Check whether you need OS access, particular drivers, custom dependencies, network configuration, or only an application feature.
3. Assign operating tasks. Name who owns updates, access reviews, monitoring, incident response, backups, and restore tests. Check that the team has the time and skills.
4. Test constraints. Verify supported runtimes, data locations, capacity, integration, scaling behavior, and recovery options using a representative workload.
5. Compare full cost. Include computing resources or execution, data storage, requests, data transfer, networking, support, commitments, and engineering time. Check minimum capacity and charges that continue while work is idle.
6. Test the exit. Export representative data and confirm how to recreate the application or replace its essential features elsewhere.

Hivenet's provider-selection questions can help turn those requirements into a service review. A successful test should establish that the workload runs, that failures can be investigated, and that the team can operate the parts left to it.

A practical example: an image-processing application

Imagine a small team building an application that receives photos and produces edited versions. With IaaS, it could install the processing stack on a VM and manage its OS, worker processes, storage connections, and recovery. PaaS might host the application if the required libraries and resource limits fit.

A function could process an upload event if the work fits execution limits and the application handles retries. A finished SaaS image tool might remove the need to build the application at all, provided its features, data terms, and export options meet the requirement.

These are alternative designs for a hypothetical workload, not performance predictions. A custom GPU dependency could favor an instance; an existing application feature could favor SaaS. The workload determines which control is useful.

How Hivenet's services map to these models

Compute with Hivenet provides an infrastructure-oriented path for customer-run GPU or CPU workloads. The available environment matters: Hivenet's VM and container documentation distinguishes VM operating-system control from container templates that do not provide root access. Do not assume every instance gives identical system privileges.

Inference API supplies a managed model endpoint instead of a customer-operated model server. The customer manages integration, requests, data sent to the service, access, evaluation, and output handling. Its current dedicated endpoint model charges for replica runtime; it should not be described as automatically scaling to zero or as generic per-token serverless inference.

S3-compatible object storage supplies managed storage for application data and artifacts. Store and Send are finished user-facing file applications, closer to SaaS. Private AI is a guided deployment path whose operating boundary needs to be established for the project.

These are different services with different responsibilities. Hivenet's architecture overview explains those product-specific paths. Choose the service that supplies the capability and control you need, then confirm its documented limits and operating responsibilities.

Frequently asked questions

Are there three or four cloud service models?

NIST defines three: IaaS, PaaS, and SaaS. Many practical guides discuss serverless as a fourth category, but it overlaps other managed services and is not a fourth NIST model.

Is FaaS the same as serverless?

FaaS is the event-driven function-execution part of serverless. Serverless also includes other managed capabilities, so the terms are not interchangeable.

Which model is cheapest?

There is no universal winner. Compare the same workload, including its idle periods, peak demand, data movement, support, and operating effort. Cost savings from a lower infrastructure bill can be offset by additional server management.

Can one application use several models?

Yes. An application might use a managed platform for its web API, a self-managed instance for a specialized job, and functions for event handling. Each connection introduces permissions, data movement, monitoring, and recovery decisions.

Does a managed service include backups and disaster recovery?

Only the capabilities specified for the selected service and plan. For business continuity, check retention, recovery points, restore procedures, access controls, and recovery time. Provider infrastructure redundancy does not establish that your application's data can be restored after an unwanted change.