| Myth | Reality |
|---|---|
| “Edge compute” means the same thing across every vendor. | Cloudflare Workers, Fastly Compute, and CloudFront Functions have different runtimes (V8 isolates vs. WebAssembly vs. a restricted JS sandbox), which changes what code can actually run at the edge. |
| Cold starts are a solved problem everywhere. | Cloudflare’s V8 isolate model and Fastly’s Wasm sandbox largely eliminate traditional cold starts, but Lambda@Edge still spins up container-based execution environments that can add tens to hundreds of milliseconds on cold paths. |
| Edge platforms are just for caching static files. | Modern edge platforms run full application logic, coordinate state with Durable Objects or KV, execute WASM-compiled languages, and even proxy AI inference requests. |
| The cheapest per-request price always wins. | Egress fees, request multipliers for WebSockets, and storage billing for stateful primitives can flip the “cheap” platform into the expensive one at scale. |
| You must pick one edge vendor and commit fully. | Most production architectures in 2026 mix a CDN-native edge layer for routing/auth with a hyperscaler edge service for deeper integration with origin services. |
Edge computing has quietly become one of the most consequential shifts in cloud architecture. Instead of every request travelling to a single regional data center, logic now runs in points of presence (POPs) scattered across 100+ cities, shaving tens of milliseconds off response times and, in some designs, eliminating a full origin round trip entirely. But “edge” is not one product — it is a family of runtimes with wildly different execution models, pricing structures, and operational tradeoffs. This guide compares the three major approaches available in 2026: Cloudflare’s Workers and Durable Objects, Fastly’s Compute platform, and the edge offerings built into AWS, Azure, and Google Cloud.
What “Edge Cloud” Actually Means in 2026
At its core, an edge cloud platform lets you deploy application code to a distributed network of servers positioned close to end users, rather than to a single region. The three dominant architectural patterns are:
- Isolate-based runtimes — Cloudflare Workers uses V8 isolates (the same technology that sandboxes tabs in Chrome) to start new execution contexts in sub-millisecond time, without booting a full OS process or container.
- WebAssembly sandboxes — Fastly Compute compiles Rust, JavaScript (via a compiler toolchain), Go, and other languages to WebAssembly, executing them in a sandbox that Fastly and independent benchmarks describe as achieving startup times in the tens-of-microseconds range with no traditional cold start.
- Hyperscaler edge extensions — AWS, Azure, and Google Cloud extend their existing CDN and compute stacks outward. AWS offers CloudFront Functions (a restricted, ultra-lightweight JS runtime) and Lambda@Edge (a fuller Lambda environment running at edge locations); Azure has moved from a pure CDN model to Front Door edge actions running lightweight JavaScript through a Hyperlight-based runtime; Google routes edge-adjacent workloads through Cloud Run and Cloud CDN with regional placement rather than a dedicated global edge runtime.
The practical difference between these models shows up the moment you need to hold state, run a long computation, or fan out to dozens of regions simultaneously. A stateless header rewrite behaves almost identically everywhere. A stateful multiplayer session, a real-time collaboration document, or a per-user rate limiter reveals which platform was actually designed for the edge and which one is retrofitting a regional service to look like an edge service.
Cloudflare Workers and Durable Objects
Cloudflare’s edge platform is built around Workers — JavaScript, TypeScript, Rust, and other languages compiled to run inside V8 isolates across Cloudflare’s network of 330+ cities. Because isolates share a process and skip container or VM boot time, Cloudflare has consistently marketed near-zero cold start latency, and independent developer benchmarks generally confirm sub-5ms startup even on a cold isolate.
The more architecturally significant piece is Durable Objects: a single-instance, strongly consistent compute primitive that lets you pin state (in-memory or backed by SQLite storage) to one location and route all requests for a given key to that same instance. This solves a problem that pure edge functions cannot — coordinating state across a distributed network — and it underpins use cases like collaborative editors, WebSocket-based chat, rate limiting, and per-tenant data isolation. Cloudflare’s own documentation confirms Durable Objects billing includes a request charge plus duration charges, with WebSocket messages billed at a 20:1 incoming-message ratio, and SQLite-backed storage billing rolling out on its own schedule separate from compute billing — details worth checking directly before committing an architecture to them.
Where Cloudflare’s model shows its seams: isolates share a runtime process, so extremely CPU-heavy or memory-heavy workloads face tighter limits than a full container would allow, and languages outside the V8/WASM-compilable set need more workarounds. Teams building their first Cloudflare-fronted deployment often pair Workers with a broader content-delivery setup; our step-by-step walkthrough on how to implement a CDN for your website using cloud platforms covers the caching layer that typically sits alongside Worker-based logic.
Fastly Compute
Fastly took a different technical bet: compile everything to WebAssembly and run it inside Fastly’s own sandboxing runtime (built on the Bytecode Alliance’s Wasmtime lineage). The pitch is that WASM’s sandbox model can start an isolated instance in microseconds rather than milliseconds, because there’s no interpreter warm-up or isolate spin-up — the binary is already compiled to a portable, verifiably safe format before it ever reaches a POP.
In practice, this gives Fastly Compute genuinely fast execution for CPU-bound edge logic — image manipulation, A/B testing logic, request validation, and API composition — and it supports a growing set of source languages (Rust, JavaScript/TypeScript via the Fastly JS SDK, Go). The tradeoff is coverage: Fastly’s POP footprint is smaller and less globally dense than Cloudflare’s or the big three hyperscalers, so regions with thin Fastly presence (parts of APAC in particular) see markedly higher latency than the US or EU paths where Fastly is strong. Fastly Compute pricing has typically been structured around a request-based model, with compute request pricing point around $0.50 per million requests in most published 2026 rate cards, plus a free-tier allotment for evaluation and low-traffic services.
AWS Edge: Lambda@Edge and CloudFront Functions
AWS splits edge compute into two distinct products rather than one, and picking the wrong one is the single most common AWS edge mistake. CloudFront Functions is a deliberately restricted JavaScript runtime: sub-millisecond execution, a 1MB code size cap, no network or filesystem access, and support limited to viewer-request and viewer-response trigger points. It is built for URL rewrites, header manipulation, simple authorization checks, and A/B test bucketing — nothing that needs to reach outside the request/response objects.
Lambda@Edge is a genuinely different animal: it runs a fuller Lambda execution environment replicated to CloudFront edge locations, supports origin-request and origin-response triggers (so it can talk to origins, external APIs, or other AWS services), and allows execution up to 30 seconds for origin-facing triggers. That capability comes at a real cost in both latency and price — published comparisons put CloudFront Functions at roughly 6x cheaper per invocation than Lambda@Edge for simple operations, with the price and latency gap widening further at high volume. If your logic only needs to look at headers and rewrite paths, CloudFront Functions is almost always the right default; escalate to Lambda@Edge only once you need origin connectivity, longer execution, or a full Node.js/Python runtime. Teams new to the AWS edge stack may want to start with our guide to launching a first AWS cloud app before layering edge functions on top of a working origin.
Azure Front Door and Cloud Run at the Edge
Microsoft’s edge story has shifted meaningfully in the past year. Azure Front Door historically offered routing, WAF, and caching without a true programmable edge runtime, pushing custom logic back to regional App Service or Functions deployments. Front Door edge actions change that: they let teams author lightweight JavaScript that executes as part of Front Door’s own request pipeline, using a Hyperlight-based micro-virtualization runtime that isolates each customer’s code to a single instance for blast-radius control. As of 2026 this capability is in public preview, which matters for production planning — teams building on it today should expect API surface and limits to keep evolving.
Google Cloud takes a distinctly different position: rather than shipping a dedicated global edge-function runtime to match Cloudflare or Fastly, Google leans on Cloud Run’s fast container cold starts combined with Cloud CDN and, for latency-sensitive regional placement, multi-region Cloud Run deployment plus Global external Application Load Balancer routing. This is not “edge” in the Workers/Compute sense — it’s regional compute placed strategically and fronted by a global anycast load balancer — but for teams already standardized on Cloud Run and container-based deployment, it avoids maintaining a second, WASM-flavored codebase just for edge logic.
| Platform | Runtime model | Cold start | Statefulness | Best fit |
|---|---|---|---|---|
| Cloudflare Workers + Durable Objects | V8 isolates | Sub-5ms typical | Native (Durable Objects, KV, D1) | Global apps needing coordinated state |
| Fastly Compute | WebAssembly sandbox | Microseconds, effectively none | Limited; relies on external stores | CPU-bound request transforms, API composition |
| AWS CloudFront Functions | Restricted JS sandbox | Sub-millisecond | None | Header/URL rewrites, simple auth checks |
| AWS Lambda@Edge | Full Lambda container | Tens–hundreds of ms (cold) | Via other AWS services | Origin-facing logic needing AWS integration |
| Azure Front Door edge actions | Hyperlight micro-VM | Low, preview-stage data | None built-in | Azure-native routing/WAF customization |
| Google Cloud Run (regional edge pattern) | gVisor container | Sub-second, improving | External (Firestore, Memorystore) | Teams standardized on containers/Cloud Run |
Figure 1: Request Path Comparison
A stateless request (e.g., a header rewrite) on Cloudflare or Fastly resolves entirely inside the nearest POP: client to POP, function executes, response returns — one round trip. A Lambda@Edge origin-request trigger adds a hop: client to POP, function executes, POP forwards to origin, origin responds, POP returns to client — two round trips minimum, with the added latency of full Lambda environment initialization on a cold path. Google’s Cloud Run pattern typically resolves at a regional edge, not a POP, so the “edge” hop is really a well-placed regional data center behind a global load balancer.
Illustrative request-path diagram: fewer hops generally correlate with lower and more predictable tail latency, but only for genuinely stateless logic.
Latency and Cold Starts, Compared Head-to-Head
Latency at the edge is really two separate numbers: how fast a warm function responds, and how much a cold start adds on the first invocation in a given location. Cloudflare’s isolate model and Fastly’s WASM sandbox both largely collapse that distinction — warm and cold performance are close enough that most teams never notice the difference in production traffic graphs. Lambda@Edge is the outlier: because it provisions a more complete execution environment, cold invocations in a rarely-hit region can add a noticeable latency spike, which is why AWS’s own guidance steers simple logic toward CloudFront Functions first.
Geographic density also matters more than raw architecture. Fastly’s smaller POP footprint means its microsecond-scale cold start advantage doesn’t always translate into the lowest end-to-end latency in every region — a nearby Cloudflare or CloudFront POP can beat a distant Fastly POP even with a technically slower runtime, simply because the physical round trip is shorter. When evaluating platforms, benchmark from your actual user geography, not from a vendor’s home region. Edge AI inference workloads make this even more visible, since round-trip time compounds with model execution time; our deep dive on processing AI data on-device at the edge looks at how that latency budget gets allocated in practice.
Pricing Models Compared
Edge pricing rarely reduces to a single number, and comparing “$X per million requests” across vendors without reading the fine print is the fastest way to get a nasty invoice surprise. A few structural differences matter most:
| Platform | Base pricing unit | Notable multipliers/fees |
|---|---|---|
| Cloudflare Workers Paid plan | $5/mo minimum, includes request + GB-second allotment | Durable Objects add $0.15/M requests plus duration; WebSocket messages billed 20 incoming = 1 request |
| Fastly Compute | ~$0.50 per million requests (typical published rate) | Separate charges for bandwidth/CDN delivery outside compute |
| AWS CloudFront Functions | Per-invocation, lowest of the AWS edge options | Roughly 6x cheaper than Lambda@Edge per invocation at comparable scale |
| AWS Lambda@Edge | Per-invocation + duration, standard Lambda-style | Pricing gap vs. CloudFront Functions widens to roughly 10:1 at very high volume |
| Azure Front Door edge actions | Preview; consumption-based pricing expected at GA | Bundled with Front Door tier (Standard vs. Premium) considerations |
The recurring lesson across all five platforms: request count is rarely the whole story. Storage billing (Durable Objects SQLite), bandwidth/egress, WAF or security add-ons, and tier minimums (Cloudflare’s $5/mo Workers Paid floor) all shift the real bill. Model your actual traffic shape — including WebSocket-heavy or long-tail geographic traffic — before signing a contract based on the headline rate. This kind of pricing due diligence matters across cloud services generally, not just at the edge, as we’ve noted in our broader look at how cloud computing is reshaping the IT industry.
Developer Experience and Language Support
Cloudflare’s Wrangler CLI and dashboard-first workflow, paired with broad JavaScript/TypeScript support and a growing WASM story for Rust and Python (via Pyodide-based workers), give it the most mature standalone developer experience of the group. Fastly’s Compute SDKs cover Rust natively and JavaScript/TypeScript through its own toolchain, and its local testing story (Viceroy, a local Wasm test harness) is well-regarded among teams that already ship Rust services. AWS’s edge tools inherit the broader AWS developer experience — CloudFront Functions and Lambda@Edge are both configured through the same console, CDK, or Terraform workflows teams already use for the rest of their AWS estate, which is a real advantage for teams that don’t want a second toolchain. Azure’s edge actions, still in preview, currently trail the other three on tooling maturity and public documentation depth, which is expected for a feature that only recently moved out of internal testing.
- Step 1Classify your workload as stateless (rewrites, redirects, auth checks) or stateful (sessions, coordination, real-time collaboration).
- Step 2If stateless and simple, default to the cheapest, lowest-latency option available on your existing CDN — CloudFront Functions on AWS, a lightweight Worker on Cloudflare, or Fastly Compute if you’re already on Fastly.
- Step 3If stateful, evaluate Cloudflare Durable Objects first — it is the most mature purpose-built primitive for pinned, coordinated edge state as of 2026.
- Step 4Benchmark cold-start and warm latency from your actual user geographies, not vendor-published averages.
- Step 5Model total cost including storage, WebSocket multipliers, and egress — not just the headline per-million-request price.
- Step 6Pilot on a non-critical route in production before migrating core request paths, and keep an origin fallback path during rollout.
Use Cases: Which Platform Fits Which Job
Personalization and A/B testing at the request layer favor Cloudflare Workers or CloudFront Functions — both are cheap enough and fast enough to run on nearly every request without meaningfully affecting page load. Real-time collaboration tools, multiplayer backends, and per-user rate limiting favor Cloudflare Durable Objects, because the alternative — routing every stateful check back to a regional database — reintroduces the latency edge compute was supposed to remove. API composition, image transformation, and other CPU-bound transforms play to Fastly Compute’s WASM performance profile. Teams deeply embedded in a single hyperscaler, with existing IAM, VPC, and service-mesh investments, often get more value from Lambda@Edge or Azure Front Door edge actions simply because the integration cost of a second vendor outweighs the marginal latency gain from a “purer” edge platform. Organizations wrestling with multi-cloud and data-residency constraints on top of these choices may also want to review our guide on multi-cloud and sovereign cloud orchestration, since edge platform selection increasingly intersects with data-sovereignty requirements.
Common Mistakes
- Defaulting to Lambda@Edge for simple header rewrites when CloudFront Functions would be an order of magnitude cheaper and faster.
- Assuming Fastly’s microsecond cold-start numbers translate to the lowest latency everywhere, ignoring thinner POP coverage in some regions.
- Building stateful logic (rate limiters, session counters) as plain edge functions that call back to a central database on every request, negating the latency benefit.
- Ignoring Durable Objects storage billing changes and WebSocket message multipliers until the first surprising invoice arrives.
- Treating Azure Front Door edge actions as GA-stable when the feature is still in public preview with an evolving API surface.
- Skipping geography-specific latency testing and relying solely on vendor marketing benchmarks run from well-covered regions.
In Practice
Teams that get edge architecture right in 2026 rarely bet on a single vendor for everything. A common pattern: Cloudflare sits in front as the CDN and WAF layer, handling bot mitigation, caching, and lightweight personalization at the Worker layer; a Durable Object backs any feature needing coordinated state, like collaborative document editing or per-tenant rate limits; and origin-facing business logic that needs deep AWS integration — database access, queue publishing, IAM-scoped calls — stays on Lambda@Edge or moves fully into a regional Lambda behind API Gateway, rather than forcing everything into the edge layer just because it’s fashionable. The discipline is knowing which 20% of requests actually benefit from edge execution and which 80% are better served by a fast, well-cached path to a regional origin.
Glossary
- Point of Presence (POP)
- A physical or logical edge location where a CDN or edge compute provider terminates client connections and, in many cases, executes code close to the user.
- V8 Isolate
- A lightweight JavaScript execution context based on the V8 engine, used by Cloudflare Workers to start new code contexts without booting a full container or VM.
- WebAssembly (WASM)
- A portable, sandboxed binary format that multiple source languages can compile to, used by Fastly Compute to achieve near-instant startup.
- Durable Object
- A Cloudflare primitive that pins a single instance of state to one location, giving strongly consistent coordination for a given key across a distributed edge network.
- Cold Start
- The extra latency incurred the first time a function executes in a given location because its runtime environment must be initialized.
- Origin
- The backend server or service that a CDN or edge platform forwards requests to when it cannot resolve a request from cache or edge logic alone.
- Anycast Routing
- A network routing technique that directs a client to the topologically nearest available server sharing the same IP address, commonly used to route users to the nearest edge POP.
Key Takeaways
- Cloudflare Workers and Durable Objects remain the strongest choice for globally distributed, stateful edge applications in 2026.
- Fastly Compute delivers the fastest raw execution start times via WebAssembly, but its smaller POP footprint can offset that advantage in under-covered regions.
- AWS splits edge compute into two products — CloudFront Functions for lightweight, cheap logic and Lambda@Edge for origin-facing, integration-heavy logic — and picking the wrong one is a common costly mistake.
- Azure Front Door edge actions bring programmable edge logic to Azure via a Hyperlight micro-VM runtime, but the feature is still in public preview as of 2026.
- Google Cloud favors a regional Cloud Run plus global load balancer pattern over a dedicated global edge-function runtime.
- Pricing comparisons must account for storage billing, WebSocket multipliers, and egress fees, not just the advertised per-million-request rate.
- Most mature 2026 architectures combine platforms — a CDN-native edge layer for routing and light logic, paired with a hyperscaler service for deep backend integration.
FAQs
What is the main difference between Cloudflare Workers and Fastly Compute?
Cloudflare Workers runs code in V8 isolates, giving it broad JavaScript/TypeScript support and native stateful primitives like Durable Objects. Fastly Compute runs WebAssembly binaries compiled from Rust, JS, or Go, offering extremely fast raw execution but a smaller global POP footprint and less built-in state management.
Should I use Lambda@Edge or CloudFront Functions for a simple redirect?
Use CloudFront Functions. It is purpose-built for lightweight, sub-millisecond operations like redirects and header rewrites, and it costs roughly six times less per invocation than Lambda@Edge for equivalent simple logic at comparable scale.
Does Fastly Compute really have zero cold starts?
Fastly’s WebAssembly sandbox largely eliminates traditional cold-start delay, with startup times reported in the tens-of-microseconds range in vendor and marketplace documentation. In practice, network distance to the nearest Fastly POP often matters more to end-to-end latency than this near-zero startup time.
Is Azure Front Door’s edge compute ready for production?
As of 2026, Azure Front Door edge actions are in public preview. Teams can experiment and prototype, but should expect the API surface, limits, and pricing model to continue evolving before general availability.
Why doesn’t Google Cloud have a direct Workers or Compute equivalent?
Google has instead invested in fast-starting Cloud Run containers combined with global load balancing and Cloud CDN, favoring regional compute placement over a dedicated isolate- or WASM-based global edge runtime like Cloudflare’s or Fastly’s.
What is a Durable Object used for?
A Durable Object pins a single, strongly consistent instance of application state to one location, so all requests for a given key — a chat room, a document, a rate-limit counter — are coordinated through the same instance rather than racing across a distributed system.
How should I estimate real edge compute costs before committing?
Model your actual traffic mix, including request volume, WebSocket message counts, expected storage usage for any stateful primitives, and egress bandwidth — then compare against each vendor’s full pricing page rather than a single advertised per-million-request number.
Can I use multiple edge platforms together?
Yes, and many production architectures do — using Cloudflare or Fastly for CDN-layer routing and lightweight logic while routing deeper, integration-heavy business logic to a hyperscaler’s edge or regional compute service that already has access to the rest of that cloud’s ecosystem.
References
- Cloudflare. “Workers Pricing.” developers.cloudflare.com/workers/platform/pricing
- Cloudflare. “Durable Objects.” developers.cloudflare.com/durable-objects
- Fastly. “Edge Compute.” fastly.com/products/edge-compute
- AWS. “Choosing Between CloudFront Functions and Lambda@Edge.” docs.aws.amazon.com
- Microsoft. “Introducing Azure Front Door Edge Actions.” techcommunity.microsoft.com
- Google Cloud. “Cloud Run Documentation.” cloud.google.com/run/docs
