Cloud Service and Deployment Models

What you will be able to do

• Recognize the essential characteristics that distinguish a cloud service from ordinary remote hosting.
• Distinguish IaaS, PaaS, and SaaS by the computing layer the customer receives and operates.
• Distinguish public, private, community, and hybrid cloud by access and governance boundary.
• Classify a workload on both axes and verify the responsibility and exit boundaries before adoption.

01

Read Two Axes Before Choosing

A cloud label should tell you more than where a server sits. A useful classification records the capability being consumed, the layer the customer still operates, and the boundary around who may use the environment.

Service models and deployment models answer different questions. IaaS, PaaS, and SaaS describe the capability delivered to the customer. Public, private, community, and hybrid describe how the cloud environment is made available and combined.

Keep both axes visible in a design note. A workload can use a public PaaS service, a private IaaS environment, or another valid combination. One label never automatically determines the other.

02

Recognize the Cloud Characteristics

Cloud services provide resources on demand through a network-accessible interface. Capacity comes from a pooled environment and can expand or contract quickly enough to support changing demand without a separate hardware purchase for every adjustment.

Usage is measured so consumption can be monitored and reported. This signal supports capacity, governance, and charging decisions, but a price page alone does not prove that a service has the other cloud characteristics.

Remote access and virtualization can support cloud delivery, yet neither one is sufficient by itself. Look for on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service as a connected operating model.

03

Use IaaS for Guest Control

Infrastructure as a Service exposes fundamental resources such as processing, storage, and networking. The provider operates the underlying cloud infrastructure while the customer deploys and controls the guest operating system, applications, and much of the workload configuration.

Choose IaaS when the workload needs operating-system control, a custom network appliance, or software that cannot fit a managed runtime. That flexibility also leaves the customer responsible for guest patching, hardening, application deployment, and recovery planning.

Verify an IaaS choice with evidence from both sides of the boundary. Record the provider resource, image, network placement, and service state, then record the guest OS version, application health, configuration owner, and backup path.

04

Use PaaS for Application Delivery

Platform as a Service provides an application-hosting environment. The provider manages the underlying infrastructure and platform layers, while the customer deploys code and controls the application, its data, and the configuration exposed by the service.

PaaS reduces guest-operating-system work, but it also narrows low-level control. The team must confirm supported runtimes, deployment methods, scaling behavior, network integration, data services, observability, and limits before assuming an existing application will fit.

A successful platform deployment is not merely a green upload message. Verify the application endpoint, health signal, logs, configuration source, data connection, scaling rule, and rollback or export path with a small reproducible release.

05

Use SaaS for a Ready Application

Software as a Service provides a ready application through a client interface or program interface. The provider operates the application and underlying cloud stack; the customer uses approved features and manages the tenant settings that remain exposed.

SaaS fits needs such as hosted email, collaboration, ticketing, or customer management when the organization prefers configuration over software deployment. It offers less control over runtime, patch timing, internal architecture, and feature implementation than IaaS or PaaS.

Before adoption, verify identity integration, administrator roles, data ownership, retention, export, audit evidence, availability commitments, and account closure. Using a finished application does not remove the customer's responsibility for users, data, and safe configuration.

06

Separate the Deployment Boundaries

A public cloud is provisioned for open use by the general public, while a private cloud is reserved for one organization. The words describe the access and governance boundary, not whether an individual workload is exposed directly to the internet.

A community cloud is reserved for organizations with shared concerns such as mission, policy, security, or compliance. Its defining feature is the agreed community boundary, not a shared chat group or a normal public-cloud subscription used independently by several customers.

A hybrid cloud combines distinct cloud environments that remain separate but are connected for data or application movement. A single public environment with two subnets is not hybrid, and an ordinary link from one office to a hosted application does not prove a hybrid cloud design.

07

Match the Model to the Workload

Start with the workload requirement rather than a provider product name. Record the required operating-system control, application runtime, user experience, data sensitivity, network reach, scaling pattern, recovery objective, skills, and approved cost boundary.

A legacy application that needs custom operating-system modules may point toward IaaS. A new web application using a supported runtime may fit PaaS. A team that only needs a finished ticketing application may prefer SaaS; these are starting hypotheses, not automatic decisions.

Then choose the deployment boundary independently. Compare public, private, community, and hybrid options against ownership, connectivity, residency, shared-policy, isolation, and integration needs. Document which requirement each choice satisfies.

08

Verify Responsibility and Exit

Create a responsibility map before migration. For every layer, name the provider duty, the customer duty, the verification signal, and the person who responds when the signal fails. Do not infer this map only from the model acronym.

Run a small reversible trial with representative identity, network, data, deployment, monitoring, backup, and failure behavior. Confirm the service limits and the exact evidence available to both operators and reviewers before moving sensitive or production data.

Test the exit path as carefully as the entry path. Record how to export data and configuration, revoke access, remove temporary resources, preserve required logs, estimate remaining charges, and return to a known state if the model does not fit.

09

Recap Before Practice and Prove

Cloud computing combines on-demand access, broad network access, pooled resources, rapid elasticity, and measured use. Remote or virtualized infrastructure is not automatically a complete cloud service.

IaaS delivers fundamental compute, storage, and network resources while leaving the guest operating system and workload with the customer. It offers the most low-level control of the three service models.

PaaS delivers a managed application platform, while SaaS delivers a finished application. Moving upward reduces platform operations but also reduces low-level control and changes the evidence available to the customer.

Public, private, community, and hybrid are deployment boundaries. They are independent from the IaaS, PaaS, and SaaS service-model axis and should be recorded separately.

Choose from workload requirements, map responsibilities, verify a small trial, and test the export and cleanup path. A model name is useful only when the operating and governance boundaries are explicit.