Public vs private cloud: how do you choose?

A public cloud is infrastructure provisioned for open use by many customers and run by a provider. A private cloud is provisioned for exclusive use by a single organization, on its premises or elsewhere. Choose by workload needs: control, regulation, scale and the skills you have to operate it.

What do the standard definitions say?

NIST SP 800-145 defines cloud computing as a model for convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort. It names five essential characteristics, three service models (software, platform and infrastructure as a service) and four deployment models: private, community, public and hybrid.

The deployment model describes who can use the cloud and who runs it. Two points are easy to miss. A private cloud is defined by exclusive use by one organization, not by where it sits: it can be owned and run by the organization, by a third party, or a mix, on or off premises. And a hybrid cloud is a composition of two or more distinct infrastructures that stay separate but are bound together by technology that enables data and application portability.

How do they compare?

Who is responsible for security?

In every model, security is shared. In a public cloud, the provider secures the physical facilities and the underlying service layers, and you secure what you configure and deploy: identities, data, network rules, application code. The more of the stack the provider runs (software as a service rather than infrastructure as a service), the less of it you configure, and the more you rely on the provider's controls.

In a private cloud you own more of the stack, including the platform software, patching and physical security, unless a partner runs it for you. That gives control and also removes the excuse that "the provider handles it".

A common mistake is assuming private means safer. A badly run private platform can be less secure than a well configured public one. The reverse is also true. Isolation helps, but configuration, identity, patching and monitoring decide outcomes.

A constructed example

A hospital group has two workloads. The first is an appointment website with seasonal spikes and no clinical records. It suits a public cloud: capacity grows with demand and the data is low sensitivity. The second is an imaging archive, tens of terabytes with steady access, strict retention rules and a requirement that data stays in the country. The group's lawyers and security team prefer dedicated infrastructure in its own data centre, a private cloud, while keeping the option of copying anonymised data to a public service for analysis later. The result is a hybrid arrangement, chosen workload by workload.

What else should you weigh?

• Regulation and residency. Some rules restrict where data may be stored or who may access it. Read them, and ask the provider where data and backups live.
• Skills. Running a private platform needs people who can operate and secure it round the clock.
• Exit. How hard is it to move out? Check data formats, tooling and contract terms.
• Cost shape. Public cloud costs follow usage and can rise unexpectedly. Private cloud costs are steadier and front loaded.
• Resilience. Consider failure of a single site or region, in either model.

How to check or apply this

1. List workloads with their data sensitivity, demand pattern and legal limits.
2. Mark any workload with a hard constraint that forces a model, such as residency.
3. For the rest, estimate three year cost for both options, including staff time.
4. Write a shared responsibility table for the chosen option, naming an owner for each control.
5. Plan an exit test: restore a workload elsewhere from backup.
6. Review the placement yearly, as needs change.

Quick check

Sources

• NIST SP 800-145, The NIST Definition of Cloud Computing
• NIST SP 800-215, Guide to a Secure Enterprise Network

Last reviewed: 18 October 2026.