Part 1 of 4 · 2026-07-25

The Five Cloud Deployment Models

Every cloud strategy conversation starts with the same argument: public, private, hybrid, or multi-cloud? It's the wrong argument. If you run a large enterprise, you're already all of them. A practitioner's primer on the five deployment models, their real trade-offs, and why the models are just vocabulary while the actual work is deciding what runs where.

By Tom Ward, Enterprise Architect — Cloud & Infrastructure

Download the deep-dive PDF6 pages — the full model in detail, a checklist, and curated references. Free, no signup.

The Five Cloud Deployment Models — architecture infographic — You're already hybrid multi-cloud — the models are vocabulary, placement is the work

The five models

Four of these come from NIST's definition of cloud — private, community, public, and hybrid; multi-cloud is the industry's fifth. The confusion worth clearing: hybrid mixes private and public, while multi-cloud means two or more public providers. The real end-state for most large banks is both at once — hybrid multi-cloud.

Private

“Exclusive to you”

Infrastructure exclusive to one organization — an owned data center or a colocation facility. Buys: control, isolation, data residency, and predictable performance — and with OpenShift or Azure Local, the cloud operating model on your own gear. Costs: you own the capex, capacity, refresh, and platform operations, and your elasticity is bounded by what you built.

Public

“Provider-run, open to all”

AWS, Azure, Google Cloud. Buys: elasticity, managed services, global reach, and no capital outlay — the fastest path to new capability. Costs: less control, a shared-responsibility model, data-residency and egress constraints, lock-in, and cost that surprises at scale if left ungoverned.

Hybrid

“Private + public, bound together”

Buys: the right workload in the right place — regulated on private, bursty on public — plus a migration bridge and cross-environment resilience. Costs: complexity at the seam — networking, identity, data gravity, and keeping governance and security consistent across both sides.

Multi-cloud

“Two or more public providers”

Buys: the ability to survive one provider's failure, freedom from lock-in, best-of-breed services per cloud, and negotiating leverage. Costs: the highest operational complexity of any model — portable architecture, duplicated skills and tooling, cross-cloud identity and networking, inter-cloud egress, and the lowest-common-denominator trap. Most “multi-cloud” is best-of-breed or by-acquisition, not resilience; true active-active across providers is, in the research literature's words, still “in its infancy.”

Community

“Shared by orgs with common needs”

Buys: shared cost and a shared compliance baseline for a sector or consortium. Costs: governance by committee and limited flexibility — real, but niche in banking, where most institutions have the scale to run their own private estate.

The model is a label. Placement is the work.

A deployment model is just a name for where a workload already runs. The decisions that actually determine cost, risk, and reliability sit one layer below the model — and there are three of them, each a companion part in this playbook.

Decision 1
Where each workload goes
Environment — Part 2
Stay in place, move to a colocation private cloud, or go to public cloud. This is the environment decision, made per application by data classification, criticality, latency, dependencies, cloud-readiness, and TCO.
Decision 2
Which zone it lands in
Neighborhood — Part 3
The security zone within an environment, defined by risk, security, data privacy, and criticality. The same map applies in every environment, so this is what lets a migration keep its security posture instead of quietly weakening it.
Decision 3
How reliable it must be
Reliability archetype — Part 4
The deployment archetype, from zonal to global, that delivers the workload's target availability. The nines you owe decide the posture you buy.

The Model Reality Test

Ten checks on whether your organization is running its deployment models on purpose. Score one point per honest “yes.” Below seven, your “cloud strategy” is a collection of accidents with a label on top.

You can name which models you actually run today — and which arrived by acquisition or by a team's local choice.
You treat hybrid multi-cloud as the state you're in, not a future decision to be made.
You know the difference between hybrid (private + public) and multi-cloud (two or more public) — and use the terms precisely.
Your “private” includes colocation private cloud (OpenShift, Azure Local), not just an owned data center.
Your multi-cloud is honestly labeled — best-of-breed, by-acquisition, or genuine resilience — and priced accordingly.
You are not paying for a resilience story your architecture can't deliver (active-active across clouds the apps can't support).
Placement is decided per workload — environment, neighborhood, reliability — not by a blanket model mandate.
Governance and security are consistent across the seams between private and public, and between clouds.
Cost is visible across every environment, so the “which model” question can be answered with numbers.
New workloads get a deliberate placement at design time — so the estate grows on purpose, not by default.

Going deeper

Sources worth your time, roughly in the order a team should read them.

Part of a four-part arc — read the rest of the playbook.

Back to the playbook