CDN vs Edge Computing

The historical separation

The classical CDN era (roughly 2000-2015) was about file delivery. Akamai, CloudFront, MaxCDN, and others operated networks of caching servers that pulled content from origin once and served it many times. The smarts lived at origin; the CDN was a dumb cache.

The edge computing era (roughly 2017 onward) introduced general-purpose code execution at edge POPs. Cloudflare Workers launched in 2017, AWS Lambda@Edge in 2017, Fastly Compute@Edge in 2019, Vercel Edge Functions in 2021. Each lets you run JavaScript (and increasingly WebAssembly) at the POP closest to the user.

Today the two categories overlap. Cloudflare positions itself as an edge platform; AWS markets CloudFront with Lambda@Edge integration; Vercel sells the combination as the default. The historical separation is mostly a vocabulary artifact at this point.

The two distinct capabilities

Cached content is "stuff stored at the edge." Edge code is "logic running at the edge." Modern platforms offer both — and they compose: edge code can decide what to cache, modify cached responses, or fall through to origin.

When you need just a CDN

Workloads that benefit from caching alone:

• Static websites. HTML, CSS, JS, images. Generate at build time; serve from edge. No per-request logic.
• Media delivery. Video streams, large file downloads. Once the file is cached at the edge, it serves indefinitely.
• Software distribution. Installer downloads, package managers (npm, pip, apt mirrors). Content rarely changes; long TTLs.
• Public API responses. Catalog data, prices, search results that are the same for all users. Short TTL with stale-while-revalidate.

For these, the CDN's edge logic is just standard cache-key construction from request URL + selected headers, driven by your origin's Cache-Control headers. No custom code needed.

When you need edge code

Workloads where edge compute is the right tool:

Authentication and access control at the edge

Validate JWTs, check OAuth tokens, enforce IP allowlists, perform mTLS — all before letting requests reach origin. Edge functions are particularly good at this: 5-20 ms execution at the edge vs. 50-200 ms round trip to origin to validate the same token.

Request rewriting and routing

Modify request paths, headers, or hosts before forwarding to origin. Examples: rewrite legacy URLs to new paths, A/B test by sending some users to a different backend, add tracking headers, normalize query parameters.

Geolocation-based personalization

Edge functions receive the user's geographic location as request metadata. Return different content per country (compliance), redirect to a localized domain, or set currency/language without origin involvement.

Edge SSR / streaming HTML

Generate HTML at the edge, streaming the first byte as soon as it's ready. Combine with a per-request data fetch from origin. Patterns popularized by Next.js, Astro, SvelteKit, and Remix. Reduces TTFB significantly compared to origin-only SSR.

Personalized cache lookups

Use edge code to fetch user data from edge state (Cloudflare KV, Workers AI, etc.) and decide what to serve. Allows per-user customization without sacrificing CDN benefits.

API gateways

Rate limiting, authentication, request normalization, response transformation, error handling — the typical API gateway functions, but executed at the edge close to the user.

What makes a workload bad for the edge

Edge environments have strict constraints. Not every workload fits.

Heavy compute

Edge functions typically allow 10-50 ms CPU time per request (50 ms on Cloudflare Workers free tier, more on paid). Image processing, video transcoding, complex ML inference, or long-running calculations exceed this budget. They should run at origin or in dedicated workers.

Database queries to a single region

If your application data lives in a single-region database, the edge function still has to round-trip to that region to fetch data. The edge benefit vanishes — you have the edge function's cold start plus the database round trip. Unless you use a globally-replicated database (Cloudflare D1, AWS DynamoDB Global Tables, FaunaDB, Turso), edge compute does not help.

Large dependencies

Edge functions have package size limits (typically 1-25 MB compressed). Heavy npm packages, large ML models, or extensive native libraries do not fit.

Long-running operations

Edge functions have wall-clock timeouts (10-30 seconds typical). Long-polling, video transcoding, batch processing — all should run on origin compute.

Strong consistency at global scale

Edge state stores (KV, D1) typically have eventual consistency. Writes propagate across the network in seconds to minutes. For applications needing read-your-writes consistency globally (financial transactions, inventory), the edge layer becomes a cache and the source of truth lives in a centralized origin.

The architectural integration patterns

Pattern 1: CDN with origin pull

Classic. Edge caches GET responses from origin. POST/PUT/DELETE pass through. No edge code. Used by: most static sites, most media platforms.

Pattern 2: Edge auth + origin compute

Edge function validates auth and decides whether to forward the request. Authenticated requests reach origin; unauthenticated requests get rejected at the edge. Origin doesn't see junk traffic; latency for unauthenticated rejections is fast.

Pattern 3: Edge transform + origin data

Edge function fetches data from origin or from edge state, transforms it, and returns the response. Origin is a data source; the response shape is decided at the edge. Used by: many API gateways, GraphQL adapters.

Pattern 4: Edge SSR + origin data

Edge function renders HTML, streaming the first chunk while fetching data from origin. Combines fast TTFB with dynamic content. Used by: Next.js App Router with edge runtime, Remix, SvelteKit.

Pattern 5: Full edge

Edge function handles everything — including data access via global edge databases (D1, FaunaDB, Turso, PlanetScale). Origin is reduced to control-plane operations. Used by: increasing number of new SaaS products, content sites, AI inference proxies.

Cost differences

CDN-only is usually billed per GB egress, similar to S3 with CDN attached. Cheap for cacheable workloads — $0.04-0.09/GB depending on volume.

Edge code adds per-invocation pricing. Cloudflare Workers: 100K free per day, then $0.50 per million requests. Lambda@Edge: $0.60 per million requests + $0.0000125/GB-second. Vercel Edge: depends on plan but generally per-request + per-execution-time.

The pricing model means edge code is great for high-traffic, lightweight processing but expensive for low-throughput heavy processing. A workload that fits in 5 ms per request costs nothing meaningful; a workload that uses 200 ms per request costs 40x as much.

Decision summary

• Static / semi-static content delivery only? Pure CDN. No edge code needed.
• Need auth, A/B, rewriting, geolocation? CDN + edge functions. Edge handles those; CDN handles caching.
• Database in single region, latency-sensitive? CDN caches what it can. Edge functions only useful for rejecting bad requests. Real work at origin.
• Database is globally replicated? Full edge architecture is possible. Origin reduces to control plane.
• Heavy compute, ML inference, video? Origin or dedicated compute pool. Edge for traffic shaping only.

Frequently Asked Questions

What is the difference between a CDN and an edge computing platform?

A CDN's primary job is to cache and deliver content from origin to users. An edge computing platform runs your code at edge locations — closer to users than your origin servers. Modern edge platforms typically bundle both: Cloudflare, AWS, and Vercel offer caching CDN features and edge function execution in the same product. The distinction matters historically but is blurred in current products.

Do I need edge computing if I already have a CDN?

Only if you need to run custom logic at the edge — A/B testing, request rewriting, authentication, geolocation-based responses, or dynamic personalization that should not round-trip to origin. A pure static CDN works fine for static sites, videos, and downloads. Edge compute adds value when application logic depends on user-specific data (location, auth, cookies) and origin round-trip latency matters.

Is edge computing the same as serverless?

Edge computing is a specific form of serverless — code that runs on demand without server management. The difference is where it runs. Standard serverless (AWS Lambda, Cloud Functions) runs in a specific region, like a normal application. Edge serverless (Cloudflare Workers, Lambda@Edge, Vercel Edge) runs at edge POPs, close to users. Edge serverless has tighter resource limits and faster cold starts due to the V8 Isolate execution model used by most edge platforms.

What workloads run poorly at the edge?

Anything that does heavy compute, accesses a database in a single region, or maintains long-running state. Edge functions have strict CPU time limits (typically 10-50 ms wall time on free tiers, up to several seconds paid). Database queries to a single-region database undo the latency benefit of running at the edge. Long-lived state requires global state stores like Cloudflare KV/D1 or Durable Objects, which have their own latency profile.

Why does Cloudflare Workers start so much faster than Lambda?

V8 Isolates vs container-based isolation. Cloudflare Workers run multiple customer functions in the same V8 process, isolated at the JavaScript level — startup is essentially free (under 5 ms). Traditional Lambda spins up a container per function invocation, which takes 50-500 ms for a cold start. AWS introduced Lambda SnapStart and Firecracker microVMs to reduce this gap, but V8 Isolates remain dramatically faster for the use cases they fit.