Public, Private, Hybrid and Community Cloud: Picking a Deployment Model

Cloud deployment models describe who the infrastructure serves and who controls it. They are a separate axis from service models — IaaS, PaaS, SaaS — which describe how much of the stack the provider manages. Exam questions frequently test whether you can keep the two apart, because a private cloud can offer IaaS and a public cloud can offer SaaS.

Public cloud

Infrastructure owned and operated by a provider, shared among many unrelated customers, and reached over the internet. Resources are logically isolated between tenants rather than physically separated.

The advantages are the ones that made the model dominant: no capital expenditure, capacity available in minutes, and genuine elasticity — the ability to scale up for an afternoon and back down again, as described under rapid elasticity. Costs follow consumption through the measured service model, which converts fixed cost into variable cost.

The trade-offs are multi-tenancy, less control over the underlying platform, data residency that must be configured deliberately rather than assumed, and the operational lock-in that comes from adopting provider-specific services. Cost predictability is genuinely worse for steady, predictable workloads — consumption pricing is a poor deal for a server that runs at the same load all year.

Private cloud

Infrastructure dedicated to a single organization. It may sit in your own data center or be hosted by a provider as dedicated capacity; what defines it is single-tenancy, not location.

The reasons to choose it are control and compliance: complete authority over configuration, physical placement of data, and the ability to meet regulatory requirements that cannot be satisfied with shared infrastructure. Performance is predictable because nobody else is competing for the hardware.

The cost is that you are buying and operating it. Capital expenditure, capacity planned for peak and idle the rest of the time, and a team maintaining the platform. Elasticity is bounded by what you bought, which removes the single biggest advantage of the public model.

Note the common misconception the exam likes: a private cloud is not automatically more secure. It is more controlled. A well-run public deployment frequently beats a neglected private one, because the provider's baseline is maintained by people who do nothing else.

Hybrid cloud

Private and public used together with some degree of integration between them, so workloads or data can move or span the two.

Typical patterns: sensitive data and regulated systems stay private while public capacity handles variable or bursty demand; public cloud serves as the disaster recovery target for private workloads; or a long migration runs both in parallel. Cloud bursting — overflowing into public capacity at peak — is the textbook example and is harder in practice than it sounds, because the data usually has to be there too.

Hybrid is the most common real-world arrangement and the most complex to secure. Two platforms means two identity models, two sets of network controls, two logging pipelines, and a connection between them that becomes a path worth attacking. Consistent policy across both, and a single place to see events from both, is the design goal.

Community cloud

Infrastructure shared by several organizations with common requirements — a group of hospitals, a set of government agencies, institutions under the same regulator. Costs and governance are shared among the members.

It exists because a sector-specific compliance baseline is expensive to build alone and wasteful to build repeatedly. The difficulty is governance: shared decisions about configuration, change, and incident handling among organizations that are otherwise independent, and a shared blast radius if one member is compromised. Genuine community clouds are less common than the other three, and the model appears on exams more often than in the field.

Choosing between them

Work from constraints rather than preferences. Regulatory and data residency requirements narrow the field first. Workload shape decides next — steady and predictable favors owned capacity, variable and bursty favors consumption pricing. Then existing investment, team capability, and latency requirements, which is where edge deployment enters for anything that cannot tolerate a round trip to a distant region.

Whatever the model, confirm the division of duties. Each arrangement splits responsibility differently, and the shared responsibility model is the document that says which side patches what — assuming rather than checking is the origin of a large share of cloud breaches.

Exam angles

Define the four models by tenancy and control: public is shared multi-tenant provider infrastructure, private is single-tenant dedicated, hybrid combines the two with integration, community is shared among organizations with common requirements. Keep deployment models distinct from service models. Know that private means more control rather than automatically more security, and expect scenarios where a compliance or residency requirement drives the choice.