IoT: Process Data on the Device, at the Edge or in the Cloud

Three places to process data

Most connected products split the work between three places:

• On the device. The sensor or appliance does what it can with its own processor: reads a value, checks a threshold, switches a relay. Small microcontrollers have little memory, so this is usually simple logic.
• At the edge. A more capable computer on site, such as a gateway in a factory or a hub in a building, collects data from many devices, processes it and talks to the cloud on their behalf.
• In the cloud. The platform your devices report to stores the data, runs the heavier analysis and serves your mobile and web apps. Our guide to IoT cloud platforms covers that layer: MQTT, device registries, and device shadows and twins.

Few products use only one. A thermostat may decide locally when to switch the heating, while the cloud keeps the history and the app. The real question is which decisions must not depend on the internet, and which data is worth sending.

What an edge runtime does

You can write edge software from scratch, but the big cloud providers offer runtimes that install on the edge computer and are managed from their cloud.

AWS IoT Greengrass is described by AWS as "an open source Internet of Things (IoT) edge runtime and cloud service". It lets devices "act locally on the data that they generate", run predictions from machine learning models, and "filter and aggregate device data". According to how AWS IoT Greengrass works, the Core software runs on Windows and Linux-based distributions on ARM or x86 hardware. Software is packaged as components, which can be Lambda functions, Docker containers, native processes or custom runtimes. Smaller devices that cannot run Greengrass themselves can connect to a Greengrass core device over MQTT, and the core device can "process, filter, and aggregate data" from them.

AWS offers two versions of the core runtime. The original, written in Java, gives wide portability but comes with "a large memory footprint", in AWS's words; the newer Greengrass nucleus lite, written in C, "considerably reduces its footprint" but has to be built separately for each target platform. So the hardware you choose for the edge and the runtime you choose go together.

Azure IoT Edge is, in Microsoft's words, "a device-focused runtime that enables you to deploy, run, and monitor containerized Linux applications". Your code runs as modules, which are Docker-compatible containers, and it runs on Windows through IoT Edge for Linux on Windows. Two system modules do the work: the IoT Edge agent starts the modules and keeps them running, and the IoT Edge hub acts as a local proxy for Azure IoT Hub. Microsoft notes that the hub "isn't a full local version of IoT Hub"; some tasks are still handed to the cloud. IoT Edge is available in the free and standard tiers of IoT Hub, and the free tier is for testing and evaluation only.

Working without a connection

For many products this is the main reason to process at the edge: a production line, a farm or a building should not stop when the internet does.

Microsoft's page on IoT Edge offline capabilities says that after an IoT Edge device has connected to IoT Hub once, the device, its modules and any downstream devices "can keep operating indefinitely" while disconnected. While offline, the IoT Edge hub stores upstream messages until the device reconnects, authenticates modules and downstream devices so they can keep running, and passes messages between them. On reconnection, stored messages are delivered in the order they were stored.

There are limits worth planning for. Microsoft notes that message storage "depends on the time to live (TTL) setting and available disk space", and that the hub's local cache is not capped and grows as long as the device has storage. It also warns that while a device is offline it cannot report deployment status, so the Azure portal can keep showing it as healthy.

On the AWS side, the Greengrass stream manager "works in environments with intermittent or limited connectivity". You set how much storage each stream may use, how long data is kept, how much bandwidth to use, and priorities, so that critical data is exported to the cloud before other data. The shadow manager component keeps device shadows on the core device and can synchronise them with the AWS IoT Device Shadow service.

Whichever runtime you use, decide what the product should do when the connection is gone for an hour, a day or a week: which actions still work, what is stored, and what is dropped when storage fills up.

Sending less data to the cloud

Raw sensor data can be large, and much of it is routine. Microsoft gives the example of cleaning and aggregating data locally "then only send the insights to the cloud for analysis", to reduce bandwidth costs. AWS describes components that filter or compress data before stream manager exports it, so that the core device can "respond quickly to local events and extract valuable information" before data leaves the site.

The trade-off is that data you discard at the edge cannot be analysed later. Decide which raw data you may need again, for example to investigate a fault, and keep that, even if only on local storage for a period.

Connectivity matters here too. A device on a narrow or metered link has more reason to send summaries than one on wired Ethernet; our guide to choosing connectivity for an IoT product compares the options.

Getting software onto edge devices

Edge software needs updating like any other, often on devices that are far away and not always online. Both runtimes manage this from the cloud.

In AWS IoT Greengrass, deployments target a device or a group of devices and are continuous: "If a target device isn't online, then it receives the deployment the next time it connects". Components can ask to defer an update, for example "if the device has a low battery level or is running a process that can't be interrupted". A deployment can roll back devices to their previous configuration if it fails, roll out gradually, and stop automatically if too many devices fail. AWS also warns that dependencies are installed at their latest supported versions, which can bring unexpected updates and restarts, and recommends naming the component versions you want.

Azure IoT Edge uses a deployment manifest that lists the modules for a device. With automatic deployments, the manifest goes to every device whose tags or reported properties match a target condition, and newly matching devices are configured when they connect. Microsoft notes that "You can't combine per-device and automatic deployments", so choose one approach for the fleet early.

These tools update the software running on the edge computer. The firmware of the devices themselves needs its own update path, which our guide to over-the-air updates explains.

The trade-offs

Processing closer to the devices tends to give:

• faster local reactions, because decisions do not wait for a round trip to the cloud;
• continued operation when the connection drops;
• less data sent, which helps on slow or metered links;
• the option to keep some data on site.

It also brings costs that are easy to underestimate:

• more hardware to buy, install, power and replace;
• more software to update and monitor, in places you cannot easily reach;
• a computer on site that must be secured, as our IoT security guide covers;
• harder debugging, because the problem may be on a device you cannot see.

Processing in the cloud keeps devices simpler and lets you change the logic in one place, but everything that depends on it stops when the connection does. Many products end up with a mix: safety and real-time decisions on the device or at the edge, history, reporting and apps in the cloud.

Questions to settle early

• Which actions must keep working with no internet, and for how long?
• How much data do devices produce, and over what kind of link?
• Which raw data might you need later, and where will it be kept?
• Is there a place for an edge computer on site, and who maintains it?
• Does the edge hardware have the memory and operating system the runtime needs?
• How will edge software be deployed, rolled back and monitored across the fleet?
• What should apps show when a site has been offline for a while?

Frequently asked questions

What is edge computing in IoT?

Processing device data on a computer close to the devices, such as a gateway or hub on site, instead of sending everything to the cloud first. The edge computer can act on local events, keep working offline and send only what the cloud needs.

Do we need AWS IoT Greengrass or Azure IoT Edge?

Not always. They are useful when you run software on site computers and want to deploy and monitor it from the cloud. A product whose devices talk straight to the cloud, or that only needs simple logic on the device itself, may not need an edge runtime.

Can an edge device keep working without the internet?

Yes, if it is designed to. Microsoft says an Azure IoT Edge device that has connected to IoT Hub once can keep operating indefinitely offline, storing messages until it reconnects, though storage is limited by message time to live and disk space. AWS IoT Greengrass stream manager is built for intermittent or limited connectivity.

How are edge devices updated?

Both runtimes deploy software from the cloud. AWS IoT Greengrass deployments reach offline devices the next time they connect and can roll back a failed update. Azure IoT Edge can deploy automatically to every device that matches a target condition. Device firmware needs its own over-the-air update path.

Is AWS IoT Greengrass Version 1 still supported?

No. AWS says it ended support for AWS IoT Greengrass Version 1 on 7 October 2026 and that the V1 API operations and resources are no longer available. New projects should use Version 2.

Building a connected product? We build the firmware connectivity, the backend that collects and acts on device data, and the mobile and web apps, with security planned in from the first prototype. See our IoT development service and all our services, or email [email protected].