Edge vs Cloud: Where Should the Compute Live?

There's a question that sits underneath every serious IoT architecture, and once you notice it you can't stop seeing it: where should the computation actually happen? Out at the edge, on or near the sensors themselves, where the data is born? Or in the cloud, where there's effectively unlimited power and a central view of everything? It sounds like a technical detail. It's actually one of the defining design decisions of the whole field, and getting it right — or rather, deciding it deliberately instead of by default — shapes the cost, the responsiveness, and the resilience of everything you build.

Let me lay out the real trade-off, because "edge" and "cloud" get talked about as a rivalry when they're better understood as two ends of a dial you set on purpose, per workload.

The case for the cloud

The cloud's appeal is straightforward and genuine: it's where the power and the perspective are.

• Effectively unlimited compute. Heavy processing, large-scale analytics, anything that needs to chew through a lot of data or run a demanding model — the cloud has resources an edge device can only dream of. If the job is big, the cloud is where big jobs live comfortably.
• The central, whole-system view. The cloud sees everything — every building, every sensor, all the history, together. Any question that spans the whole estate ("compare all our buildings," "learn a pattern across the entire fleet") fundamentally needs the place where all the data converges. The edge, by definition, only sees its own corner.
• Easier to manage and evolve. Updating logic in one cloud service is far simpler than pushing changes out to a thousand scattered devices. Centralised means maintainable.

If those were the only considerations, everything would run in the cloud and there'd be no post to write. But they aren't.

The case for the edge

The edge's appeal only becomes obvious once you take the physical reality of the situation seriously — which cloud-native thinking tends not to.

• Latency: some reactions can't afford the round trip. If something needs to respond now — a safety threshold, a local control loop — shipping the reading to the cloud, waiting for a decision, and shipping the command back may simply be too slow. When the reaction has to be immediate, the computation has to be local, near the thing it's reacting to. Physics doesn't negotiate.
• Bandwidth and cost: shipping everything is wasteful. A building's sensors produce a relentless torrent of raw readings, and most of it is unremarkable — the temperature was normal, again, for the ten-thousandth time. Sending every raw reading to the cloud costs bandwidth and money to transmit and store, to mostly confirm nothing happened. Process at the edge and you can send summaries and exceptions — "here's the hourly average, and by the way something unusual happened at 3pm" — instead of the raw firehose. That's a large, ongoing saving.
• Autonomy: it has to work when the network doesn't. This is the one cloud-native designs forget. If your logic lives entirely in the cloud, then the moment connectivity drops, your building goes dumb — it can't react to anything until the link comes back. Edge computation means the local intelligence keeps working through an outage. For anything that matters, "stops working when the internet hiccups" is not acceptable, and only the edge fixes it.

None of these are edge being nicer. They're edge being necessary for a specific class of requirement that the cloud, however powerful, structurally can't meet — because the constraint is about where the work happens relative to the physical world and the network.

It's a dial, not a switch

So the answer to "edge or cloud" is almost always "both, deliberately split" — and the skill is deciding which computation goes where, workload by workload. The pattern I keep arriving at:

• Put the time-critical and the autonomy-critical at the edge. Anything that must react instantly, or must keep working when the network is down, lives locally. This is non-negotiable for those requirements.
• Put the local data reduction at the edge too. Summarising, filtering, and detecting exceptions near the source — so you ship insight, not raw torrent — is where the bandwidth and cost savings come from, and it's cheap intelligence to place locally.
• Send the reduced, meaningful data to the cloud for the big picture. Cross-building analysis, long-term history, heavy modelling, the whole-estate view — the things that genuinely need everything in one place and serious compute — happen in the cloud, fed by the digested stream the edge sends up.

Azure IoT Edge, which lets you run cloud-style logic out on the devices, is what makes this split practical rather than theoretical — you can push real processing to the edge and manage it centrally, getting local responsiveness without hand-building everything twice.

Edge versus cloud isn't a contest with a winner. It's a placement decision you make per workload, on latency, bandwidth, and autonomy. Decide it deliberately, and you get a system that's responsive, economical, and resilient. Decide it by default — everything in the cloud because that's the reflex — and you get one that's laggy, expensive, and helpless the moment the network blinks.

A worked split: one building

Let me make the dial concrete with a single building. The instant reactions — a threshold that needs to trigger a local response now, the control loops that keep the place comfortable and safe — run at the edge, because a round trip to the cloud is both too slow and too fragile for anything that must happen immediately and keep happening during an outage. The relentless raw stream from the sensors also gets reduced at the edge: instead of shipping every reading, the local intelligence rolls it up — averages, exceptions, "here's the shape of the last hour, and one thing worth flagging" — and sends that up.

Then the cloud takes over for everything the edge structurally can't do. Comparing this building against the rest of the estate. Holding the long history and spotting the seasonal patterns. Running the heavier analysis that no edge device could. None of that needs to be instant, and all of it needs the whole picture, so the cloud is exactly right for it.

The result is a building that stays responsive and keeps working when the network drops, sends a fraction of the data it would have shipped raw, and still feeds a rich central view for the big questions. Every piece of that came from asking, of each workload, the one question that actually decides it: does this need to happen here, now, regardless of the network — or is it fine for it to happen there, later, with everything else.

Where I've landed

In practice, my buildings run a deliberate blend: local intelligence handling the instant reactions and the summarising, so the building stays responsive and keeps working through a network drop, and the cloud handling everything that benefits from seeing the whole picture over the long term. The raw firehose gets tamed at the edge into something meaningful; the meaningful stream flows up for the big questions.

What I'd urge anyone building IoT to avoid is treating this as a decision that makes itself — defaulting everything to the cloud because cloud is where we're all trained to put compute now. The edge exists because some requirements are about place: how fast, how far the data has to travel, and whether it has to work when the connection doesn't. Those requirements don't care how powerful your cloud is. Ask where each piece of compute has to live, set the dial accordingly, and the architecture comes out right. Reach for the cloud reflexively, and you'll build something that works beautifully in the demo and falls over the first time a building loses its connection at exactly the wrong moment.