Edge computing vs cloud for IoT: where the decision should live

The search “edge computing vs cloud” usually wants a winner. For IoT, that is the wrong shape of answer. Edge computing keeps a decision on the device or on a computer near it. Cloud computing runs it in a remote data center. Use the edge when the action is local, urgent, or must survive a dropped network, and when shipping raw data would be wasteful or hard to justify. Use the cloud when the value comes from history, fleet-wide comparison, or heavier analysis. Most systems that matter do both, on purpose. This is how to draw that line.

The words drifted, including at NIST

“Edge” is not a brand of box. In March 2018 the U.S. National Institute of Standards and Technology published Special Publication 500-325, a conceptual model of fog computing. For that paper, edge computing is the network layer of end devices and their users: local computing on a sensor, a meter, or another device that can be reached over a network. Fog, in the same paper, sits in layers between those devices and a traditional cloud. It is hierarchical. It covers computing, and also storage, control, and faster data handling. NIST warned that people already mixed the two up.

Since then, industry speech has stretched “edge” to a gateway or a cupboard server. The NIST Internet of Things Advisory Board, in October 2024, used that looser sense on purpose: data may be processed on the device, on a nearby server it called “the edge,” or off premises in “the cloud.” Say which you mean. A model on the sensor and a model beside the machine are both not the cloud, and they fail differently. If the cupboard loses power, the sensor’s loop may continue. Spare computers do not help a decision only the sensor can make.

Cloud, in this contrast, means pooled computing and storage in a remote data center, reached over a wide-area network and shared across sites. Edge is nearby. Cloud is elsewhere. The design question is which decisions can survive the gap.

What the cloud is actually for

The cloud earns its place when the value appears only after many devices, or many months, are seen together. One thermostat can notice a room. It cannot see that equipment across a region fails in the same week, or that a maintenance pattern shows up only in the fleet. Central systems hold long histories, train models on more examples than one site will collect, stage software for a fleet, and give people a place to look.

IoT Analytics, in its 28 October 2025 State of IoT update, treated demand for device data as a growth driver through 2030, next to its estimate of 39 billion connected devices that year. Wanting data is not the same as wanting every raw reading in a distant region. Central analysis needs identities, time, and enough context to compare sites. It does not need a live copy of every intermediate sample.

The cloud is also where a rule can change without a visit. A test that analysts revise every week is painful to push onto every device and easier to change in one service, if the devices can tolerate the wait and the outage. Frequent change argues for the center. It does not argue for putting a safety interlock there.

What should stay near the device

Keep a decision at the edge, whether that means the device or a nearby gateway, when delay, disconnection, or the cost of shipping raw data would make the cloud result useless or unsafe.

Some actions have to match the pace of a machine, a door, a brake, or a process line. Inserting a wide-area round trip, plus whatever queue sits behind it, makes the tail of the delay someone else’s problem. Median speed on a good day is not the requirement. The requirement is what happens on a bad day, and what the actuator does if the answer never arrives.

Some sites have no reliable path. A hut, a ship, a basement, or a rural pump does not become a cloud application because a slide said the network was fine. If the job must continue through an outage, the outage policy has to live locally: hold the last safe setting, refuse new remote commands, keep a reduced mode, and store a bounded log until a link returns.

Volume is the third push. A camera, a vibration stream, or a high-rate meter can cost more to haul than the insight is worth. The LoRa Alliance, on 2 March 2026, described devices that infer on the device and send an alert or a recommendation instead of bulk raw data. It also said there were more than 125 million LoRaWAN devices worldwide at the end of 2025. The useful point is architectural, not a slogan about artificial intelligence. A small radio can carry a conclusion. It should not be asked to carry a firehose.

Privacy pushes the same way, with a narrower legal meaning. Not every reading is personal data. A household occupancy trace, a wearable, or a workplace camera may be. The EU General Data Protection Regulation, Article 5(1)(c), says personal data must be adequate, relevant, and limited to what is necessary. Local processing does not by itself meet that duty. It can help, because data that never leaves need not be justified as a transfer. It is false comfort if the “local” box still syncs identifiable archives every night.

A split you can defend

Do not choose edge or cloud for a whole product. Place each function.

Sampling and the first filter belong next to the sensor. The device, or the gateway, should decide what is normal enough to drop. Event detection that must happen even if the wide-area link is down belongs there too: a threshold, a stuck actuator, a door that must not wait. Short-term buffering belongs there, with a stated limit, so a week of disconnection does not fill the disk and crash the loop.

Cross-site comparison, model training, long retention, and identity and software management for a fleet belong in the center, or in a regional center if the data is not allowed to leave a jurisdiction. Commands that change a safety boundary should be explicit, authenticated, and boring. A local controller should be able to reject a remote command that falls outside the policy it already holds.

How long may this decision wait? What happens after a minute offline, and after a day? Is the data personal, operational, or both? Who maintains the rule if it sits on a thousand devices? Moving work outward can cut a cloud bill and raise the cost of field support. A distributed fleet needs identities, health reports, staged updates, and a way back from a bad release. NIST’s fog paper already counted that burden.

Hybrid is the usual outcome, not a shrug. The October 2024 advisory board described local, nearby, and cloud processing as three places one system might use. A good design says which fact is computed where, and what the other places may assume.

What the comparison is not

Edge computing vs cloud is not a moral ranking. Local processing is not automatically private, and a data center is not automatically reckless. A poorly protected gateway can be a worse exposure than a well-run service with a narrow feed. Keeping raw video “in case” also fails a necessity test when the job was to record an exception.

Chip fashion does not settle it. Smaller models make more on-device inference possible. They do not repeal outages, battery limits, or the difference between a control loop and a monthly report. A faster radio is still a link. If the decision is unsafe without that link, it is in the wrong place.

There is no single winner, and a page that offers one is selling a category. The durable answer is placement: immediate work next to the process, shared work where the history already is, and a written story for the day the path between them breaks.

MeshRuby’s notes on ordinary deployments come back to that placement rather than to a platform. Send the fact that changed. Leave the decision that cannot wait beside the thing it controls. The cloud can wait for the summary.