The framing is wrong from the start. Edge computing did not arrive to replace cloud computing, and no serious system chooses one exclusively. Every real architecture uses both, and the interesting question is which work goes where.
Fortunately that question has a fairly mechanical answer.
The two models
Cloud computing means running your workload in large, centralised data centres. You get effectively unlimited capacity, you pay for what you use, and someone else handles the hardware. The trade is distance: your users are somewhere else, and the speed of light is not negotiable.
Edge computing means running the workload physically close to where the data is produced — in the building, on the device, at the base station, in a regional facility. You get low latency and local autonomy. The trade is that you now have limited, expensive, hard-to-reach compute in many places instead of abundant compute in one.
That is the whole tension. Centralise for economics, distribute for latency and independence.
The four questions that decide it
1. How fast does the answer need to come back?
Round trips have a hard floor set by distance — roughly 1 ms per 50-70 km in practice once routing and equipment are accounted for.
| Requirement | Where it must run |
|---|---|
| Under 5 ms | On the device or in the building. No exceptions. |
| 5-25 ms | Regional edge, same city or metro |
| 25-100 ms | Cloud, in a nearby region |
| Over 100 ms tolerable | Cloud, anywhere convenient |
Industrial control, robotic safety systems, augmented reality head tracking and vehicle braking sit in the first row. They are not cloud workloads at any price, because the physics forbids it. Everything else is a business decision rather than a physical constraint.
2. How much data is produced, and how much of it matters?
This is the argument people underestimate.
A single 4K camera generates several terabytes a month. A factory with two hundred sensors sampling at high frequency produces enormous volumes. Shipping all of that to a data centre costs bandwidth and egress fees continuously, forever.
But almost none of it is interesting. The useful output of a camera watching a loading bay is "a vehicle arrived at 14:32", not thirty frames per second of an empty bay.
Processing at the edge and sending only the conclusions can reduce data volume by three or four orders of magnitude. When the ratio of raw data to useful information is that extreme, edge processing pays for itself on bandwidth alone.
3. What happens when the network drops?
If the answer is "the system must keep working", the decision is made for you.
A payment terminal, a hospital monitor, a building's access control, a production line — all of these have to function during an outage. That requires local logic and local state, with the cloud used for coordination and reporting rather than for operation.
If the answer is "it can wait", the cloud is simpler and cheaper.
Local decisions, central learning. The edge handles anything time-critical or safety-critical and keeps working alone. Periodically it sends summaries upstream, where abundant compute does the aggregation, model training and cross-site analysis. New models are pushed back down. Each layer does what it is actually good at.
4. Where is the data legally allowed to be?
Increasingly the binding constraint, and it has nothing to do with performance. Health records, biometric data, and personal data in jurisdictions with residency requirements may be restricted from leaving a country or a building.
Sometimes this means regional cloud. Sometimes it means the data genuinely cannot leave the premises, and processing has to happen where it is generated.
Cost, which is not intuitive
Neither model is reliably cheaper. They fail expensively in different directions.
Cloud gets expensive when: you move a lot of data out (egress charges are the classic surprise), you run steady predictable load that would be cheaper on owned hardware, or you never cleaned up the resources somebody spun up last year.
Edge gets expensive when: you have to buy capacity for peak load at every site, you have hardware in a hundred locations that needs physical maintenance, or you underestimated how hard it is to deploy software reliably to devices you cannot log into.
That last one is the most common failure. Central deployment is a solved problem. Updating five thousand devices in five thousand buildings, some offline, some on ancient firmware, some behind networks you do not control, is genuinely difficult, and teams routinely underestimate it by a large factor.
Where each clearly wins
Cloud, without argument: model training, analytics over historical data, anything with unpredictable or spiky demand, batch processing, storage of record, and anything you want to be able to change quickly without touching hardware.
Edge, without argument: real-time control loops, safety systems, high-volume video and sensor pre-processing, anything that must survive an outage, and anything where data residency forbids the alternative.
Genuinely contested: content delivery, inference for user-facing features, game servers, retail and point-of-sale systems, and telemetry aggregation. These get decided on cost and operational preference rather than on principle.
A worked example
A retail chain with three hundred stores wants to detect stock gaps from shelf cameras.
All cloud: every camera streams continuously to a data centre. Bandwidth cost is enormous, the connection becomes a single point of failure, and stores stop working when the line goes down.
All edge: each store gets a box running a detection model. Bandwidth is negligible and stores are independent. But three hundred boxes need maintenance, and improving the model means a fleet update.
The sensible design: a modest device in each store runs detection locally and sends only structured events — shelf, timestamp, confidence. The cloud aggregates across all stores, trains improved models on the interesting cases, and pushes updated models down on a schedule. Stores keep detecting during an outage and forward a backlog when the link returns.
That third option is not a compromise. It is what the constraints actually specify once you ask the four questions.
The practical decision procedure
For any given piece of work:
- Does it have a hard latency requirement under 25 ms? If yes, edge. Stop.
- Must it work during a network outage? If yes, edge for the critical path.
- Is the raw data volume large and the useful output small? If yes, process at the edge and forward summaries.
- Does regulation restrict where the data may go? If yes, that decides it.
- Otherwise, cloud. It is cheaper to operate, easier to change, and easier to hire for.
The default should be cloud, with work pulled out to the edge only when one of the first four conditions genuinely applies. Distributing computation is a real cost, and it should be paid for a reason rather than for the architecture diagram.
The direction of travel
The line between the two is blurring from both sides. Cloud providers now operate small facilities in dozens of metropolitan areas and sell managed hardware that runs in your building; edge devices have become powerful enough to run models that recently needed a server rack.
The useful consequence is that latency is becoming a slider rather than a binary choice. You pick a distance and pay accordingly. That is a better world to design in than one where the only options were "in this room" or "in another country", and it means the four questions above matter more than the labels ever did.