The cloud service model categorizes delivery types such as IaaS, PaaS, and SaaS and defines responsibility boundaries. It supports decision makers in assessing abstraction levels, control trade-offs, and operational cost allocation. Choice of model affects architecture, compliance posture, billing, and integration with on-premises systems.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
The cloud service model classifies cloud offerings by how much infrastructure, platform, and application operation the provider takes on, and how responsibility is split between provider and customer.
In cloud architecture and its standardization, the classification emerged because outsourced IT services had to be separated not only technically but also organizationally and contractually. NIST made IaaS, PaaS, and SaaS a shared reference so control, operational effort, compliance, and integration needs could be compared.
Think of three stacked layers with a shifting handoff line. With IaaS, the provider supplies compute, storage, and networking while the customer manages the operating system and applications. With PaaS, the provider also runs the platform and runtime. With SaaS, the finished application is delivered. The higher the layer, the more operations shift to the provider and the less control remains with the customer.
The broader paradigm provides IT resources over networks on demand.
The provider supplies infrastructure; the customer usually manages operating systems, runtime, and applications.
The provider also operates platform and runtime; the customer focuses on code and data.
The provider delivers the finished application; the customer uses and configures it.
Security and operations duties are divided differently depending on the service layer.
Multiple customers share one technical base while remaining logically separated.
The model is useful for cloud selection, migration decisions, contract review, and governance. It helps balance control against operational offloading and assign responsibilities clearly. In practice, the boundaries are not always sharp: add-on services, identity, data handling, and network connectivity can shift an offering's responsibility profile.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.