Service model (IaaS / PaaS / SaaS / FaaS) tells you how much of the stack the provider runs. Deployment model tells you who you share the underlying infrastructure with. These are independent choices — you can run IaaS in a public cloud, in a private cloud, in a hybrid arrangement, or in a community cloud. Almost every real architecture picks one of each.
NIST SP 800-145 defines four deployment models. Twenty years in, the boundaries between them blur in practice, but the four categories still describe how organizations actually choose hosting. Most enterprises run a mix — not because they planned to, but because different workloads have different requirements and the answer is rarely "all in one place."
The four models
Shared infrastructure, rented capacity
Infrastructure owned and operated by the cloud provider, available to anyone with a credit card. Your VM may share a physical host with hundreds of other customers' VMs. You pay for what you use; you don't pay for what you don't.
Dedicated infrastructure for one tenant
Cloud-style infrastructure (self-service provisioning, elastic scaling, metered billing) but the underlying hardware is yours alone. Can live in your data center or be hosted by a provider on dedicated equipment.
Public + private, orchestrated together
A composition of two or more distinct cloud infrastructures (public, private, or both) that remain unique entities but are bound together with standardized technology enabling data and application portability. The most common real-world architecture.
Shared by orgs with the same concerns
Infrastructure provisioned for exclusive use by a specific community of consumers from organizations with shared concerns (mission, security requirements, policy, compliance). May be owned by one or more of the orgs, by a third party, or some combination.
Trade-offs at a glance
No deployment model wins on every axis. The matrix below shows which model is strongest on each common decision factor. Reading it down a column tells you the personality of one model; reading it across a row tells you who wins on that specific trade-off.
| Decision factor | Public | Private | Hybrid | Community |
|---|---|---|---|---|
| Up-front cost | Lowest | High | Mixed | Shared |
| Long-term cost at huge steady scale | Mid | Lowest | Mid | Mid |
| Scalability ceiling | Effectively none | What you bought | Burst to public | Sized for community |
| Control over hardware & config | Provider's | Total | Where you put it | Community-defined |
| Data residency / sovereignty | Provider region | Your data center | Sensitive data private | Guaranteed by SLA |
| Compliance fit (FedRAMP High, IL5, etc.) | Standard regions: no | Customizable | Mixed | Built for it |
| Time to deploy a new service | Minutes | Weeks | Depends on side | Member onboarding |
| Maintenance burden | Provider's | Yours | Split | Shared / outsourced |
| Vendor lock-in | High | None / low | Reduced | To community |
Pick the right one for a scenario
Click each scenario to see which deployment model fits best and why. The right answer is rarely "public cloud always" — the constraints attached to the workload almost always pick the model for you.
Hybrid in practice
In real architectures, "hybrid" is the default. Almost no enterprise of any size runs 100% public or 100% private. The questions worth answering up front:
- Identity. Which directory is the source of truth? Active Directory on-prem + Entra ID in the cloud is the most common pattern.
- Network path. ExpressRoute, Direct Connect, Cloud Interconnect, or VPN? Bandwidth, latency, and cost differ by an order of magnitude.
- Data gravity. Where does the data sit? Pulling 100 TB across the WAN every day is an architecture, not a network issue.
- Failure domains. If the public side goes dark, can the private side keep running? If the WAN drops, what stops working?
- Cost visibility. Hybrid bills come from two places. Track both, or you'll be surprised.
Deployment model is a question about who shares the underlying hardware with you, and it is independent of how much of the stack the provider runs. You can have private-cloud IaaS, public-cloud SaaS, hybrid PaaS, and community FaaS — the two dimensions multiply.
Almost every real organization ends up hybrid: public cloud for elasticity and most new workloads, private cloud or on-prem for workloads with hard data-residency or latency constraints, community cloud for regulated work, all glued together with identity, network, and management planes. The skill isn't picking one model; it's knowing which workloads belong on which side of the line.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Amazon Web Services. (n.d.). AWS GovCloud (US). https://aws.amazon.com/govcloud-us/
- Mell, P., & Grance, T. (2011). The NIST definition of cloud computing (NIST Special Publication No. 800-145). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-145
- Microsoft. (n.d.). Azure Government documentation. Microsoft Learn. https://learn.microsoft.com/en-us/azure/azure-government/
- U.S. General Services Administration. (n.d.). FedRAMP marketplace. https://marketplace.fedramp.gov/