What is a cloud deployment model, and which one fits you?

TL;DR: A cloud deployment model answers who owns the infrastructure, who runs it and who gets in. There are five: public, private, hybrid, multicloud and community. Classify your data before you compare a single price sheet, because compliance rules out options long before budget does.

A cloud deployment model answers three questions. Who owns the infrastructure. Who runs it. Who is allowed in.

That's it. Everything else people argue about sits on top of those three answers.

There are five models in common use. The NIST definition of cloud computing set out the first four back in 2011, and multicloud has since joined them in practice.

• Public cloud. Shared kit, run by a provider like Azure or AWS.
• Private cloud. Dedicated kit for one organisation.
• Hybrid cloud. Two or more clouds wired together.
• Multicloud. More than one public provider, on purpose.
• Community cloud. Shared kit for a group with the same compliance rules.

Pick wrong and you go one of two ways. You pay for control you never needed. Or you leave data somewhere you can't afford to leave it.

Here's the thing most guides miss. This is not a shopping decision. It's an architecture decision, and it's very hard to change later.

Key takeaways

What is public cloud, and when does it fit?

Public cloud is multi-tenant. One provider owns the hardware. Lots of customers share it, kept apart by software. Microsoft's own explainer frames it the same way.

The provider handles hardware, patching and physical security. You handle everything above that line.

What you get is speed. Near-instant scale, fast setup, and a bill that moves with use instead of a big cheque up front.

What you give up is control over exactly where the data sits. Some rules need extra contract work to sort out data residency.

Public cloud fits:

• Customer apps with traffic you can't predict
• AI inference that needs to scale up and down quickly
• Dev and test environments
• Marketing sites and content delivery

Worth knowing. Before you default to public cloud for an AI feature, check the provider's data residency options for training data. Some rules want it kept onshore even when inference runs elsewhere.

What makes private cloud worth the extra cost?

Private cloud means dedicated kit for one organisation. On your own site, or run by someone else on hardware nobody else touches.

The difference isn't where the boxes live. It's who can get to them.

Now here's the important bit. A private cloud without self-service provisioning, automated orchestration and metered usage isn't a private cloud. It's a legacy datacentre with a new label. You inherit the exact rigidity you were trying to escape.

Organisations go private when:

• Rules demand tight control over data location and access logs
• The workload touches highly sensitive customer or patient data
• Steady, predictable load makes owned capacity cheaper than pay-as-you-go
• Custom hardware, say GPUs for model training, needs to be fully yours

The trade is running cost. Someone has to plan capacity, schedule patching and refresh hardware. A public provider absorbs all of that.

Worth reading alongside this: what your software infrastructure actually costs over three years, not month one.

How does hybrid cloud actually work?

Hybrid connects two or more separate cloud environments. Usually one private, one public. Work and data move between them.

It's not a stepping stone to full public cloud. Industry analysis now treats hybrid as a permanent shape, because it lets you keep sensitive work private while public cloud carries the customer-facing load.

Hybrid needs real integration work in three places. Data has to move between environments. Identity and access has to be one system, not two. Networking has to treat both clouds as one logical thing.

Done well, you get the compliance posture of private and the elasticity of public. Google Cloud's hybrid guide walks the same ground.

Done badly, you double your surface. Two monitoring stacks. Two security models to audit. A data sync problem that never fully goes away.

• Good: sensitive data stays put while customer features scale
• Good: you can move a workload on cost or speed without a full migration
• Bad: identity and networking integration is always underestimated
• Bad: two operating models mean two skill sets to keep

Do this first. Building hybrid for an AI platform? Map where training happens and where inference happens before you design the network. Training often wants private compute. Inference can usually run wherever is cheapest.

Multicloud and community cloud, explained

Multicloud means using more than one public provider on purpose. To avoid lock-in, to mix the best services, or because a client insists on a platform.

People mix it up with hybrid. The split's simple. Hybrid joins private and public into one architecture. Multicloud runs several public providers, often loosely joined or not joined at all.

Community cloud is infrastructure shared by a group with the same concerns. Usually compliance. Government agencies, health consortiums and financial services groups pool it to share the audit cost.

• Multicloud fits teams avoiding vendor dependency, or chasing an AI service only one provider has
• Multicloud costs you complexity: more contracts, more monitoring, more skills
• Community cloud fits regulated sectors where shared compliance cuts each member's audit load
• Community cloud limits you to what the group agrees on, not your own roadmap

Lock-in is the real driver behind most multicloud decisions. Our group has written on this before: you don't own your AI stack is the same argument one layer up.

How the five models compare

Find your biggest constraint in the left column. Read across. The models that cluster near your answer are your shortlist.

The public-to-private axis is a straight trade. Security and control climb as you move private. Cost efficiency and speed climb as you move public.

Multicloud and community cloud sit off that axis entirely. They are driven by provider strategy and sector rules, not by a control-versus-cost call.

How to choose

Work this list before you commit to anything.

1. Classify your data. Know what is sensitive, regulated or customer-identifying before you decide where it lives. In Australia that starts with the Australian Privacy Principles.
2. Map your compliance load. Data residency, retention and audit rules often rule out options before cost even comes up.
3. Profile your workloads. Steady load suits private or reserved capacity. Spiky load suits public.
4. Set a three-year budget window. Private front-loads cost. Public spreads it. Month one tells you nothing at all.
5. Audit your team's skills. Hybrid and multicloud both need broader skills than one public provider.

Questions to put straight to any vendor:

• What's the SLA, and what happens when it's breached?
• Where exactly does your responsibility end and ours start?
• Can you set data residency by jurisdiction?
• What does the exit plan look like in two years?

Red flags: a vendor who can't answer the exit question, a contract with a fuzzy responsibility split, and any private cloud pitch that never mentions self-service provisioning.

One more. Building an AI platform? Ask about retraining. Work that needs frequent retraining on sensitive data often tips you to private or hybrid, even when public looks cheaper on the spreadsheet.

Deployment model is not service model

These are two different axes. People fuse them and get confused.

Deployment model says who owns and accesses the kit. Service model says which layers of the stack you run. NIST treats them separately, and so should you.

• IaaS. You run the operating system and up. The provider runs hardware, networking and virtualisation.
• PaaS. You run application code and data. The provider runs the runtime, middleware and OS.
• SaaS. The provider runs the lot. You use the finished app.

A private cloud can run any of the three. A public cloud usually offers all three.

For AI platforms the pairing matters. PaaS on public cloud gets models deployed fast. IaaS on private cloud gives you full control of GPU allocation for training. Pick the deployment model first. That keeps the call grounded in compliance and control instead of convenience.

If you want the layer-by-layer view, we broke that down in AI platform architecture.

What our own builds taught us

Two Devwiz builds show the trade in practice.

CARED is a national NDIS allied health platform on the Microsoft stack. Four mobile apps, three web platforms, an admin platform, and integrations into the healthcare and government systems it has to talk to.

Here's the part people get wrong. CARED runs on Azure. That's public cloud. The compliance work didn't go into owning hardware. It went into NDIS-compliant data flows, Microsoft Entra B2B for identity, and the integrations. Regulated data doesn't automatically mean private cloud. It means governed data flows and provable access control, wherever the boxes sit.

The white-label AI SaaS platform went the other way on the same question. It is multi-tenant, built on Supabase with row-level security holding tenants apart, Clerk for auth, and OpenRouter routing between models. Tenant isolation lives in the data model, running on shared public infrastructure. Nobody got dedicated kit. That's what kept it cheap enough to scale to many partners.

Two lessons out of both:

• Compliance is about governed data flows and access control, not about who owns the rack
• The deployment call is an architecture decision made early, not a setting you flip later

Owning your data matters more than owning the hardware. Our group makes that case in full in own your data, not just your model.

Where teams get burned

Most guides treat this as a one-off pick. Choose a model, live with it. That's not how it plays out.

The teams that get hurt treated deployment as a purchase. It is an architecture, and it has to move with the workload.

The other mistake is putting cost first. Cost matters. But data classification and compliance exposure rule out options long before budget does.

And operational maturity is underrated. A private cloud without automation isn't a better public cloud. It's a worse version of both.

So do this first: classify your data honestly, before you compare a single provider or price sheet. Every other answer, including whether hybrid's integration cost is worth paying, falls out of that one.

Weighing private against hybrid for an AI product? We build custom AI platforms and applications around the deployment model your compliance and scale actually demand. Not the one that's easiest to sell. Worth a chat?

For the integration side of the same problem, our group's LLM integration guide covers what sits above the infrastructure.

Frequently asked questions

What are the four types of cloud deployment models?

NIST SP 800-145 lists four: public, private, hybrid and community. Multicloud is now widely treated as a fifth, though it turned up after the original NIST framework.

What does a cloud deployment model mean?

It sets who owns the infrastructure, who runs it and who is allowed in. That is separate from the service model, which is about which layers of the stack you manage.

What is a private cloud deployment model?

Dedicated infrastructure for one organisation, on your own site or run by someone else on hardware nobody shares. Without self-service provisioning and automation it is just a datacentre with a new label.

What is PaaS, with an example?

Platform as a Service. You run your application code and data, the provider runs the runtime and operating system. A managed database or a hosted model endpoint are both examples.

Does regulated data mean I need a private cloud?

No. Plenty of regulated platforms run on public cloud. What matters is governed data flows, provable access control and data residency you can point to in a contract, not who owns the rack.