Cloud deployment models define where cloud resources are hosted and who can use them; cloud service models define what level of technology is delivered to the customer.
That distinction matters because the common question “What are the four types of cloud computing?” is often answered in two different ways. In the deployment-model taxonomy used by NIST SP 800-145, the four cloud deployment models are public cloud, private cloud, community cloud and hybrid cloud. IaaS, PaaS, SaaS and FaaS are service models, which can run within those deployment models rather than replacing them.
The clean taxonomy: deployment models and service models
A deployment model answers questions about ownership, access and location. It explains whether infrastructure is shared broadly over the internet, dedicated to one organisation, shared by a defined group, or combined across environments. For readers who need the foundation first, what is cloud computing? is the starting point before comparing models.
A service model answers a different question: how much of the technology stack the provider manages. Infrastructure as a Service gives customers virtual machines, storage and networking. Platform as a Service adds managed runtime and development services. Software as a Service delivers an application. Function as a Service runs event-driven code without the customer managing servers directly. The same organisation might consume SaaS from a public cloud, run a PaaS-like platform in a private cloud, and use IaaS across a hybrid estate. A deeper explanation of IaaS, PaaS and SaaS helps clarify that second layer.
| Cloud concept |
What it describes |
Examples of the question it answers |
| Deployment model |
Where the cloud runs, who controls it and who can access it. |
Is the environment public, private, community or hybrid? |
| Service model |
Which parts of the technology stack are delivered as a service. |
Is the workload using IaaS, PaaS, SaaS or FaaS? |
| Cloud strategy |
How an organisation combines providers and operating choices. |
Is the organisation standardising on one provider, using hybrid cloud, or adopting a multi-cloud approach? |
Public cloud
Public cloud is a cloud environment made available to many customers over a shared provider platform. The provider owns and operates the underlying infrastructure, while customers consume services on demand. Microsoft Azure, Amazon Web Services and Google Cloud are common public cloud providers, although individual services within those platforms may support private networking, dedicated hardware options or hybrid extensions.
Public cloud is often the practical default for new digital services because it reduces the need to purchase and operate physical infrastructure. A retailer launching an ecommerce analytics workload, for example, can provision storage, compute and managed databases quickly, then scale usage as demand changes. The trade-off is that the organisation must understand shared responsibility: the provider secures the cloud infrastructure, while the customer remains responsible for configuration, identity, data protection and workload governance. The shared responsibility model in cloud security is central to using public cloud safely.
Public cloud fits well when workloads benefit from elasticity, global reach and managed services. It is less straightforward when data residency, highly predictable low-latency links to local systems, bespoke hardware dependencies or strict internal control requirements dominate the decision. Cost also needs active management because on-demand services can expand quickly when tagging, budgets, lifecycle policies and architecture controls are weak.
Private cloud
Private cloud is a cloud environment dedicated to one organisation. It may run in the organisation’s own data centre or be hosted by a third party, but the defining feature is exclusive use rather than public access. A private cloud should still provide cloud characteristics such as self-service provisioning, resource pooling, measured usage and automation; a traditional virtualised server estate does not automatically become a private cloud because it uses virtual machines.
Private cloud is often chosen when control requirements are stronger than the benefits of broad public-cloud consumption. A financial services organisation might keep a sensitive workload in a private cloud to meet internal governance, audit and data-handling requirements while still giving development teams automated provisioning. The model can also suit workloads with specialised hardware, predictable demand or deep dependencies on local systems.
The main challenge is operational maturity. Private cloud requires platform engineering, capacity planning, patching, security operations and service management that public cloud providers otherwise absorb at scale. It may reduce some external dependency concerns, but it does not remove the need for disciplined identity management, backup, monitoring, vulnerability management and policy enforcement.
Community cloud
Community cloud is a cloud environment shared by several organisations with common requirements. Those requirements might relate to regulation, security, jurisdiction, procurement or a shared mission. Community cloud is less common than public, private and hybrid cloud, partly because the hard work is often governance rather than technology.
In practice, community cloud may look like a jointly governed private cloud serving a defined group, such as public-sector bodies with similar compliance obligations or organisations in a regulated consortium. The participants need agreement on funding, operating rules, access control, risk ownership, service levels and change management. Without that governance layer, a shared platform can become difficult to manage even if the technical architecture is sound.
Community cloud should not be confused with a public cloud programme aimed at a sector or charity group. A discounted or tailored public cloud offering is still usually public cloud unless the infrastructure and governance are genuinely dedicated to a defined community.
Hybrid cloud
Hybrid cloud combines two or more distinct cloud environments, typically private and public cloud, that remain separate but are connected in a way that allows data and applications to move or operate across them. The point is not simply that an organisation has both a data centre and a cloud subscription. The environments need a deliberate integration layer covering networking, identity, security, operations and workload placement.
A common hybrid scenario is a manufacturer that keeps latency-sensitive factory systems close to production equipment while using public cloud for analytics, backup or central management. Another example is an organisation that runs regulated systems in a private environment but uses public cloud capacity for customer-facing services or disaster recovery. Vendor technologies such as Azure Stack Hub and AWS Outposts are examples of offerings designed to extend cloud operating models into local or dedicated environments, but the deployment model is defined by the architecture rather than by the vendor name.
Hybrid cloud is useful when constraints are mixed, but it is operationally demanding. Identity federation must work consistently across environments. Network ranges can overlap after mergers or rushed migrations. Data gravity can make large datasets expensive or slow to move, and egress charges may influence architecture. Policy enforcement, logging, incident response and deployment pipelines also need consistency, or teams end up with toolchain sprawl and unclear ownership. Cloud and infrastructure teams building these skills often start with structured cloud and DevOps training before specialising by platform.
Hybrid cloud and multi-cloud are different ideas
Multi-cloud means using services from more than one cloud provider. It is a strategy layered on top of deployment choices, not one of the four deployment models in the NIST taxonomy. An organisation might use Azure for workplace identity services, AWS for application hosting and Google Cloud for analytics, while still relying mostly on public cloud deployment models.
Multi-cloud can support vendor diversification, regional coverage, latency needs or data-locality requirements. It can also increase cost and complexity because each provider has different identity patterns, networking constructs, observability tools, billing models and security controls. A sensible multi-cloud strategy is usually workload-led, not provider-led: the organisation should be clear about why each provider is present and how governance will remain consistent. Readers comparing these approaches can explore hybrid cloud and multi-cloud differences in more detail.
How to choose the right cloud deployment model
The right deployment model is usually determined by constraints rather than preference. A simple decision sequence helps avoid vendor-first thinking. First, identify whether the workload handles regulated, sovereign or otherwise in-scope data. Second, assess whether latency, edge processing or legacy-system adjacency limits where the workload can run. Third, compare the operating model: public cloud usually favours operating expenditure and managed services, while private and community models require stronger internal platform capability and governance. This kind of practical framework is also used in Readynez learning paths to connect cloud architecture choices with real operational responsibilities.
Public cloud is often appropriate for general-purpose workloads, customer-facing applications, analytics, development environments and services that benefit from elastic capacity. Private cloud becomes more attractive when strict control, predictable demand or deep internal dependencies outweigh the advantages of public-cloud managed services. Community cloud suits groups that share regulatory or governance requirements and are prepared to manage joint decision-making. Hybrid cloud fits mixed estates where some workloads can move to public cloud while others must remain close to local systems, specialised hardware or controlled data environments.
The skills question should not be treated as an afterthought. Public cloud still requires expertise in identity, networking, security, cost management and automation. Private and hybrid models add platform operations and integration complexity. Depending on the technology stack, teams may build role-based skills through Microsoft cloud training via Microsoft courses, architecture and operations paths through AWS courses, or security foundations through ISC2 and CompTIA training.
Where the four models fit
The four cloud deployment models are best understood as placement and governance choices. Public cloud offers shared provider infrastructure and broad managed-service access. Private cloud gives one organisation dedicated cloud capability. Community cloud serves a defined group with shared requirements. Hybrid cloud connects separate environments into a coordinated operating model.
Service models cut across all four. A SaaS application can be consumed from a public cloud, but an organisation may also run internally delivered software in a private cloud-like model. PaaS capabilities may exist in public cloud or be extended into hybrid environments. IaaS is common across public, private and hybrid deployments. Once that separation is clear, cloud discussions become more precise and architecture decisions become easier to defend.
FAQ
What are the four types of cloud computing?
The four cloud deployment models are public cloud, private cloud, community cloud and hybrid cloud. This is separate from service models such as IaaS, PaaS, SaaS and FaaS.
Is multi-cloud one of the four cloud types?
No. Multi-cloud is a strategy that uses services from more than one cloud provider. It can involve public, private or hybrid deployments, but it is not one of the four NIST deployment models.
How do public and private cloud differ?
Public cloud uses provider-operated infrastructure shared across many customers. Private cloud is dedicated to one organisation and is usually chosen when control, compliance or specialised operating requirements are more important.
When does hybrid cloud make sense?
Hybrid cloud makes sense when some workloads benefit from public cloud while others need to remain close to private infrastructure, legacy systems, edge locations or controlled data environments. It requires careful integration across identity, networking, security and operations.
Which cloud deployment model is right for a business?
The answer depends on data sensitivity, residency requirements, latency, compliance scope, budget model and team skills. Public cloud suits many general workloads, private cloud suits strict-control scenarios, community cloud suits shared-governance groups, and hybrid cloud suits mixed constraints.
Making cloud terminology useful
The key takeaway is that “cloud type” should be used carefully. Public, private, community and hybrid describe deployment. IaaS, PaaS, SaaS and FaaS describe service delivery. Multi-cloud describes a provider strategy. Keeping those layers separate prevents poor architecture choices and avoids misleading comparisons.
A practical next step is to classify current and planned workloads against data, latency, compliance, cost and skills constraints before choosing a platform. Teams that want help connecting those decisions to certification and capability planning can contact Readynez for a focused discussion.
