“Cloud computing” gets used loosely enough that it’s worth starting from an actual definition rather than marketing language. This article covers what specifically makes a service “cloud,” and how the three common service models — IaaS, PaaS, and SaaS — differ in what you manage versus what the provider manages.
A working definition
The most widely cited formal definition comes from the U.S. National Institute of Standards and Technology (NIST), in NIST Special Publication 800-145. It defines cloud computing as a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources — networks, servers, storage, applications, and services — that can be rapidly provisioned and released with minimal management effort or provider interaction.
NIST breaks that down into five essential characteristics:
- On-demand self-service — you can provision compute or storage yourself, without calling anyone.
- Broad network access — resources are available over the network through standard mechanisms.
- Resource pooling — the provider serves multiple customers from a shared, multi-tenant pool of physical resources, dynamically assigned as demand changes.
- Rapid elasticity — capacity can scale up or down quickly, often automatically, to match demand.
- Measured service — usage is metered, and you’re billed for what you actually consume.
Any service that lacks self-service provisioning or usage-based billing isn’t really “cloud” in this formal sense, even if it runs on someone else’s servers.
The three service models
Where cloud offerings differ most in practice is how much of the technology stack the provider manages for you.
Infrastructure as a Service (IaaS) gives you raw compute, storage, and networking — virtual machines, block storage, virtual networks — and you’re responsible for the operating system, runtime, and everything you install on top. Amazon EC2, Google Compute Engine, and Azure Virtual Machines are IaaS products. This is the model closest to running your own servers, just without owning the hardware.
Platform as a Service (PaaS) manages the operating system and runtime for you, and you deploy application code directly. You don’t patch servers or manage a database engine’s underlying infrastructure; the platform handles it. This trades some control for significantly less operational burden.
Software as a Service (SaaS) hands you a finished application, accessed over the network, with the provider managing everything underneath it. Email, CRM, and office suites delivered this way are SaaS — there’s no infrastructure or platform for the customer to think about at all.
Moving from IaaS toward SaaS generally means less operational responsibility and less low-level control, in both directions. Neither end is inherently “better” — it depends on how much of the stack your team actually needs, or wants, to manage. That trade-off is easier to see clearly once you’ve also considered the alternative of not using a cloud provider at all, covered in Cloud Computing vs. On-Premises Infrastructure.
Public, private, and hybrid deployment
Separately from service model, cloud deployments also vary in who the infrastructure is shared with. A public cloud — AWS, Google Cloud, or Microsoft Azure, among others — serves many customers from shared infrastructure. A private cloud is dedicated to a single organization, whether self-hosted or run by a provider on dedicated infrastructure. A hybrid cloud combines both, often to keep specific workloads or data on-premises while using public cloud elasticity for everything else. A related but distinct decision — running across more than one public cloud provider rather than mixing cloud with on-premises — is covered in Multi-Cloud vs. Single-Cloud.
Major providers describe their own platforms in these terms directly: see AWS’s overview of cloud computing, Google Cloud’s introduction to cloud computing, and Microsoft’s cloud computing glossary entry.
Why the geography of “the cloud” still matters
Despite the name, cloud infrastructure runs in specific physical data centers, and where those data centers are located has direct consequences for latency, availability, and data residency. That’s covered in Regions, Availability Zones, and Why Cloud Architecture Is Geographic.
Where this fits in a longer history
Cloud computing as defined above is a relatively recent formalization of ideas — time-sharing, utility computing, virtualization — that go back decades. We trace that lineage, and how today’s major providers emerged, in A Brief History of Cloud Computing, From Mainframes to Kubernetes.
Key takeaway
Cloud computing specifically means on-demand, self-service, metered access to elastic computing resources — not simply “software that runs on someone else’s server.” IaaS, PaaS, and SaaS describe a spectrum of how much of the underlying stack you manage yourself versus hand to the provider, and picking the right point on that spectrum is a genuine architectural decision, not just a vendor preference.
This article explains general cloud computing concepts; specific provider features, pricing, and terminology change over time. See our disclaimer and always check current provider documentation before making architectural decisions.