Why Cloud Deployment Models Matter
Cloud deployment models define who owns and controls the infrastructure, who can use it, and where it resides. Choosing the wrong model for a given requirement creates security, compliance, or cost problems. A healthcare organisation storing patient records on a shared public cloud without proper controls may violate HIPAA. A startup refusing to use public cloud and building its own private infrastructure wastes capital on hardware instead of product development. The exam tests whether candidates understand the trade-offs well enough to recommend the correct model for a described scenario.
Public Cloud
Public cloud infrastructure is owned, operated, and maintained by a third-party provider — Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), IBM Cloud, and Oracle Cloud are the major providers. Compute, storage, networking, and managed services are delivered over the internet on a pay-as-you-go, on-demand basis. The infrastructure is shared among millions of customers — a concept called multi-tenancy — though each customer's data is logically isolated from others through virtualisation and access controls.
Public cloud advantages: elasticity — scale up and down on demand without hardware procurement lead times; global reach — deploy in data centres across the world in minutes; no capital expenditure — pay only for what you use, no server hardware, no data centre facility costs; managed services — databases, AI/ML, monitoring, and security services operated by the provider reduce operational burden. The primary concern is that you don't control the underlying infrastructure — you trust the provider's security controls and availability SLAs.
Public cloud is appropriate for: development and test environments, workloads with variable demand, startups without capital for infrastructure, global applications requiring geographic distribution, and organisations that prefer operational expense over capital expense.
Private Cloud
A private cloud provides cloud-like capabilities (self-service provisioning, elasticity, resource pooling) on infrastructure dedicated exclusively to one organisation. Private cloud can be: on-premises — hardware owned and operated by the organisation in their own data centre (VMware vSphere, OpenStack, Microsoft Azure Stack); hosted private cloud — dedicated hardware in a third-party data centre but not shared with other customers. The defining characteristic is exclusive use — no other organisation shares the infrastructure.
Private cloud advantages: full control — the organisation manages all aspects of the environment; regulatory compliance — sensitive data stays within controlled boundaries, meeting requirements that prohibit public cloud; customisation — hardware and software can be configured to specific requirements that public cloud standardised offerings don't accommodate; predictable costs — hardware depreciation and operational costs are fixed, not variable. The trade-off is capital cost (hardware purchase), operational overhead (staff to manage it), and limited elasticity compared to public cloud.
Private cloud is appropriate for: regulated industries with data sovereignty requirements (government, defence, some healthcare), organisations with large, stable workloads that justify hardware investment, and environments requiring physical security controls that public cloud cannot guarantee.
Hybrid Cloud
Hybrid cloud combines public and private cloud resources that remain distinct but are connected and can share data and workloads. The defining feature of true hybrid cloud is the ability to move workloads and data between the environments — not just having both environments exist independently. A company running its customer-facing web application on AWS while keeping its SQL database on-premises is hybrid cloud. An organisation bursting computation to AWS during peak periods while keeping base capacity in their private data centre is hybrid cloud with cloud bursting.
Hybrid cloud use cases: keeping sensitive data on private infrastructure while running web tiers on public cloud (compliance + cost balance); disaster recovery using public cloud as the recovery site for on-premises systems; migrating workloads progressively to public cloud while maintaining on-premises during transition; and leveraging public cloud services (AI/ML, big data analytics) that aren't economical to run privately, while keeping operational databases on-premises.
The complexity of hybrid cloud is its management overhead — two or more environments with different tools, security models, and networking configurations. Consistent identity management (single sign-on across both environments), network connectivity (VPN or dedicated links like AWS Direct Connect / Azure ExpressRoute), and unified monitoring are required to operate hybrid environments effectively.
Community Cloud
Community cloud is shared infrastructure used exclusively by a group of organisations with common interests, requirements, or compliance obligations. The community shares costs but not with the general public. Examples: a cloud environment built specifically for US federal government agencies (FedRAMP-authorised, meeting federal security requirements), a healthcare community cloud where member hospitals share infrastructure that meets HIPAA requirements, or a financial services community cloud meeting PCI-DSS and financial regulatory requirements for all member banks.
Community cloud benefits from economies of scale compared to each organisation building its own private cloud, while maintaining the compliance posture and access controls that would be difficult to achieve or verify on a general-purpose public cloud. Community clouds are managed by one of the member organisations, a third-party provider, or a consortium. This is the least common deployment model and the one candidates most frequently confuse with private cloud — the key distinction is that multiple organisations share the community cloud.
Comparison Table
| Model | Who Uses It | Who Owns Hardware | Elasticity | Cost Model | Best For |
|---|---|---|---|---|---|
| Public | Anyone — multi-tenant | Cloud provider | Unlimited | Pay-as-you-go | Variable workloads, cost optimisation |
| Private | One organisation | Organisation or provider | Limited by hardware | CapEx + OpEx | Regulated data, full control |
| Hybrid | One organisation | Both | High — bursting to public | Mixed | Compliance + scalability balance |
| Community | Specific group | Member or provider | Moderate | Shared costs | Shared compliance requirements |
Shared Responsibility Model
The shared responsibility model defines which security controls are the customer's responsibility vs the cloud provider's responsibility — and it varies by deployment model and service model. In public cloud IaaS (renting virtual machines): the provider secures the physical infrastructure, hypervisor, and network; the customer is responsible for the OS, applications, data, and network configuration within their VMs. In public cloud PaaS (using a managed database service): the provider also manages the OS and database engine; the customer is responsible for data and application configuration. In SaaS (using Office 365 or Salesforce): the provider manages everything from infrastructure through the application; the customer is responsible for user account management, data governance, and access controls.
In a private cloud, the organisation is responsible for the entire stack — physical infrastructure, hypervisor, OS, application, and data. There is no provider to share responsibility with. In a hybrid cloud, the shared responsibility model applies differently to the public and private components. This model is a Security+ exam topic, and the exam tests whether candidates understand that "moving to the cloud" doesn't transfer all security responsibility to the provider — the customer always retains responsibility for their data and access controls regardless of deployment model.
Cloud Service Models — IaaS, PaaS, SaaS
Cloud deployment models (public/private/hybrid/community) describe who uses the infrastructure. Cloud service models describe what the provider delivers. IaaS (Infrastructure as a Service) — virtual machines, storage, and networking; the customer manages OS and above. PaaS (Platform as a Service) — managed runtime environment (managed databases, serverless compute, container platforms); the customer manages applications and data. SaaS (Software as a Service) — complete applications delivered over the internet (email, CRM, productivity suites); the customer manages only data and user access. These service models can be deployed in any of the four deployment models — a private cloud can offer IaaS, PaaS, or SaaS to internal teams; a community cloud can deliver SaaS to member organisations.