What Is Cloud Computing and Edge AI, Using the NIST Words

What is cloud computing and edge AI, on this page, means two public definitions and a refusal to invent a third. Cloud computing is the model in NIST Special Publication 800-145. Edge, in a later NIST conceptual model, is a network layer of end devices, not a product named edge AI. This page is not a deployment guide, not a purchasing recommendation, and not advice about a medical, legal, or hiring decision.

If you are fitting a small model on a table you already have, start with how to make an AI model for beginners. This page only fixes the vocabulary.

What is cloud computing and edge AI doing in one title

The two ideas are easy to mash together because both get used in sales pages about running a model closer to the data. NIST did not publish them as one phrase. SP 800-145, by Peter Mell and Timothy Grance, September 2011, defines cloud computing. SP 500-325, March 2018, defines a fog computing conceptual model and, in Annex A, says what that document means by edge computing. What is cloud computing and edge AI should be read as: here is the cloud definition, here is the edge definition, and edge AI is not a term either document defines.

SP 800-145 says its definition is meant as a baseline for discussion, from what cloud computing is to how to use it, and that the service and deployment models are a simple taxonomy not intended to prescribe or constrain a method of deployment, service delivery, or business operation. Treat this page the same way. Naming a characteristic is not a design.

The cloud model, in the publication’s own list

The definition says cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications, and services, that can be rapidly provisioned and released with minimal management effort or service provider interaction. The same paragraph says the model is composed of five essential characteristics, three service models, and four deployment models.

The five characteristics, in the publication’s names, are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. On-demand self-service means a consumer can provision capabilities such as server time and network storage without human interaction with each provider. Broad network access means capabilities are available over the network through standard mechanisms. Resource pooling means the provider’s resources are pooled for multiple consumers, with physical and virtual resources assigned and reassigned, and the customer generally does not control the exact location. Rapid elasticity means capabilities can be provisioned and released to scale with demand. Measured service means usage is metered, monitored, controlled, and reported. The publication’s footnote says metering is typically pay-per-use or charge-per-use. That is the publication’s typically, not a price.

The three service models are software as a service, platform as a service, and infrastructure as a service. In software as a service, the consumer uses the provider’s applications and does not manage the underlying infrastructure. In platform as a service, the consumer deploys applications onto the provider’s stack and still does not manage the underlying infrastructure, but does control the deployed applications. In infrastructure as a service, the consumer provisions processing, storage, and networks and can run arbitrary software, including operating systems, without managing the underlying cloud infrastructure. The publication defines a cloud infrastructure, in a footnote, as the hardware and software that enables the five characteristics, with a physical layer and an abstraction layer.

The four deployment models are private, community, public, and hybrid. Private is for one organization. Community is for a group of organizations with a shared concern. Public is for open use by the general public and exists on the provider’s premises. Hybrid is a composition of two or more distinct infrastructures that stay unique but are bound so data and applications can move. The publication gives cloud bursting for load balancing as an example of that binding. It does not rank them.

Edge, in the later conceptual model, is not fog

SP 500-325 is about fog computing for systems that also use cloud computing. It describes fog computing as a layered model for access to a shared continuum of computing resources, with fog nodes, physical or virtual, between smart end-devices and centralized cloud services. It says fog is not a mandatory layer, and a centralized cloud is not required for a fog layer to support end devices. Different use cases can use different architectures. That is a conceptual model. It is not a wiring diagram.

Annex A of that publication is the part that answers the edge half of the question. It says, for the purpose of that document, edge computing is the network layer encompassing the end devices and their users, to provide local computing capability on a sensor, meter, or other network-accessible device. It says this peripheral layer is also often called an IoT network. It then says fog computing is often confused with edge computing, and it lists differences: fog runs applications in a multi-layer architecture, while edge runs specific applications in a fixed logic location; fog is hierarchical, while edge tends to be limited to a small number of peripheral devices. The annex cites another white paper for the comparison. If you need the comparison’s wording, read the annex rather than a paraphrase that adds a vendor.

After those two publications, the page is still not a claim that a model runs on a sensor. Neither document defines an edge AI product, a chip, or a latency budget. If a page uses the keyphrase to mean a model on the device, that meaning is the page’s, not NIST’s. Say which document you are quoting.

What not to add

Do not add a count of devices, a latency figure, or a cost. SP 500-325’s introduction mentions an estimate from an outside source. This page leaves that estimate in that source. A definition does not become a forecast because a footnote points at a forecast.

Do not treat the five characteristics as a checklist that makes a service count as cloud for a contract. SP 800-145 says it was prepared for federal agencies, may be used by others voluntarily, and should not be taken to contradict mandatory standards. It is not legal advice, and this summary is not legal advice either.

Do not describe a bypass, a jailbreak, or a way to move data off a device against its policy. The definitions are about where computation is described as sitting. They are not permission.

Tomorrow, open SP 800-145 and write the five characteristics and three service models in your own words, with the link. Then open Annex A of SP 500-325 and write one sentence on what that annex calls edge computing, and one sentence on how it separates edge from fog. If a sentence names a product or a number you did not read, delete it. What is cloud computing and edge AI is done when those two links are the only authorities on the page.

Keep the two publications separate in the notes. Cloud is the 2011 definition. Fog and the annex’s edge wording are the 2018 conceptual model. Mixing them into one slogan hides which sentence came from which document. A reader should be able to check you without guessing.

If someone asks where the model runs, answer with the layer you actually mean: a centralized pool as SP 800-145 describes cloud, a fog node as SP 500-325 describes fog, or the end device as Annex A describes edge. If you cannot point at one of those, you do not have an answer yet. The phrase edge AI does not fill that gap.

Write the audience the way SP 800-145 does. That publication says it is for system planners, program managers, technologists, and others adopting cloud computing as consumers or providers. SP 500-325 says its audience is planners, architects, engineers, managers, and networking specialists who consume or provide IoT solutions that use cloud or fog services. If you are none of those, you can still read the definitions. You should not turn them into a build plan.

When you cite them, cite the DOI, not a slide that cropped the sentence. The cloud DOI is 10.6028/NIST.SP.800-145. The fog DOI is 10.6028/NIST.SP.500-325. A slide that says edge AI and then quotes only the word edge is not a citation.