Types of cloud computing explained: service models vs deployment models

The types of cloud computing fall into two main classifications. Service models, such as IaaS, PaaS, and SaaS, describe what a provider delivers and which parts of the technology it manages. Deployment models, such as public, private, community, and hybrid cloud, describe who can use the cloud infrastructure and how it is organized.

These classifications work together. A virtual machine can be an IaaS service in a public cloud; a development platform can provide PaaS inside a private cloud. Multicloud, serverless, and edge computing add other useful distinctions, but they answer different questions. Understanding those differences helps you compare control, operating work, and provider dependence without treating every term as a competing option.

Why lists of cloud types differ

The NIST definition of cloud computing, published in 2011, identifies three service models and four deployment models. That remains a useful baseline. It also defines five essential cloud characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

Commercial terminology has expanded since then. For example, Google Cloud's explanation of cloud types discusses serverless alongside IaaS, PaaS, and SaaS. Other lists emphasize multicloud or leave out community cloud. A list can be useful without reproducing NIST exactly, provided it explains what it is classifying.

Start with two questions: what capability are you receiving, and how is the cloud environment arranged? Then ask whether additional terms describe provider choice, code execution, or the location of processing. This avoids comparisons such as “SaaS versus hybrid cloud,” which mix different categories.

Cloud service models: what the provider manages

A cloud application depends on physical equipment, networking, an operating system, a runtime, application code, and data. Service models place the boundary between provider and customer at different points in that stack. The exact boundary still depends on the product and contract.

Infrastructure as a Service: IaaS

IaaS supplies computing resources that customers configure for their workloads, including virtual machines, storage, and networking. The provider operates the facilities, physical equipment, and underlying virtualization. For a typical virtual machine service, the customer manages the guest operating system, installed software, applications, data, and access settings.

That control is useful when a workload needs a particular operating system, specialized software, or a configuration that a managed platform does not support. Examples include development environments, existing applications, scientific computing, and machine-learning workloads.

The work does not end when the instance starts. Someone must patch the guest OS, protect credentials, monitor resource use, manage backups, and test recovery. A provider may offer additional management services, so IaaS does not mean the entire environment is unmanaged. Ask which tasks are included and which belong to your team.

Platform as a Service: PaaS

PaaS provides an environment for developing and running applications. The provider manages the underlying infrastructure and operating systems, along with supported runtimes or middleware. Developers focus on their code, application settings, data, and user access.

A team building a web application or API may use PaaS to avoid maintaining virtual machines. Some managed database services also fit this model. However, the label alone does not tell you whether database tuning, updates, scaling, or recovery are automatic, configurable, or separately billed.

The trade-off is reduced control over the managed layers. Supported languages, runtime versions, deployment methods, and integrations can shape the application. Check what happens when a runtime is retired and how much work a move to another platform would require. For managed Kubernetes, inspect the actual division of work: managing the control plane does not necessarily mean the provider manages worker nodes or application operations.

Software as a Service: SaaS

SaaS delivers an application that the provider operates. Customers use the software through a browser, client application, or API rather than installing and maintaining its underlying stack. Email, document collaboration, customer management, accounting, and project management are familiar uses.

The customer still has decisions to make. Administrators manage accounts, permissions, sharing rules, integrations, and the information entered into the service. Devices and credentials still need protection. Procurement teams need to understand retention, deletion, export options, and contract terms.

SaaS usually leaves customers with the least direct control over the application's technology and release schedule. It can reduce operating work when the product meets the need, but a feature gap may require changing a business process or choosing another application.

Where serverless and Function as a Service fit

Serverless services move server provisioning and much of the capacity-management work to the provider. Servers still exist. The customer uses an execution environment or managed service without continuously operating the underlying machines.

Function as a Service, or FaaS, is one serverless approach: code runs in response to a request or event. For example, a function could validate a newly uploaded file and send its details to a queue. AWS Lambda Functions are a provider example. Serverless also extends beyond functions to other managed execution and data services.

For an event-driven API, automation job, or intermittent processing task, this can remove useful amounts of infrastructure work. It does not remove application design, monitoring, access management, or failure handling. Review startup behavior, execution limits, concurrency, networking, and local testing before choosing a service. Billing and scaling behavior vary; the word serverless does not promise that every service scales to zero or charges only for individual requests.

IaaS vs PaaS vs SaaS: a comparison

The table describes typical boundaries. Serverless is included as an additional execution approach, not as a fourth service model in the original NIST definition. Control and operating work refer to the customer's role.

Model	What you receive	Provider manages	Customer manages	Control	Operating work	Typical use
IaaS	Configurable compute, storage, and networking	Physical infrastructure and virtualization	Guest OS, software, workloads, data, and access	High over the guest environment	OS and workload operations	Custom software or computing workloads
PaaS	A managed application platform	Infrastructure, OS, and supported platform components	Code, application settings, data, and access	Limited to supported platform choices	Application operations	Web applications and APIs
SaaS	A finished application	Application and supporting stack	Users, settings, data, devices, and integrations	Product configuration	Administration and integration	Standard business applications
Serverless functions	An environment that runs functions	Servers and execution infrastructure	Code, events, permissions, data, and monitoring	Within execution limits	Function and workflow operations	Event processing and automation

A label is a starting point for evaluating a service. Compare its responsibility documentation with the actual settings and tools available to your team.

Cloud deployment models: who uses the environment

Deployment models describe access to cloud infrastructure and the relationship between environments. They do not specify whether a customer receives virtual machines, a development platform, or finished software.

Public cloud

A public cloud makes cloud infrastructure available for use by the general public. A provider operates it and offers services to customers. “Public” describes availability of the service, not permission to read customer data.

Customers can obtain resources without owning the underlying hardware. Services may share physical infrastructure, while providers can also offer dedicated capacity or isolation options. Public cloud does not mean every workload shares one physical host or that every service must be reached over the public internet.

Check available regions, access controls, connectivity, pricing, quotas, and support. Less hardware ownership can be useful, but total cost still depends on utilization, data transfer, managed-service charges, and operating work. Provider dependence and exit requirements also deserve attention.

Private cloud

A private cloud is reserved for one organization, potentially serving several internal teams. It can run on the organization's premises or at another location. The organization, a third party, or a combination of both may manage it.

Private cloud can support organization-specific configurations and greater control over an environment. That can matter for unusual hardware, integration, or governance requirements. It also brings capacity planning and operating responsibilities, whether performed internally or purchased from a provider.

Virtualizing a set of servers does not by itself create a private cloud. The environment should still provide cloud characteristics such as self-service, pooled resources, elasticity, and measured use. Nor does exclusive use make an environment inherently more secure: architecture, configuration, access, maintenance, and staff capability determine the result.

Community cloud

A community cloud serves a defined group of organizations with shared concerns, such as a research mission, security policy, or governance requirements. The participating organizations, a third party, or both may operate it, on or off their premises.

For example, a group of research institutions could establish a shared cloud with common access and data-handling rules. The defining feature is the community's agreed requirements. Several unrelated customers using the same public provider do not automatically form a community cloud.

Shared funding and policies can be useful, but participants need clear decision-making and responsibility arrangements. Service choice, funding disputes, membership changes, and conflicting priorities can constrain the environment. Community cloud remains part of NIST's four deployment models even when a commercial comparison omits it.

Hybrid cloud

In the NIST definition, hybrid cloud combines two or more distinct cloud infrastructures, such as private, community, or public clouds, connected by technology that enables data and application portability. The individual clouds retain their identities.

Industry usage is often broader and may include conventional on-premises systems connected to public cloud services. Make the meaning clear in a design or contract. Using a local server and an unrelated online application does not establish how those environments work together.

A hybrid design might retain a dataset in a private environment while sending approved processing jobs to a public service. It may also support staged migration or a recovery plan. Those outcomes require working identity controls, network connections, data-transfer arrangements, monitoring, and tested procedures. A hybrid label does not make an application portable or create spare capacity on demand.

Multicloud vs hybrid cloud

Multicloud means using services from more than one cloud provider. It describes provider choice, while hybrid cloud describes a combination of environments. Multicloud is not one of NIST's four original deployment models, though contemporary provider explanations may group it with them.

An organization using SaaS from one provider and public-cloud virtual machines from another has a multicloud arrangement. A private cloud connected to a public cloud can be hybrid without using several external cloud providers. A private environment connected to public services from two providers can be both hybrid and multicloud.

Reasons to use several providers include required regional availability, different service capabilities, procurement requirements, or systems inherited through an acquisition. The costs include additional contracts, identity controls, billing systems, skills, and monitoring.

Multicloud does not automatically provide resilience. If one essential application runs only at provider A, an unrelated service at provider B does not keep it available when A fails. Resilience requires an architecture, data synchronization, available capacity, and tested recovery procedures appropriate to that application. Portability likewise depends on formats, APIs, dependencies, and the effort needed to move.

Comparing deployment models

The last row describes a strategy that can overlap with the deployment models above it. Control and workload are conditional on the services and operating agreements selected.

Model or strategy	Operator	Users	Arrangement	Customer control	Operating burden	Common reason	Main limitation
Public cloud	Provider	Customers from the general public	Provider-operated cloud infrastructure	Within service boundaries	Depends on service model	Access resources without owning hardware	Provider and service dependence
Private cloud	Organization, third party, or both	One organization	Exclusive cloud, on or off premises	Can include infrastructure choices	Capacity and operations must be assigned	Specific control or integration needs	Staffing and capacity requirements
Community cloud	Members, third party, or both	A defined community	Shared cloud for common requirements	Shared through governance	Jointly agreed responsibilities	Common mission or policies	Coordination between organizations
Hybrid cloud	Operators of the connected environments	Authorized users across environments	Distinct clouds connected; industry usage may include other local systems	Varies by component	Integration and cross-environment operations	Connect selected workloads and data	Network and integration complexity
Multicloud strategy	Several providers plus the customer's team	The organization's authorized users	Services from multiple providers	Varies by service and provider	Multiple tools, contracts, and controls	Different capabilities or sourcing needs	More dependencies to manage

Distributed cloud and edge computing

Distributed cloud concerns where cloud services operate and how they are coordinated. IBM's definition describes public cloud services across several physical locations under centralized management. Other providers may use the term differently. It is worth checking the operating model behind the label.

Edge computing places processing close to users, devices, or data sources. It describes location, rather than ownership or a service boundary. An edge installation could form part of a private, public, hybrid, or distributed environment.

Distributed does not necessarily mean decentralized. Infrastructure can span several locations while one organization controls it. Neither term replaces IaaS, PaaS, SaaS, or the deployment classifications.

How the classifications work together

Consider these hypothetical arrangements:

• Public IaaS: an engineering team rents virtual machines and installs its own simulation software.
• Private PaaS: an internal platform team runs an application platform on the organization's private cloud for its developers.
• SaaS on public infrastructure: a business uses an accounting application whose provider operates it on public-cloud resources. The business receives SaaS; the application's provider may consume IaaS or PaaS underneath.
• Hybrid services: an organization connects private-cloud infrastructure to a public managed application platform, with explicit rules for moving data between them.
• Multicloud services: a company buys collaboration software, a managed database, and virtual machines from different providers. Each service has its own management boundary.

These combinations are possible patterns, not a promise that every product supports every arrangement. Deployment location, supported integrations, and licensing must be checked for the actual services.

For a concrete infrastructure example, Compute with Hivenet provides instances on which customers control their operating environment and software. Hivenet's S3-compatible object storage provides a separate storage capability. Customers still manage how their applications use stored data and access credentials. The products' specific responsibilities matter more than assigning every storage service the same model label.

Shared responsibility remains part of every choice

Moving from IaaS to PaaS to SaaS generally transfers more of the technology stack to the provider. The Microsoft shared-responsibility matrix illustrates how that boundary shifts, while customers retain important responsibilities for data, identities, access, settings, and devices.

For each service, record who performs updates, reviews access, monitors incidents, configures backups, and tests restoration. Include retention, deletion, and usable exports in that review. The cloud security guide explains the controls to examine.

A technical model name does not settle legal obligations or establish compliance. The relevant data, uses, jurisdictions, contracts, and implemented controls still need review. Managed services reduce specified operating tasks; the organization still needs to choose, configure, and oversee them.

Which type of cloud computing should you choose?

Begin with one workload and its requirements. Choose the capability first, then the deployment and operating arrangements that can support it. A company can use several models for different needs.

1. Define what you need to receive. A finished business application suggests evaluating SaaS. Custom application development may suit PaaS. A requirement to configure the OS or specialized software points toward IaaS.
2. Identify the control you need. Write down required runtime versions, hardware access, networking, update windows, and integrations. Separate actual requirements from preferences that add work without improving the workload.
3. Assign the operating work. Confirm that someone can handle each customer responsibility, including during an incident. If your team cannot maintain an OS securely, the flexibility of a virtual machine may be a poor trade.
4. Specify data and location requirements. Consider processing, primary storage, backups, logs, administrative access, and subcontractors. The guide to cloud data locations explains why a region name alone is not the whole answer.
5. Test connectivity and performance. Check latency, bandwidth, offline behavior, data-transfer volume, and dependencies between services. Placing computation near a device only helps if the application can use that arrangement.
6. Compare a realistic operating cost. Include expected resource use, idle capacity, transfer, support, licenses, staff time, and migration. No deployment model is automatically the least expensive.
7. Plan for change and exit. Test an export or migration path. Check usable data formats, API dependencies, configuration portability, contract changes, and the work required if a product feature disappears.

Finish with a responsibility record, a cost estimate based on the workload, and a small test that exercises failure and recovery. Those results will tell you more than choosing a cloud model by name alone.

Frequently asked questions

What are the main types of cloud computing?

Name the classification first. NIST identifies three service models, IaaS, PaaS, and SaaS, and four deployment models, public, private, community, and hybrid cloud. Service models describe the capability and management boundary; deployment models describe how the cloud infrastructure is organized and used.

What is the difference between IaaS, PaaS, and SaaS?

IaaS gives customers configurable infrastructure. PaaS provides a managed environment for building and running applications. SaaS delivers an application operated by its provider. The provider generally manages more of the stack as you move from IaaS to SaaS, while customers retain responsibility for their use of the service.

Is serverless a fourth cloud service model?

Some modern classifications present it that way, but it is not one of the original three NIST service models. Serverless describes approaches that move server provisioning and execution-infrastructure management to the provider. FaaS is one form of serverless; the two terms are not exact synonyms.

Is multicloud the same as hybrid cloud?

No. Multicloud uses more than one provider. Hybrid connects different environments. An architecture can be both, and neither label alone guarantees that workloads can move or recover between them.

Can an organization use IaaS, PaaS, and SaaS together?

Yes. It could use SaaS for accounting, PaaS for a customer application, and IaaS for specialized processing. Each service needs its own responsibility and dependency review.

Is distributed cloud a separate alternative to public or private cloud?

It describes an architectural arrangement across locations. To understand a distributed service, also identify who can use its infrastructure, who controls it, what capability it provides, and which tasks the customer manages.