XenonStack Blog Fog vs Edge vs Cloud Computing: Key Differences

Cloud, fog and edge computing differ mainly in where data is processed. Edge computing runs on or beside the device that creates the data. Fog computing adds a shared, layered tier of nodes on the local network between those devices and the cloud. Cloud computing runs in central data centres with the most capacity and the longest path to the device.

Many enterprise architectures now combine all three: the edge for millisecond decisions, the fog tier for site-wide aggregation, control and resilience, and the cloud for training, fleet management and long-term analytics. This comparison explains where each tier fits, what the standards say and when a fog layer is not worth adding.

This post focuses on the three-tier comparison. For edge AI types and use cases, see our guide to the intelligent edge and edge AI. To choose a product for each tier, see the edge computing platform guide, and for the two-way view, edge computing vs cloud computing.

What is the difference between edge, fog and cloud computing?

The quickest way to compare the three is by where the work runs, what each tier is good at and what limits it.

What do the standards say about fog computing?

Two reference documents still define the term. NIST SP 500-325, Fog Computing Conceptual Model (March 2018) describes fog computing as a layered model that gives access to a shared continuum of scalable computing resources, with fog nodes placed between smart end devices and centralised cloud services. It also defines mist computing as a lightweight form of fog computing closest to the devices, running on microcontrollers and microcomputers.

In August 2018 IEEE adopted the OpenFog Reference Architecture as IEEE 1934-2018, which describes moving compute, storage, control and networking functions closer to users along the path from the cloud to connected devices.

How does fog computing differ from edge computing in practice?

NIST's annex on the two terms says edge computing runs specific applications in a fixed logical location and gives a direct transmission service, while fog computing is hierarchical, multi-layered and also covers storage, control and data processing acceleration. In practice the difference shows up in five places.

Many teams now call the fog tier the "near edge" or "on-site edge". The label matters less than being clear about which decisions run on the device, which run on shared site infrastructure and which wait for the cloud. Our post on edge data management covers how data is filtered and governed across those tiers.

When does each tier fit?

Use the decision rules below as a starting point. Most real systems place different steps of the same workflow in different tiers.

Real-time video analytics is a good example of the split: inference runs close to the cameras, the site tier builds one operational picture, and the cloud keeps history and retrains models.

Video: Real-time video analytics, where camera feeds are processed near the site and combined into one live operations picture.

What has changed since fog computing was first defined?

The concept has held up, but the products that deliver it have changed. The table shows the current status of the main options, checked against vendor and standards pages in November 2026.

The other change is the workload. Fog and edge tiers increasingly run AI inference and AI agents rather than simple rules, which raises the stakes on governance. Our guide to 5G edge computing architecture covers the network edge in more depth.

How should you handle governance, security and cost across the three tiers?

• Security: every edge device and fog node is a place to patch, harden and monitor. Use signed images, device identity and a single fleet control plane rather than per-site tooling.

• Data residency: keep raw personal or sensitive data at the edge or fog tier and send only results or anonymised events to the cloud.

• Decision accountability: when an AI model or agent acts locally, record what it saw, which policy applied and what it did, so the action can be reviewed later.

• Cost: fog nodes cut bandwidth and cloud processing, but add hardware, power, spares and field support. Compare the full site cost, not only cloud spend.

• Resilience: decide what each site must keep doing when disconnected, and for how long, before you size the fog tier.

For local AI decisions, AgentGRC keeps autonomous agent actions inside policy, with the audit trail risk teams need.

How should an enterprise adopt a cloud, fog and edge design?

1. List the decisions the system must make and the response time each one needs.

2. Place each decision in a tier using the rules above: edge for millisecond actions, fog for site-wide context and resilience, cloud for learning and oversight.

3. Decide which data never leaves the site, which leaves as events and which is copied in full.

4. Choose one control plane for deploying, updating and monitoring every tier.

5. Pilot on one site with a clear success measure, such as response time, bandwidth saved or uptime during outages.

6. Add security, logging and rollback before expanding to more sites.

7. Review the tier placement after the pilot; move work up or down where the numbers show it belongs elsewhere.

For physical AI workloads that span plants, devices and the cloud, NexaStack is an agentic operating platform for physical AI that runs across on-premises, cloud and hybrid environments. Teams building the agents and workflows themselves can use ElixirClaw, an agentic OS platform to build, orchestrate and govern AI agents and automation workflows while keeping humans in control.

What are the trade-offs, and when should you not add a fog layer?

Skip the fog tier when devices are few, latency is not critical, connectivity is reliable and there is no residency constraint. A direct device-to-cloud design, or devices plus one managed gateway, is easier to secure and cheaper to run.

To map one edge or fog decision your agents should make, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.

Frequently asked questions

What is the main difference between edge and fog computing?

Location and scope. Edge computing runs a specific application on or right next to the device, such as a camera, controller or gateway. Fog computing adds a layered tier of shared nodes, usually on the local network, that provide compute, storage, control and networking for many devices at once. NIST describes fog as hierarchical and multi-layered, and edge as limited to a small number of peripheral devices.

Is fog computing still relevant in 2026?

The idea is, even if the label is used less. Vendors now sell the fog tier as edge platforms on site, such as Azure IoT Operations on Azure Arc-enabled Kubernetes, AWS IoT Greengrass V2 or Google Distributed Cloud, and as network edge services such as ETSI MEC and AWS Wavelength. The reference definitions are still NIST SP 500-325 and IEEE 1934-2018.

Does edge or fog computing replace the cloud?

No. In a cloud, fog and edge design, the cloud keeps model training, fleet management, long-term storage and cross-site analytics. Fog and edge tiers handle time-critical decisions, local filtering and operation during network outages.

What is mist computing?

NIST describes mist computing as a lightweight and rudimentary form of fog computing that sits closest to the end devices and runs on microcontrollers and microcomputers. It is optional rather than a mandatory layer.

When should an enterprise not add a fog layer?

When a few devices can talk directly to the cloud or to a single gateway, latency is not critical and connectivity is reliable. A fog tier adds hardware, patching and security work at every site, so it should earn its place through latency, bandwidth, resilience or data residency needs.