Cloud, edge, and fog computing are usually presented as three competing places to process IoT data. In practice they are three positions on one axis — distance from the sensor — and almost every production system uses all three at once.
The useful question is therefore not which to choose, but which piece of work belongs at which distance. That decision is driven by physics and economics rather than preference: how fast a reaction must be, what happens when the network fails, and how much it costs to move the data.
This guide defines each tier precisely, sets out the criteria that assign work to them, and covers the mistakes that come from putting the wrong responsibility in the wrong place.
For AIoT systems, where models run adds a further question, so the final part of this guide covers how to split responsibilities cleanly in a hybrid edge-cloud design.
What Each Tier Actually Means
Edge computing — on or beside the device
Processing that happens on the sensing device itself or on hardware directly attached to it. Latency is measured in microseconds to milliseconds, and it continues working with no network at all.
The constraint is capability: limited memory, limited compute, and often a strict power budget. Work placed here must be small, deterministic, and genuinely necessary to run locally.
Fog computing — at the local network
An intermediate tier between devices and the cloud: gateways, on-site servers, or micro data centres serving a building, a production line, a vehicle, or a substation.
Fog nodes have mains power and real compute, and they see many devices at once. Their defining ability is local correlation — combining data from several devices in the same physical place, which no individual device can do and which the cloud cannot do fast enough or during an outage.
Cloud computing — centralised and remote
Effectively unlimited compute and storage, reachable over a wide-area network. Latency ranges from tens to hundreds of milliseconds and depends entirely on connectivity being available.
Its unique capability is scope: it sees every device, every site, and the entire history. Nothing else can compare one machine against ten thousand or train on two years of data.
Edge is defined by speed and independence. Fog is defined by local context. Cloud is defined by scope and memory. Each has one thing the others cannot provide.
Cloud vs Edge vs Fog: Direct Comparison
| Edge | Fog | Cloud | |
|---|---|---|---|
| Location | On or beside the device | Local network or site | Remote data centre |
| Latency | Microseconds to milliseconds | Milliseconds to tens of ms | Tens to hundreds of ms |
| Compute available | Very limited | Moderate to substantial | Effectively unlimited |
| Works offline | Fully | Fully, for local scope | No |
| Data visibility | One device | One site | Entire fleet and history |
| Cost driver | Hardware per unit | Site hardware and upkeep | Usage: ingestion, storage, compute |
| Best for | Immediate reaction, filtering | Local correlation, protocol translation | Learning, comparison, coordination |
Deciding Where Work Belongs
Four questions place almost any piece of processing correctly.
Applied to a typical predictive maintenance system, this produces a clear division: the device samples vibration and extracts features, the fog node correlates several machines on a line and reacts to local conditions, and the cloud compares assets across the fleet and retrains the model that the device runs. The same reasoning underpins the wider question of choosing an IoT deployment architecture.
Common Mistakes in Tier Placement
Hybrid AIoT: Split by Responsibility, Not by Technology
The useful division is not “AI in the cloud, rules at the edge”. It is based on what each side can uniquely do.
| Only the edge can | Only the cloud can | |
|---|---|---|
| Timing | React in milliseconds | — |
| Availability | Work with no network | — |
| Data | See full-rate raw signals | See every device and every year |
| Cost | Avoid transmitting | Afford heavy computation |
| Learning | — | Compare assets and retrain |
Everything in the first column must be at the edge regardless of preference. Everything in the second must be central. What remains is genuinely a choice, and should be decided on cost and operational simplicity rather than habit.
The edge decides what is happening. The cloud decides what it means across the fleet, and improves what the edge knows.
What Belongs at the Edge and What in the Cloud
At the edge
- Signal conditioning, filtering and feature extraction at full rate
- Immediate detection and any safety or control reaction
- Local buffering during connectivity loss
- Deciding what is worth transmitting at all
- Inference where latency or offline operation matters
In the cloud
- Long-term storage and historical analysis
- Cross-asset and cross-site comparison
- Model training and retraining
- Fleet management, configuration and update orchestration
- Business system integration and reporting
What crosses the line
Upward: events, summaries, features, model outputs with confidence, device health, and a sampled stream of raw data for future training.
Downward: configuration and thresholds, updated models, firmware, and commands. Keeping both directions explicit is what prevents the system becoming an undocumented mesh of special cases.
How Hybrid Architectures Go Wrong
Frequently Asked Questions
Conclusion
Cloud, edge, and fog are not alternatives. They are three distances, each with one capability the others cannot supply: speed and independence at the edge, local context in fog, scope and memory in the cloud.
Assign work by asking how fast it must react, whether it must survive an outage, how many sources it needs, and what moving the data costs. Give every decision exactly one owner, buffer between every tier, and leave enough headroom on devices to move work downward later. That is what makes an architecture that grows rather than one that has to be escaped.