Definition of cloud: the NIST model explained

A simple definition of cloud is computing capacity and software that people use through a network, rather than running everything on their own device. The resources can include servers, storage, databases, applications, and processing power. Here, “cloud” refers to computing.

The formal definition goes further: cloud computing supplies configurable resources from a shared pool, with ways to request, change, release, and measure them. A remote computer alone does not establish that operating model.

That distinction is useful when a provider calls its service “cloud.” This guide explains the NIST definition, the five characteristics behind it, and the questions that turn a familiar label into something you can evaluate.

A simple definition of cloud

From the user's perspective, the cloud is a way to obtain computing services over a network. An application may keep shared records on remote storage, a developer may request a virtual machine, or a team may use an online accounting application. The local device still runs an interface and may also perform substantial processing.

“The cloud” often refers to the services and environment being used. “Cloud computing” emphasizes how those resources are provided and managed. Everyday usage overlaps, so there is no rigid boundary between the two expressions.

The name comes from a drawing convention: a cloud shape can stand for a network without showing all its internal equipment. Cloudflare explains this network-diagram metaphor. The abstraction makes diagrams easier to read; the actual service still needs processors, storage, networking, power, and cooling.

The formal definition of cloud computing

The NIST Definition of Cloud Computing, SP 800-145, describes a model in which consumers obtain configurable computing resources through a network on demand. Those resources come from a shared pool and can be allocated and released quickly, with little manual intervention by the provider.

NIST identifies five essential characteristics, three service models, and four deployment models. Together they provide a vocabulary for comparing services. They do not certify a provider's security, reliability, pricing, or suitability for your work.

The definition concerns behavior. Who can request capacity? How does the system assign it? Can that capacity change? What is measured? A service's website, subscription plan, or use of the word “cloud” does not answer these questions.

The five essential characteristics of cloud computing

1. On-demand self-service

Consumers can obtain computing capabilities without a member of the provider's staff handling every routine request. For example, an authorized developer can create a test server through a dashboard or API and remove it when testing ends.

Self-service can coexist with account checks, budgets, quotas, and internal approval. The useful distinction is whether ordinary provisioning happens through an automated service or requires the provider to process each request manually.

For a software service, the user may manage accounts and application settings rather than individual servers. Evaluate self-service at the level of the capability the service actually supplies.

2. Broad network access

Resources are available over a network through supported access mechanisms. These can include browsers, applications, APIs, and command-line tools used from different client platforms.

“Broad” does not mean anonymous, unrestricted, or compatible with every device. Authentication, permissions, network rules, software requirements, and organizational policies still apply. A cloud environment can use a private network or dedicated connection without being exposed to the public internet.

3. Resource pooling

The provider groups resources so that capacity can be assigned and reassigned as consumers' needs change. The pool can contain physical and virtual resources, including processing, memory, storage, and network capacity.

Multiple consumers need not mean unrelated companies. A private cloud can pool resources across departments in one organization. Isolation between workloads remains necessary even when their underlying resources belong to a common pool.

A customer may select a region or a dedicated-host option without choosing every physical component. Check the service's actual allocation and isolation rules; sharing a resource pool does not mean sharing access to another customer's files.

4. Rapid elasticity

Capacity can grow and shrink with demand, sometimes automatically. An application might add worker instances while a queue is busy, then release them when the queue clears. Elasticity includes reducing capacity, not just expanding it.

Scalability describes a system's ability to handle a changed amount of work. Elasticity concerns adjusting resources as that demand changes. Neither property removes limits in the application, account, network, or provider's available capacity.

For a concrete example, Amazon EC2 documents regional service quotas that can prevent an instance request from succeeding. A cloud label is therefore no promise of unlimited or immediately available resources.

5. Measured service

The system meters resource use at a level appropriate to the service and makes that use available for monitoring, control, and reporting. A measurement might concern storage, processing time, transferred data, or active user accounts.

Measurement and pricing are separate questions. A provider can measure consumption while charging a subscription, a tiered plan, or a committed amount. Conversely, charging by the hour does not by itself establish the other cloud characteristics.

Ask which events start and stop a charge, which resources remain after a workload ends, and which measurements you can inspect. A usage chart is useful only when its units and scope are clear.

How cloud computing works

Consider a developer requesting a temporary application environment. The exact implementation varies, but this sequence connects the service interface to the equipment underneath it:

1. The developer makes a request. A dashboard, API, command-line tool, or automated deployment describes the required environment.
2. The platform checks access and limits. Identity, permissions, policy, quotas, and availability determine whether the request can proceed.
3. Management software assigns resources. The platform selects suitable computing, storage, and networking capacity and applies the requested configuration.
4. Physical equipment performs the work. Processors execute instructions, memory holds working data, storage retains information, and networks carry traffic.
5. The application becomes reachable. Users interact through the permitted network path. Their devices still handle local software, input, and display.
6. The platform measures and manages the environment. Resources can be monitored, changed, or released. Retained storage and other services may need separate cleanup.

Opening an existing application does not necessarily create a new server each time. Provisioning an environment and using an already running service are different operations.

The layers commonly include physical infrastructure, software that allocates resources, platform services, and applications. Identity, monitoring, billing, and management tools operate across those layers. This is a useful description, not a requirement that every provider build an identical stack.

Cloud service models: what does the provider manage?

Infrastructure as a service (IaaS) supplies fundamental resources such as compute, storage, and networking. The customer can install and manage operating systems and applications within the service's limits. A team running its own application on a virtual machine has more operational responsibility than a team using a finished application.

Platform as a service (PaaS) supplies an environment for deploying applications using supported tools and runtimes. The customer manages code, application behavior, configuration, and data while the provider manages more of the underlying platform. Google Cloud's PaaS explanation describes this division between application development and platform operation.

Software as a service (SaaS) supplies a provider-operated application. Webmail, accounting, and shared-document services can fit this model. Customers still manage access, settings, data, and their use of the application. A browser interface or subscription alone does not establish that an application follows the cloud model.

Serverless is a later industry category, rather than a fourth original NIST service model. It generally means the developer uses a service without provisioning and continuously managing individual servers. Function as a service is one approach: events trigger code that runs in provider-managed environments. AWS Lambda's documentation gives a concrete example. Servers still exist, and permissions, code, dependencies, and service limits still need attention.

Cloud deployment models: who can use the environment?

Public cloud is made available for use by the general public through a provider. Customer resources normally have access controls; “public” does not mean that stored documents or databases are publicly readable.

Private cloud is for one organization's exclusive use. That organization, a third party, or a combination can own and operate it, on or off premises. Exclusive use does not prove stronger security or require ownership of every building and server.

Community cloud serves a defined group of organizations with shared concerns, such as a mission or security requirements. Hybrid cloud, in NIST's taxonomy, connects two or more distinct cloud environments while allowing data or applications to move between them. Simply having office computers and an online subscription does not establish that integration.

Multicloud means using more than one cloud provider. It is a common industry term, not one of NIST's four original deployment models. A setup can be both hybrid and multicloud, but neither label demonstrates that failover, identity management, or migration works.

These classifications answer different questions. A private cloud can supply infrastructure or application services. A public cloud can offer several service models. Geography and the physical distribution of hardware add further design choices.

What is not automatically cloud computing?

The internet: this is a system of interconnected networks. Cloud services can use it, but a network connection is not itself a pool of managed computing resources. Private connectivity can also carry cloud traffic.

A data center: this is a facility containing computing equipment and supporting systems. It may host a cloud platform, dedicated servers, or conventional applications. Our guide to where cloud data is physically stored separates facilities, regions, servers, and copies of data.

A remote server or hosting account: remote access does not tell you how capacity is provisioned, pooled, adjusted, or measured. Hosting can use cloud infrastructure, but a provider's label and a fixed monthly bill are insufficient evidence either way.

Virtualization: running virtual machines on a physical host can help allocate resources. It does not by itself provide the self-service, elasticity, or measurement of a cloud platform. Containers and bare-metal resources can also participate in cloud services.

Cloud storage: this is one category of service, rather than a synonym for all cloud computing. Compute, applications, databases, and managed processing are other uses. Storage also does not automatically provide a recoverable backup; synchronization and backup solve different problems.

Apply the definition to three examples

A remotely accessed office computer. A worker signs into a fixed machine over a network. That establishes remote access. Without evidence of the other characteristics, it is insufficient to call the arrangement a cloud service.

An internal development platform. Teams request environments through a portal, draw from pooled capacity, resize resources, and receive usage reports. This illustrates cloud behavior even if the equipment serves only one organization and uses a private network.

A managed application. An organization uses a provider-operated application with centrally managed accounts and configurable access. The provider handles the underlying resource allocation. Users do not need a virtual-machine dashboard for the service to be SaaS, but the provider's delivery model still matters.

AI workloads follow the same logic. Running a model on a rented GPU instance places more responsibility on the customer than using a managed inference endpoint. “AI” describes the workload; it does not establish a service or deployment model by itself.

Benefits and trade-offs are separate from the definition

Cloud services can shorten the path from a request to a usable environment, reduce local hardware procurement, and give teams access to managed software. Whether those changes help depends on the workload and the responsibilities transferred to the provider. Our guide to cloud computing benefits examines the practical conditions.

Cost: compare the whole arrangement, including retained storage, data movement, support, commitments, licenses, and the staff time needed to operate it. A low instance price does not establish a low total cost. Cloud also does not eliminate every hardware purchase or infrastructure expense.

Availability: consider the service, your network connection, and dependencies such as identity or name resolution. Replication and failover must be designed and tested. The definition makes no uptime guarantee, and scaling capacity does not automatically repair an application failure.

Control and location: establish where processing and data can occur, including backups and supporting services. A chosen region does not answer every question about access, retention, or contractual obligations. Review the relevant service documentation and agreement.

Exit: check export formats, APIs, data volume, transfer time, and dependencies on managed features. Using several providers does not automatically make an application portable. Test a small export and restore before migration becomes urgent.

How cloud security responsibility is divided

Moving a workload changes who operates each layer. The provider may manage facilities, hardware, and parts of the platform or application. The customer still needs to manage the controls available to them.

Microsoft's shared-responsibility guidance illustrates how the division changes across IaaS, PaaS, and SaaS. Data, accounts, permissions, configuration, and client-device protection remain important customer concerns. An infrastructure customer also manages more operating-system and application security.

For each workload, write down who patches, monitors, revokes access, restores data, and responds to incidents. Verify that division against the actual service. A cloud classification does not demonstrate that those tasks are covered or that the service meets your requirements.

Does the cloud have to be centralized?

The definition does not prescribe one geographic layout. Resources can sit in large regional facilities, organizational sites, or infrastructure distributed across multiple locations. The important questions concern how they are supplied and managed.

Distributed infrastructure is not automatically decentralized governance, peer-to-peer networking, multicloud, or edge computing. Those terms describe different properties. Distribution can affect latency, placement, and failure handling, but its benefits depend on the actual design and operating conditions.

Hivenet's current architecture overview describes product-specific paths for compute, managed inference, storage, and file transfer. Compute with Hivenet and a managed inference endpoint expose different levels of control. The architecture page also makes clear that every Hivenet product does not use an identical system.

The same evaluation applies: inspect the service's access, allocation, limits, measurement, responsibilities, and exit options. Distribution alone is no guarantee of security, resilience, or environmental performance.

Questions to ask before choosing a cloud service

• Provisioning: What can an authorized user create or change directly, and which operations require support or approval?
• Capacity: How does scaling work, what are the quotas, and what happens if capacity is unavailable?
• Pooling and isolation: Which resources are shared or dedicated, and what boundaries protect workloads and data?
• Measurement and cost: Which units are metered, how do they become charges, and what continues to cost money after a job stops?
• Responsibility: Who manages each layer, including access, updates, monitoring, backup, and incident response?
• Location and recovery: Where can data and processing occur, and how are restoration and outage procedures tested?
• Exit: What can be exported, in which formats, at what cost, and which parts would need rebuilding elsewhere?

Request evidence for the answers: documentation, a configuration example, a usage report, or a small test. That makes the cloud computing definition useful in a real decision.

Frequently asked questions

Is the cloud just someone else's computer?

That phrase points to physical equipment behind a service, but leaves out the operating model. Cloud computing also involves self-service, pooled resources, network access, elasticity, and measurement. An organization can operate a private cloud on infrastructure it owns.

Does cloud computing always use the internet?

It requires network access, which can include private networks and dedicated connections. Access over the public internet is common, but public exposure is not a defining requirement.

Does measured service mean you only pay for what you use?

No. Usage can be measured within subscriptions, tiers, reservations, or minimum commitments. Check the billing rules as well as the usage measurements.

Does meeting the definition mean a service is good?

No. It establishes characteristics of the delivery model. Performance, recovery, security, cost, and the ability to leave require their own evidence.