Cloud Service Models and Deployment Architectures: A Practical Guide to SaaS, PaaS, IaaS
The cloud computing model isn’t one thing — it’s a taxonomy of how different layers of technology get managed, who owns each layer, and what that means for the people building on top.
NIST’s cloud computing reference architecture (SP 500-292) standardized the most widely used framework: three service models defined by the responsibility boundary between provider and customer, four deployment architectures defined by who can access the infrastructure, and five essential characteristics that distinguish true cloud from just “rented servers.”
Service Tiers — The Responsibility Stack
The three primary service models differ along one axis: how much of the technology stack you’re responsible for managing.
At the bottom sits Infrastructure as a Service (IaaS) — compute, storage, and networking. You provision virtual machines, configure firewalls, patch operating systems, install runtime environments, deploy your application, and manage your data. AWS EC2 is the canonical example: you get raw infrastructure and do everything above it.
In the middle sits Platform as a Service (PaaS) — the runtime and supporting services are managed by the provider. You write code, deploy your application, and manage your data, but not the operating system, middleware, or runtime. Google App Engine or AWS Elastic Beanstalk fit here: you push code and the platform handles everything beneath it.
At the top sits Software as a Service (SaaS) — you use the application. The provider manages absolutely everything below your data: infrastructure, runtime, middleware, the application itself. Google Workspace or Salesforce are typical SaaS: there’s no infrastructure to manage at all.
Each tier includes everything below it. PaaS isn’t “a different thing” from IaaS — it is IaaS with the provider taking over more layers. The trade-off is predictable: every step up reduces your control and operational burden.
Here’s the comparison printed from a runnable reference script:
TIERS = [
{"name": "IaaS", ...},
{"name": "PaaS", ...},
{"name": "SaaS", ...},
]Deployment Architectures — Who Accesses What
Independently of the service model, there are four ways cloud infrastructure gets deployed:
Public cloud. Infrastructure is owned and operated by a service provider. Multiple organizations share the same physical resources (multi-tenant), accessible over the public internet. AWS, Azure, and GCP.
Private cloud. Infrastructure dedicated to a single organization. Can be on-premises or hosted by a third party. Banks and government agencies often use it for compliance requirements.
Community cloud. Shared infrastructure built for a specific community of organizations with common concerns — regulatory requirements, security standards, or mission objectives. Less common but fills the gap between public and private.
Hybrid cloud. A composition of two or more deployment models that remain distinct entities but are bound by standardized technology enabling data and application portability. Critical workloads on private infrastructure, burst capacity in a public cloud.
The deployment model choice is orthogonal to the service model — you can mix freely (IaaS on public cloud → EC2, IaaS on private → OpenStack on-prem, PaaS on public → App Engine). The service model answers “what do I manage?” The deployment model answers “who else can reach my infrastructure?”
Here’s the full comparison:
The Five Essential Characteristics
NIST’s definition of cloud computing includes five characteristics that separate true cloud from merely virtualized infrastructure. All five must be present for something to qualify as cloud:
On-demand self-service. A consumer can provision computing capability — server time, network storage — automatically without requiring human interaction with each service provider. You click a button or run an API call; the infrastructure appears.
Broad network access. Capabilities are available over the network and accessed through standard mechanisms. Your resources aren’t locked to a specific terminal type.
Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model. Physical and virtual resources are dynamically assigned per consumer demand.
Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. This is the “burst” behavior that defines cloud economics.
Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability appropriate to the type of service. You pay for what you use.
Without all five, a deployment is virtualized IT — not cloud:
Takeaway
Cloud computing isn’t a single technology; it’s an organizational framework. The service model (SaaS, PaaS, IaaS) determines what you manage and what the provider manages. The deployment model (public, private, community, hybrid) determines who can access your infrastructure. And the five NIST characteristics define the technical bar — true cloud requires on-demand provisioning, network accessibility, pooled resources, rapid elasticity, and measured service. Understanding which decisions you’re making at each layer is what lets you reason about trade-offs instead of choosing based on marketing.