What is edge computing?

The problem it solves

Sending every piece of data to a distant cloud region and waiting for a response works fine for most workloads, but some cannot tolerate that round trip. A factory robot deciding whether to stop before a collision, a self-driving system reacting to an obstacle, or a video feed being screened for a fault on a production line all need a decision in milliseconds — far less time than a request travelling to a data centre hundreds of kilometres away and back allows. Other workloads simply generate too much raw data to usefully ship in full: a single industrial sensor array or a fleet of cameras can produce far more volume than is practical, or affordable, to transmit continuously.

Edge computing addresses both problems at once. Processing time-sensitive or high-volume data close to its source removes the network round trip from the critical path and cuts down what actually needs to cross the wider network, leaving bandwidth and central compute for the work that genuinely benefits from it.

How it works, conceptually

In an edge architecture, compute happens at several points rather than one. Local devices — sensors, cameras, industrial controllers — may do some processing themselves. Gateways or small on-site servers aggregate and filter data from many local devices before anything leaves the building. Edge locations operated by a cloud provider sit closer to end users or facilities than a full region, handling processing that needs to be nearby but does not need to run on the device itself. The central cloud then handles what it is best at: heavier computation, long-term storage, training and analysis across aggregated data from many edge sites, and anything that is not time-critical.

The division of labour is deliberate: the edge handles "decide now," the cloud handles "understand overall."

Edge and cloud are partners, not rivals

Edge computing does not replace the cloud; it extends it outward. The same ideas that make cloud regions and availability zones work — distributing infrastructure to be closer to where it is needed and resilient to local failure — apply at a smaller, more local scale at the edge. A related and more familiar form of edge computing is the content delivery network, covered in our what is a content delivery network explainer, which caches and serves static content from locations near the requester; edge computing generalises that same "process closer to the user" idea to active computation, not just cached files.

In practice, an edge deployment still relies on the central cloud for management, updates, aggregated analytics and long-term storage — the edge is where certain decisions get made faster, not where the whole system lives.

Where edge computing shows up

A few recurring patterns illustrate the range of edge use cases:

• Internet of Things (IoT) — sensors and devices that pre-process or filter readings locally before sending summaries to the cloud.
• Manufacturing — on-site systems monitoring equipment and quality in real time, without depending on network availability to keep a production line safe.
• Retail — in-store systems handling point-of-sale, inventory checks or camera analytics locally, so the store keeps functioning if connectivity drops.
• Autonomous vehicles and robotics — decisions that must be made in real time, with the cloud used for fleet-wide learning and updates rather than moment-to-moment control.
• Real-time analytics — dashboards or alerts that need to reflect what is happening now, not what happened after a round trip to a distant data centre.

What the major providers offer

AWS, Azure and Google Cloud each provide edge and IoT services that extend their platforms toward devices and local sites, alongside networks of edge locations used for content delivery and, increasingly, compute closer to end users. The specifics of each provider’s offerings and the number or location of their edge points change often enough that it is worth checking the provider’s current documentation rather than treating any snapshot as fixed — the concept of "compute pushed closer to the source" is the stable part, and the product names built on top of it change over time.

The honest trade-offs

Edge computing solves a real problem, but it is not free. Managing infrastructure spread across many physical sites is harder than managing it in one or two cloud regions — updates, monitoring and troubleshooting all have to reach places that are, by design, remote and sometimes intermittently connected. Security is also more demanding: every edge location is a physical and network endpoint that needs protecting, and the attack surface grows with the number of sites. Edge computing is worth the added operational complexity for workloads that genuinely need low latency or local resilience, and is unnecessary overhead for workloads that do not.

Edge concepts appear across cloud certification study wherever architecture and networking are covered — recognising when a workload needs edge processing, and how it fits alongside central cloud services, is part of designing well-architected systems.