The cloud deployment model defines patterns for delivering IT resources across public, private, hybrid or community clouds and includes SaaS/PaaS/IaaS variants. It supports architectural decisions, governance, operations and compliance mapping. Decision criteria include cost, security, control, scalability and operational capabilities.
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 organizes, connects, or makes decisions possible.
The cloud deployment model describes how cloud resources are organized for delivery: public, private, hybrid, or community-based. It helps classify tenancy, access boundaries, and responsibility for a workload.
The term captures a core cloud dimension: not the service type, but where resources are operated and how they are separated. NIST’s 2011 definition explicitly treats deployment models as part of the cloud concept. That framing addresses the practical problem of naming public, private, hybrid, and community setups so that control, data location, sharing, and workload responsibility can be compared consistently.
Think of deployment as a map of operating boundaries. Public cloud means shared provider infrastructure, private cloud means a dedicated environment for one organization, community cloud means a shared environment for a defined group, and hybrid cloud links two or more such environments through explicit interfaces and rules. The key question is placement and organizational boundary, not how much of the stack is delivered.
It marks where a cloud environment is technically and organizationally separated.
The infrastructure is operated by a provider for multiple customers to share.
The environment is intended for a single organization rather than general sharing.
Multiple deployment environments are connected and used together.
Several organizations with similar requirements share one environment.
The model is useful for architecture decisions, cloud migrations, procurement, and security or compliance reviews. It matters most when cost, control, scalability, and regulatory constraints must be balanced. It does not define the service model or specific operating procedures; those require a separate target architecture and clear ownership assignments.
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.