“CDN” and “edge computing” are often used interchangeably, especially in marketing. They’re related — both run on the same distributed infrastructure — but they solve different problems. A CDN serves content. Edge computing runs code.

This post draws the boundary clearly, walks through what each does well, where they overlap, and how to choose between them (or combine them) for a real application in 2026.

CDN: The Original Idea

A Content Delivery Network caches static assets — images, CSS, JavaScript, videos — at hundreds of physical locations close to users. When a user in Tokyo requests cdn.example.com/logo.png, they fetch it from a server in Tokyo, not from your origin in Virginia.

The benefits:

Latency — the file comes from nearby instead of halfway around the world.
Bandwidth offload — your origin serves fewer requests.
Resilience — the CDN absorbs traffic spikes.
DDoS protection — bonus, courtesy of the CDN’s scale.

The traditional CDN model is read-only for content. You publish files; users fetch them. The CDN takes care of distribution.

This works perfectly for static assets and is well-suited to anything that doesn’t change per-user.

Edge Computing: Running Code at the POP

Edge computing generalizes the CDN idea: instead of just caching responses near users, run code near users. The same global network of POPs (typically anycast) that serves cached files also runs lightweight compute.

Examples:

Cloudflare Workers — JavaScript/TypeScript/Wasm running at every Cloudflare POP.
Vercel Edge Functions — Similar model, integrated with the Vercel platform.
AWS Lambda@Edge and CloudFront Functions — Smaller compute on CloudFront POPs.
Fastly Compute — Wasm-based edge functions.

When a user requests a URL, your code runs in their region — milliseconds away — before the request reaches your origin (if it reaches it at all). The code can:

Rewrite requests/responses
Serve personalized content from edge data
Make A/B testing decisions
Authenticate the user before forwarding to origin
Make GeoIP-based routing decisions

The execution environment is constrained (fast cold-start, limited CPU time per request, no persistent local disk), but that’s the point — these are short, lightweight functions.

The Difference, Concretely

A traditional CDN responds to “where is this file.” Edge computing responds to “given this request from this user in this country, what should we serve?”

Capability	CDN	Edge computing
Cache static files near users	Yes	Yes
Serve precomputed responses	Yes	Yes
Make per-request decisions	No (mostly)	Yes
Personalize per user	No	Yes (light)
Heavy computation	No	No (limited)
Database access	No	Limited (KV-style storage usually)
State across requests	No	Limited
Cold start	N/A	~ms
Cost	Cheap	Per-request

Modern CDNs blur this line — Cloudflare’s static caching and Workers share the same edge network — but it’s still useful to keep the conceptual distinction.

When CDN Alone Is Enough

For many sites:

Static marketing sites — Pages don’t change per user. CDN caches everything; users get sub-100ms TTFB globally.
Static documentation — Same. Astro, Hugo, Next.js static export → CDN.
Image/video delivery — Adobe, Netflix, YouTube — massive content served from CDN edges.
Software downloads — Releases, installers, packages. CDN is the right level.

If your content is bytes that don’t depend on the requester, CDN is the answer.

When You Need Edge Computing

Edge computing earns its complexity when:

You need per-user logic at low latency. A/B testing, feature flags, geo-routing, personalization — all benefit from running near the user.
Authentication/authorization checks at the edge can short-circuit unauthorized requests before they hit the origin.
Image/video manipulation can be done at the edge (resize, transform) cheaper than at the origin.
GeoIP-based responses — Return different content per country. CDN headers (CF-IPCountry) plus an edge function ≈ “country-aware static site.”
API gateways at the edge can rate-limit, validate, or rewrite requests before they reach origin.

For most modern web apps in 2026, “static CDN + a few edge functions for the dynamic bits” is the production sweet spot.

A Concrete Example: GeoIP at the Edge

Suppose you want to show pricing in the user’s local currency. You could:

Option A: Origin lookup

User requests /pricing → request goes to origin → origin reads CF-IPCountry → renders page → response goes back to user.

Pros: simple. Cons: every request hits origin; no CDN caching.

Option B: Client-side detection

User requests /pricing → CDN serves cached HTML → JS in browser detects locale → updates display.

Pros: cached, fast. Cons: flash of wrong content; SEO bots see default currency.

Option C: Edge function

User requests /pricing → Cloudflare Worker runs at the edge → reads CF-IPCountry → returns appropriate cached fragment.

Pros: cached and personalized at the edge. SEO bots see localized content immediately.

Option C is the edge-computing sweet spot. The function does almost nothing (read a header, pick a cache key), but the result is dramatically better than either alternative.

Cost Models

CDN pricing is typically per GB transferred: $0.005-0.08/GB depending on volume and region.

Edge function pricing is typically per request + CPU time: $0.50-2.00 per million requests + a small CPU-second charge.

Comparison for 1M requests at 100 KB average:

CDN bandwidth: 100 GB × ~$0.04 = ~$4 (varies by region/tier)
Edge function: 1M × $0.50/M = $0.50 + maybe $0.50 in CPU = $1.00

The edge function costs less per million than CDN bandwidth at small response sizes — but if your edge function calls origin, you pay both the function cost and the origin bandwidth.

For most web apps, the cost difference is negligible. Pick on capability, not price.

Architecture Patterns

Pattern 1: Static-first with edge augmentation

Build the site as static. Use a CDN. Add edge functions only where dynamic behavior is needed (auth, geo-routing, personalization).

This is the modern default. Vercel, Cloudflare Pages, Netlify, AWS Amplify all encourage this pattern.

Pattern 2: Edge as API gateway

The edge sits in front of your origin API. It handles auth, rate limiting, geo-routing, request rewriting. Origin focuses on business logic.

Used for: large SaaS, B2B APIs, anything where the API surface area is large and you want guardrails close to users.

Pattern 3: Full edge

All compute runs at the edge. Origin is just a database or storage layer. Examples: Cloudflare D1 + Workers, Deno Deploy + Postgres.

Used for: latency-critical apps with simple compute needs. Less common; works best when the storage layer is also designed for edge access.

Pattern 4: CDN-only

For static sites with no dynamic behavior. Plenty of personal sites, documentation sites, marketing pages.

What Doesn’t Belong at the Edge

Edge isn’t a place for everything. Don’t put at the edge:

Heavy computation — Edge runtimes have tight CPU limits (10-50ms per request typically). Anything that runs longer should be at origin.
Long-lived connections — Edge connections are typically stateless and short-lived. WebSocket-heavy apps usually need a dedicated origin.
Database writes that need transactions — Edge KV stores are eventual-consistency. Real transactional writes belong at origin.
Anything that needs the full Node.js standard library — Edge runtimes are subsets. Most Node packages don’t run.

The rule of thumb: edge for “fast and stateless,” origin for “complex and stateful.”

Edge + IP Geolocation

Edge functions are particularly good for IP-based decisions because the IP is already adjacent to the edge:

// Cloudflare Worker
export default {
    async fetch(request: Request, env: Env) {
        const country = request.headers.get('cf-ipcountry')
        const region = request.headers.get('cf-region')
        const city = request.headers.get('cf-ipcity')
        
        // Make routing/content decisions based on geo
        if (BLOCKED_COUNTRIES.has(country)) {
            return new Response('Not available in your region', { status: 451 })
        }
        
        return fetch(request)
    }
}

For richer signals (ASN, VPN detection), call the Ip2Geo API from the edge function. Add ~30-50ms but get the full IP intelligence stack. For details on Node-side patterns, see IP geolocation in Node.js.

The 2026 Default

For a typical modern web app:

Static frontend built with Astro/Next.js/Remix/SvelteKit.
Deployed to a CDN (Vercel, Cloudflare Pages, Netlify).
Edge functions for: auth checks, geo-personalization, A/B testing, request rewriting.
Origin API for: business logic, database writes, anything stateful.

This stack gives you global low-latency static delivery, dynamic edge logic where needed, and a clean origin for the complex bits. It’s also straightforward to deploy and scale.

TL;DR

CDN caches content near users.
Edge computing runs code near users.
Modern platforms blur the line — Cloudflare, Vercel, AWS all combine both.
Use CDN alone for static content.
Add edge functions for per-user logic that needs low latency.
Don’t put heavy compute at the edge. It’s for short, stateless operations.
IP geolocation belongs at the edge — the data is already there, latency is minimal.
For most 2026 web apps, static + CDN + a few edge functions is the right architecture.

CDN and edge computing aren’t competing — they’re layers in the same architecture. Once you internalize the difference, it becomes obvious which problems each one solves. For more on geographic personalization specifically, see geo personalization. For the IP intelligence layer that powers most edge geo decisions, the Ip2Geo API is one HTTP call away.

CDN vs Edge Computing: What's the Difference?