What Is Cloud Computing?

A definition that has to do real work

"The cloud" gets used so loosely that it can mean almost anything: a file synced to a phone, a website hosted somewhere else, an email account you did not have to install software for. That looseness is a problem the moment you need to tell whether a specific service actually is cloud computing, or just something running on someone else's server. You need a definition precise enough to test a service against, not just a feeling.

The definition the industry actually uses comes from the U.S. National Institute of Standards and Technology (NIST), published in Special Publication 800-145. It is vendor-neutral: NIST does not sell cloud services, so its definition describes the model itself rather than any one provider's marketing.

The NIST definition, phrase by phrase

Here is the full definition:

"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

That is a dense sentence, so unpack it piece by piece.

"Ubiquitous, convenient, on-demand network access" means you reach the service over a network, almost always the internet, from ordinary devices, whenever you want, without arranging access in advance.

"A shared pool of configurable computing resources" means many customers draw from the same underlying hardware, servers, storage, networking, rather than each customer owning a dedicated machine. "Configurable" matters here: you are not just handed a fixed slice, you can shape what you get to fit your needs.

"Rapidly provisioned and released" means capacity appears when you ask for it and disappears when you are done with it, on the order of minutes, not the weeks you saw in the previous lesson.

"With minimal management effort or service provider interaction" means you do not file a request and wait for a human at the provider to act on it. You configure it yourself, through a console, an API, or a command line.

The shape of the full model

NIST's definition is really the headline for a larger model with 3 parts, each covered in its own place in this course:

• 5 essential characteristics, the specific, testable traits every real cloud service has to exhibit. The next lesson walks through all 5 in depth.
• 3 service models, IaaS, PaaS, and SaaS, which describe how much of the technology stack the provider manages for you versus how much you manage yourself. You will cover these in the Cloud Service Models topic later in this course.
• 4 deployment models, public, private, community, and hybrid, which describe who the infrastructure is shared with. You will cover these in the next topic, Cloud Deployment Models.

You do not need to memorize those lists yet. What matters here is the shape: a cloud service is defined by characteristics it must have, not by a single technology or a single company.

The boundary that trips people up

Here is the misconception worth naming directly: a server you did not buy is not automatically "cloud." A traditional web host that racks a physical server for you, gives you SSH access, and requires you to email support and wait a day whenever you want more RAM is not cloud computing, even though it is remote and even though someone else owns the hardware. It fails the definition on "on-demand" and "minimal service provider interaction," because a human has to act before you get more capacity.

Contrast that with a service where you open a console, request more capacity, and have it within minutes, with no email, no ticket, no wait. That gap, self-service versus request-and-wait, is the practical test you can apply to almost any service someone calls "cloud" to check whether it actually earns the label.

Carrying this forward

You now have the test: a real cloud service is on-demand, self-service, network-accessible, drawn from a shared and elastic resource pool, and billed for what you actually use. The next lesson slows down on each of those 5 traits individually, because they are exactly what a genuine architecture decision, or an exam question, will ask you to recognize.