Public and Private Clouds

Who owns the hardware you're using

A hospital network wants to run its patient portal on infrastructure it can scale up during flu season and scale back down in summer. Its compliance officer also insists that patient records never leave hardware the hospital itself controls: no shared servers, no unknown neighbor's workload running next to it. Three blocks away, a 3-person startup wants the opposite: no data center, no IT staff, and a product ready to launch in 6 weeks.

Both teams want cloud characteristics, on-demand self-service, elastic scale, but they cannot get them from the same infrastructure. That difference, who owns the hardware and who else is allowed to share it, is what a cloud deployment model describes. This lesson covers the 3 models NIST defines around exclusivity: public, private, and community cloud. The next lesson covers what happens when you combine them.

Public cloud: one provider, many tenants

In a public cloud, an external provider such as AWS, Microsoft Azure, or Google Cloud owns and operates the hardware, then sells access to it as a service to anyone willing to pay. NIST's definition is blunt about the audience: the infrastructure is "provisioned for open use by the general public." You do not own a single server. You rent capacity, a virtual machine, a storage bucket, a managed database, from a shared pool that thousands of other customers also draw from, and the provider's software keeps every customer's data and workload isolated from the others.

That shared pool is exactly what makes public cloud economical. Because the provider spreads the cost of its data centers across every customer, you get the scale, service variety, and pay-as-you-go pricing that made the 3-person startup's 6-week launch possible in the first place. AWS puts the tradeoff plainly in its own guidance: for nearly every use case, public cloud wins on cost, breadth of services, and how fast you can start, precisely because you are not paying to build or run any of the infrastructure yourself.

Private cloud: one organization, dedicated hardware

A private cloud flips the ownership. NIST defines it as infrastructure "provisioned for exclusive use by a single organization." That organization, not a public provider, controls who touches the hardware, where it physically sits, and how it is secured, which is exactly what the hospital's compliance officer was asking for.

Here is the boundary that trips people up: owning virtualized on-premises servers does not automatically make them a private cloud. A real cloud still has to clear all 5 NIST characteristics from the previous topic, and on-demand self-service is one of them. A data center where developers file a ticket and wait 2 days for a new virtual machine is not a private cloud. It is traditional IT wearing a hypervisor. A setup only earns the name "private cloud" once it also lets its own users self-provision resources on demand, the same instant, no-approval experience a public cloud gives you, just restricted to one organization instead of the general public.

Even when it clears that bar, AWS's own comparison is candid about what a private cloud gives up: a single organization can rarely match the breadth of services, the pace of new features, or the economies of scale that a public provider spreads across millions of customers. Building your own version of a service like Amazon S3 gets you an S3-shaped bill, not S3 itself. That is why AWS argues private cloud fits a narrow case: very large organizations that already run their own data centers and have the infrastructure staff to operate them, not the default choice for most teams.

Community cloud: shared by, not sold to

NIST names a third exclusive model that gets far less attention: community cloud, infrastructure "provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns," things like a common mission, security requirement, or compliance obligation. Unlike a public cloud, strangers cannot sign up. Unlike a private cloud, more than one organization shares it, as long as each belongs to the same vetted community.

You rarely meet a textbook community cloud in the wild, but government cloud regions come closest in practice: isolated environments built specifically for government agencies and their vetted contractors, who share the same compliance and security bar rather than being open to the general public. That is a useful real-world anchor for the definition, even though the more textbook case, research consortia or industry groups with a shared compliance need, stays niche.

Comparing the 3 models

Choosing between them

Go back to the hospital and the startup. The startup has no compliance blocker and nothing of its own to protect, so public cloud is the obvious fit: no upfront cost, and elastic capacity from day one. The hospital's constraint is not cost or speed; it is that patient records cannot sit on hardware it does not control. A private cloud, expensive as it is to build and staff, is the model that satisfies that one non-negotiable requirement.

Watch for the same signal in any scenario you read. Phrases like "dedicated," "hardware we control," or a compliance rule that forbids shared infrastructure point at private cloud. Phrases like "pay only for what you use," "no upfront investment," or "launch quickly with no infrastructure to manage" point at public cloud. "Shared by multiple organizations with the same compliance requirement" is the community cloud signal, and it shows up rarely enough that when it does, it is almost always the deliberate answer, not a distractor.

Where this leaves you

The question that separates these 3 models is always the same: who owns the hardware, and who else is allowed to share it. Public cloud answers "a provider, and anyone who pays." Private cloud answers "one organization, no one else, and only if self-service is actually part of the deal." Community cloud answers "a vetted group, and only that group." Real deployments rarely stop at picking one. The next lesson covers what happens when an organization combines them, connecting private infrastructure to a public cloud, or spreading workloads across more than one public provider, and why those 2 combinations are not the same thing.