What Is a CDN? covered caching static content close to users to reduce latency. Edge computing takes the same underlying principle — proximity reduces latency — and applies it to something a CDN alone can’t do: running actual code close to the user, not just serving cached files.
Where a CDN’s job ends
A CDN excels at serving content that’s the same for every user and doesn’t need to be computed fresh on each request — images, stylesheets, static pages. Its edge locations are optimized for fast retrieval and delivery of that content, not for running arbitrary application logic. Content that genuinely needs computation specific to each request — personalization, real-time data processing, logic that depends on the specific request — falls outside what a CDN’s caching layer alone is designed to handle.
What edge computing adds
Edge computing extends compute capability itself out to distributed edge locations, rather than confining it to a small number of centralized regions. AWS’s overview of its edge infrastructure describes this as bringing compute, storage, and services physically closer to end users and devices, specifically to reduce the latency and bandwidth cost of always routing every request back to a centralized region.
In practice, this often takes the form of lightweight functions that can run at edge locations — modifying a request or response, running personalization logic, or handling simple application logic — without a full round trip to a centralized backend for every request. It’s a similar underlying serverless execution model to the one described in Serverless vs. Containers vs. VMs, just deployed to many distributed locations instead of a single region.
What edge computing is good for, and what it isn’t
Edge computing earns its complexity for logic that’s genuinely latency-sensitive and doesn’t need access to a large, centralized dataset — request routing decisions, lightweight authentication checks, simple transformations, A/B test assignment. It’s a poor fit for logic that needs to query a large, centralized database or maintain complex shared state, since that data generally isn’t (and often can’t practically be) replicated to every edge location — pulling it back to the edge would just reintroduce the latency the edge was meant to avoid, or run into the same consistency trade-offs that make distributing any stateful system hard.
A spectrum, not a binary choice
In practice, “edge” and “centralized” aren’t mutually exclusive architectural choices for a whole application — most real systems place different pieces of logic at different points along the spectrum, running lightweight, latency-sensitive logic at the edge while keeping data-heavy, stateful logic centralized, connected back through DNS resolution and routing, discussed in How DNS Actually Works, that directs a given request to the right place in the first place.
Key takeaway
Edge computing extends a CDN’s core insight — proximity to the user reduces latency — from cached static content to actual running computation, deployed across many distributed locations instead of a small number of centralized regions. It’s the right tool for latency-sensitive, relatively simple logic, and a poor fit for anything that needs centralized data or complex shared state, which is why most real architectures use it alongside centralized compute rather than as a wholesale replacement for it.
This article explains general edge computing concepts; specific capabilities and limitations vary by provider. See our disclaimer.