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.
Definitions
What Each Tier Actually Means
1
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.
2
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.
3
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.
Comparison
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 |
Assignment
Deciding Where Work Belongs
Four questions place almost any piece of processing correctly.
How fast must it react?
Under 10 ms means the device. Tens of milliseconds allows a fog node. Hundreds of milliseconds or more permits the cloud. This is the strongest constraint and it comes from the physical process, not from ambition.
Must it survive an outage?
Anything with safety, quality, or continuity implications must run at the edge or in fog. If the process cannot pause when the internet does, cloud dependency is not an option regardless of latency.
How many sources does it need?
One device points to edge. Several devices in one place points to fog. Devices across multiple sites points to cloud. This single question resolves most placement debates.
What does moving the data cost?
High-rate signals such as vibration, audio, and video should be reduced where they are produced. Transporting raw high-bandwidth data to the cloud is usually the most expensive possible choice.
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.
Pitfalls
Common Mistakes in Tier Placement
1Putting everything in the cloud by default
It is the easiest tier to build in and the worst to depend on. Any requirement involving latency or availability eventually forces a redesign, usually after hardware has been deployed.
2Pushing too much onto constrained devices
Edge compute is expensive per unit and limited by power. Work that does not need to be local should not be, or battery life and unit cost both suffer for nothing.
3Duplicating a decision across two tiers
If both the device and the cloud can trigger the same action, they will eventually disagree, and diagnosing that is disproportionately painful. Every decision needs exactly one owner.
4Treating fog nodes as infrastructure
Gateways need identity, monitoring, configuration management and an update path exactly like devices. Hand-configured gateways become the limiting factor as sites multiply.
5Leaving no compute headroom
Choosing the smallest device that fits today means any future local processing requires new hardware. A modest surplus preserves the option to move work down a tier later.
6Forgetting buffering between tiers
Each tier must hold data when the one above is unreachable. Without it, an outage anywhere becomes permanent data loss rather than a delay — the core of
offline-first design.
FAQ
Frequently Asked Questions
What is the difference between edge, fog and cloud computing?
They are three positions on one axis: distance from the sensor. Edge runs on or beside the device with microsecond to millisecond latency and full offline operation. Fog runs on a gateway or site server and correlates several devices in one place. Cloud is remote, effectively unlimited, and sees the entire fleet and history.
Is fog computing the same as edge computing?
No. Edge processing happens on the device itself, limited to one device’s data and constrained by power and memory. Fog sits on a gateway or local server with mains power, sees many devices at once, and its defining capability is local correlation across them.
Do you have to choose between edge, fog and cloud?
No, and most production systems use all three. The useful decision is which piece of work belongs at which distance: the device decides what happened, the fog node decides what it means locally, and the cloud decides what it means across the fleet over time.
When should processing stay out of the cloud?
When the reaction must occur in under roughly 10 milliseconds, when the process cannot pause during a network outage, when moving the raw data would cost more than the insight is worth, or when regulation prevents the data leaving the site.
What does a fog node actually do?
Protocol translation for local equipment, buffering during uplink loss, correlation across several devices in the same location, and any real-time reaction that needs more compute than a device has. It is also where legacy industrial protocols are converted into a normalised format.
What is the most common architecture mistake?
Putting everything in the cloud because it is the easiest tier to build in. Any requirement involving latency or availability eventually forces a redesign, and by then the hardware choices that would have made local processing possible are already fixed in deployed devices.
Wrapping Up
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.
