The three deployment models are usually compared on price, which is the dimension where the comparison is least reliable. What actually differs is who operates the platform, where the data sits, how quickly capacity can change, and what shape the cost takes on a balance sheet.
This page compares them on those terms. The architectural detail of combining them is in Hybrid Cloud Architecture Explained.
The definitions are settled, and worth using
NIST defines cloud computing as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction, and names five essential characteristics including On-demand self-service, Rapid elasticity and Measured service. See NIST SP 800-145, The NIST Definition of Cloud Computing.
Those characteristics are the test. An environment without self-service provisioning, elasticity and metering is virtualized infrastructure, which may be entirely appropriate and is not a private cloud. Being clear about that avoids a common procurement confusion in which two bidders describe very different things using the same word.
Public cloud
Infrastructure operated by a provider and shared among many tenants, consumed on demand and billed by usage. The provider owns and operates the facility, the hardware, the hypervisor and the platform services above them.
What you gain is elasticity, breadth of managed services, geographic reach and no capital commitment. What you give up is control over the platform, visibility below your own layer, and a degree of predictability in cost. The major platforms are covered in AWS Managed Services and Microsoft Azure Managed Services.
Private cloud
Infrastructure provisioned for a single organization, whether it sits in that organization's own facility, in leased colocation space, or is operated by a third party. The defining property is single tenancy, not physical location, which is a distinction procurement documents frequently get wrong.
What you gain is control over hardware, placement, data location and the change schedule, plus predictable cost for steady workloads. What you give up is elasticity beyond what you bought, and the effort of operating the platform yourself. Private Cloud and Data Center Services covers this in depth.
Hybrid
A composition of two or more distinct infrastructures that remain separate entities but are bound together well enough to move data and workloads between them. It is the model most large organizations arrive at, generally by accumulation rather than by design.
What you gain is the ability to place each workload where it belongs. What you give up is simplicity: two operating models, two sets of tooling, a connectivity dependency between them, and a boundary that has to be managed deliberately.
Cost is a shape, not a number
The comparison usually offered is capital expenditure against operating expenditure, which is real and is not the interesting part. The interesting part is how cost responds to change.
Private infrastructure costs roughly the same whether it is busy or idle: you bought the capacity and you own it. Public cloud costs track usage, which is efficient for variable demand and considerably more expensive for a steady load that runs continuously. The crossover is not a rule of thumb; it depends on the workload's shape, and calculating it for the actual workload is the only way to know. Cloud Cost Optimization and FinOps covers the arithmetic.
Elasticity is the genuine discriminator
Everything else in this comparison is a trade-off with arguments on both sides. Elasticity is not: a public platform can give you a large amount of capacity in minutes and take it away again, and private infrastructure cannot.
How much that matters depends entirely on demand. A workload with a ten-to-one daily variation, a seasonal peak or an unpredictable launch is expensive to serve privately, because the capacity has to be bought for the peak and sits idle the rest of the time. A workload that runs flat has nothing to gain.
Control cuts both ways
Private infrastructure lets you choose the hardware, know the neighbours, schedule the maintenance and keep an operating system version longer than a provider would prefer. That is valuable for workloads with unusual requirements and for organizations with obligations about physical placement.
It also means every one of those decisions is yours, including the ones a public provider would have made competently without telling you. Organizations that want control frequently want it in one specific respect and inherit it in every respect.
Data location is often the deciding constraint
For many public-sector and regulated organizations the question is not cost or elasticity but where data physically resides, who can access it, and under what jurisdiction. That constraint can be satisfied in several ways, including sovereign regions of public platforms, and it eliminates some options outright.
When it applies, it should be established first, because it narrows the field before any other comparison is worth running. Government and Public-Sector Cloud Infrastructure covers the specifics.
The security comparison is not what it was
The assumption that private is more secure than public no longer survives contact with the evidence. Major public platforms invest in physical and platform security at a scale almost no individual organization matches, and most cloud incidents are customer misconfiguration rather than provider compromise.
What does change is the division of labour. NIST's synopsis makes the underlying point that cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources, and the word doing the work is shared. See NIST SP 800-146, Cloud Computing Synopsis and Recommendations. Which controls remain yours is set out in Cloud Security and Shared Responsibility.
Performance, and the workloads that still prefer metal
Public platforms serve the overwhelming majority of workloads without a performance argument. The exceptions are real and narrow: sustained high-throughput storage, workloads sensitive to latency variation from shared tenancy, and applications licensed per physical core where the licensing dominates the infrastructure cost.
Those cases deserve measurement rather than assumption. The belief that a workload needs dedicated hardware outlives the measurement that established it by several hardware generations.
Operational effort moves rather than disappears
Public cloud removes facility, hardware and hypervisor work. It adds identity and permissions design, cost management, service selection, quota management and keeping up with a platform that changes weekly.
Teams that plan for the removal and not the addition end up understaffed in a new way. The net effect is usually favourable, and it is not the elimination of operations that business cases sometimes describe.
Community cloud, and why it rarely appears
The definitions name a fourth model: infrastructure provisioned for exclusive use by a specific community of organizations with shared concerns, such as a common mission or compliance regime. It is the least used of the four and the most often misdescribed.
In practice the requirement it was meant to serve is now usually met by a dedicated region or partition of a public platform, which offers the same restricted tenancy and jurisdictional separation without any member organization operating the facility. The model has not disappeared so much as been absorbed, and a proposal describing something as a community cloud is worth reading carefully to see which of the two it means.
Lock-in is a spectrum, and worth pricing
Virtual machines and block storage move between platforms with effort. Managed databases, serverless functions, proprietary data services and platform-specific identity do not, and the deeper the integration the greater the benefit and the higher the exit cost.
The useful question is not how to avoid lock-in but how much of it is being bought and whether the productivity gain justifies it. Refusing every managed service to stay portable means operating everything yourself, which is a real cost paid now against a hypothetical migration later.
How the decision is usually made in practice
Workload by workload, not estate by estate. A regulated dataset with a location requirement goes private. A customer-facing service with variable demand goes public. A stable internal system that runs continuously stays where the economics favour it. A system with an unmovable dependency stays put until the dependency changes.
That produces hybrid as an outcome rather than as a choice, which is the honest description of how most estates got there. Hybrid Cloud Infrastructure covers operating the result.
What LABUSA operates, and why it says so
LABUSA operates private infrastructure in leased, secured colocation space in the Houston area, and a hybrid architecture using Amazon Web Services, AWS GovCloud (US) and Microsoft Azure. Both models are in daily use, which is the reason this comparison is written from the middle rather than from one side of it.
The approach to a placement decision is boundary-first: establish the constraints that eliminate options, then compare what remains on cost shape, elasticity and operational effort for that specific workload. The capability behind this comparison describes how that assessment runs.