Global edge functions platforms with usage-based pricing: Workers vs Lambda@Edge vs Fastly Compute@Edge

Most teams evaluating global edge functions are trying to answer the same question: which platform gives us predictable performance everywhere, with usage-based pricing that won’t explode as we scale? In this guide, I’ll break down how Cloudflare Workers compares to AWS Lambda@Edge and Fastly Compute@Edge — from architecture and pricing models to real-world fit for web, API, and AI workloads.

Quick Answer: Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute@Edge all run code at the edge with usage-based pricing, but they differ sharply in global reach, pricing transparency, developer experience, and how easily they connect/protect your broader stack. Workers is part of Cloudflare’s connectivity cloud, which unifies edge compute with security, performance, and Zero Trust access on one global network.

---

The Quick Overview

• What It Is: A comparison of three global edge functions platforms — Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute@Edge — focusing on usage-based pricing, architecture, and practical fit for production workloads.
• Who It Is For: Engineering leaders, architects, and platform teams deciding where to run latency-sensitive logic, APIs, and AI inference close to users without managing servers.
• Core Problem Solved: Choosing an edge platform that delivers global performance, strong security, and predictable cost — without forcing a complex, multi-vendor patchwork of CDN, WAF, Zero Trust, and compute.

---

How It Works

All three platforms follow the same core idea: your code runs on a provider’s global network, close to users, rather than in a centralized region. Requests hit the provider’s edge; the platform executes your function, applies any configured policies, and returns a response — often before traffic ever touches your origin.

From an architecture standpoint:

1. Code Deployment to the Edge:
   You push functions (JavaScript/TypeScript, Rust, or other languages) to the provider. They propagate to data centers around the world.

2. Request Routing & Execution:
   User requests are routed through the provider’s edge network. Your function executes, often with access to key-value storage, caches, or data services.

3. Security & Observability at the Edge:
   Security controls (and, on Cloudflare, Zero Trust policies and WAF rules) are enforced at the edge, and logs/metrics are generated for every request so you can see exactly what ran, where, and why.

Where they differ is in how much of your architecture they can take on — and how pricing scales once you move from “toy projects” to real production workloads.

---

Workers vs Lambda@Edge vs Compute@Edge: Platform-by-Platform

Cloudflare Workers: Edge compute on a full connectivity cloud

Cloudflare Workers runs on Cloudflare’s global network — hundreds of cities in 125+ countries — the same network that already secures and accelerates a large share of the Internet. Workers is not just a standalone edge function service; it’s part of Cloudflare’s connectivity cloud that lets you:

• Connect users, apps, APIs, networks, and AI agents via Cloudflare One (SASE/Zero Trust).
• Protect websites, APIs, and internal apps with WAF, DDoS, bot mitigation, and Zero Trust access.
• Build at the edge with Workers, KV, D1, Queues, Durable Objects, and AI inference.

Key characteristics:

• Runtime model:

  • V8 isolates (no per-customer containers/VMs to warm up)
  • Very fast cold starts; functions feel “always warm” for most HTTP use cases
  • Standard Web APIs, Workers AI, KV, Durable Objects, R2, D1, Queues, etc.

• Network & integration:

  • Same edge that fronts your websites, APIs, and internal apps
  • Integrates with Cloudflare WAF, DDoS protection, Bot Management, CDN, and Zero Trust (Access, Gateway)
  • No inbound ports needed if you pair with Argo Tunnel — everything is outbound-only from your infrastructure

• Usage-based pricing:
  Designed so you can start small and scale without guessing capacity:

  • Free and paid usage-based tiers (requests, CPU time, data/storage usage)
  • Transparent per-request and per-resource pricing; no region-based pricing complexity
  • AI inference and data services follow similar usage-based patterns

Workers is strongest when you want edge compute that’s tightly coupled to security, performance, and Zero Trust access. Instead of bolting on a function engine to a CDN, you’re using a single platform where edge is the control plane for both requests and policies.

---

AWS Lambda@Edge: Edge functions tied to CloudFront

Lambda@Edge is an extension of AWS Lambda that runs code at CloudFront locations. It’s best understood as: “Lambda triggers that run on the CDN when CDN events fire.”

Key characteristics:

• Runtime model:

  • Based on AWS Lambda’s execution environment (per-function containers)
  • Supports Node.js and Python (with specific versions)
  • Cold starts can be more noticeable for first invocations in a region or for less-frequently-used functions

• Network & integration:

  • Only triggers via CloudFront request/response events (viewer/origin request/response)
  • Tightest fit if you’re already standardized on AWS and CloudFront
  • Security and WAF controls live in separate AWS services (AWS WAF, Shield, etc.) you must configure and manage separately

• Usage-based pricing:

  • Charged per-request and per-GB-second of compute, plus data transfer and CloudFront costs
  • Pricing can be harder to reason about because it spans multiple AWS line items (CloudFront, Lambda@Edge, data transfer, WAF, etc.)
  • Typically billed per-Region, which matters if your user base is globally distributed

Lambda@Edge is strongest if you’re all-in on AWS, already using CloudFront, and want to tweak HTTP traffic in-flight — header manipulation, auth tokens, basic personalization — but are comfortable managing security and connectivity with separate services.

---

Fastly Compute@Edge: Performance-focused edge functions on a modern CDN

Fastly Compute@Edge is a WASM-based edge compute platform sitting on top of Fastly’s high-performance CDN. It’s designed for low-latency use cases and gives you more general-purpose logic at the edge than traditional CDN configuration.

Key characteristics:

• Runtime model:

  • WebAssembly (WASM) runtime, with first-class Rust support and other languages via WASM
  • Very fast startup times due to WASM and Fastly’s optimized runtime
  • Strong fit for performance-critical workloads where you want fine-grained control

• Network & integration:

  • Tight integration with Fastly’s CDN and caching features
  • Security (WAF, DDoS, etc.) is available but not as deeply tied into identity/Zero Trust patterns as Cloudflare One
  • Requires separate solutions or integrations if you want full Zero Trust access to internal apps, SSH/RDP, or private APIs

• Usage-based pricing:

  • Pricing based on requests, compute time (CPU), and data transfer
  • Some plans bundle CDN and Compute@Edge; others bill them separately
  • As with AWS, you’ll want to model both function and delivery costs for accurate TCO

Compute@Edge is strongest if you prioritize raw performance and are deep into Fastly’s CDN ecosystem, and are comfortable layering other vendors for Zero Trust, network services, or AI-specific controls.

---

How It Works (Side-by-Side Flow)

Here’s how a typical HTTP request flows in each platform:

1. Request entry point:

   • Workers: DNS for your domain points to Cloudflare; traffic always hits Cloudflare’s global edge first. Workers execute before, instead of, or alongside origin calls.
   • Lambda@Edge: DNS points to CloudFront; CloudFront events (viewer/origin request/response) trigger Lambda@Edge functions.
   • Compute@Edge: DNS points to Fastly; Fastly service routes the request to a Compute@Edge function, which can make origin calls as needed.

2. Security & policy enforcement:

   • Workers (with Cloudflare One & Application Services):

     • WAF, DDoS, and Bot Management are applied at the edge.
     • Zero Trust policies (via Cloudflare Access) evaluate identity and context on every request for protected apps and APIs.
     • Outbound-only Argo Tunnel lets you publish apps without opening inbound ports. The Worker can sit in front, acting like a programmable bouncer.

   • Lambda@Edge:

     • AWS WAF and Shield can protect CloudFront distributions, but they’re configured and managed separately.
     • Identity-based policies typically happen in your origin, Cognito, or custom auth functions, not as a unified “Zero Trust at the edge” plane.

   • Compute@Edge:

     • Fastly’s security services can protect edge traffic; identity and Zero Trust access usually require external IdPs and separate ZTNA/SASE tools.
     • Policies are more DIY unless you invest in a broader security stack alongside Fastly.

3. Compute & data access:

   • Workers:

     • Direct access to KV, Durable Objects, D1 (SQL), R2 (object storage), Queues, and Workers AI at the edge.
     • You can build full applications — APIs, AI workflows, stateful coordination — without a separate origin.

   • Lambda@Edge:

     • Typically used as a thin layer that modifies requests/responses and forwards to regional services (Lambda, API Gateway, S3, etc.).
     • Complex data access usually happens in standard AWS regions, not at the edge itself.

   • Compute@Edge:

     • Can talk to origins and external APIs; some state patterns exist, but more complex persistent data often lives off-edge.
     • Strong for real-time transformation and routing; deeper stateful apps require additional services.

---

Features & Benefits Breakdown

Here’s how key capabilities map across the three platforms:

Core Feature	What It Does	Primary Benefit
Global Edge Network Integration	Workers run on Cloudflare’s full connectivity cloud; Lambda@Edge on CloudFront; Compute@Edge on Fastly.	Determines latency, coverage, and how much of your stack (security, performance, Zero Trust) can be unified in one place.
Usage-Based Pricing Model	Pay per request and compute time; Workers also meter data/storage/AI usage in a transparent way.	Lets you scale up and down without capacity planning; Cloudflare’s model is simpler to forecast across security + performance + compute.
Zero Trust & Security Integration	Workers tightly integrated with Cloudflare One (SASE/Zero Trust), WAF, DDoS, Bot Management. Lambda@Edge and Compute@Edge require separate services for ZTNA.	Reduces security gaps; lets you evaluate identity and context at the edge for each request instead of relying on a “trusted network.”

---

Ideal Use Cases

• Best for connectivity cloud + edge apps: Cloudflare Workers
  Because it combines edge compute with Zero Trust access, WAF, DDoS, bot protection, and a global CDN on one platform. Ideal when you want to connect, protect, and build everywhere — websites, APIs, internal apps, and AI workloads — without juggling multiple vendors.

• Best for AWS-centric architectures: AWS Lambda@Edge
  Because it is deeply integrated with CloudFront and the broader AWS ecosystem. Ideal when all your workloads, data, and security tooling are already standardized on AWS, and you primarily need request/response tweaks at the CDN layer.

• Best for performance-first CDN extensions: Fastly Compute@Edge
  Because Fastly’s WASM runtime and CDN are optimized for low latency and fine-grained control. Ideal for teams that already rely heavily on Fastly and want programmable edge behavior without moving security and Zero Trust onto the same platform.

---

Limitations & Considerations

• Cloudflare Workers limitations:

  • Non-Node-specific APIs: Workers follows a Web-standards runtime instead of a full Node.js environment, so some Node-specific libraries need adaptation.
  • Deep AWS-native integration: If your org mandates AWS-native for everything (CloudFormation, IAM-only, etc.), you’ll need to plan for cross-cloud integration.

• Lambda@Edge limitations:

  • Event model & language scope: Tied to CloudFront events with limited languages and runtime customizability.
  • Cold starts and complexity: Cold starts can be more pronounced, and you’ll manage multiple AWS services (CloudFront, Lambda@Edge, WAF, Shield, logging) to approximate a full edge platform.

• Compute@Edge limitations:

  • Language/runtime expectations: Strongest with Rust/WASM; teams unfamiliar with these may face a steeper learning curve.
  • Security and Zero Trust are not unified: You’ll likely stitch in other vendors for identity-driven access, network security, and SASE.

---

Pricing & Plans

Cloudflare, AWS, and Fastly all advertise usage-based pricing, but the operational reality differs:

• Cloudflare Workers (part of Cloudflare’s connectivity cloud):

  • Transparent per-request and per-resource pricing, plus free tiers to prototype.
  • When you move to Enterprise, you can bundle Workers with WAF, DDoS, Bot Management, Zero Trust (Cloudflare One), and Network Services — simplifying TCO across security, networking, and compute.
  • No need to manage separate hardware or backhaul traffic; the edge acts as your unified control plane.

• AWS Lambda@Edge:

  • Billed across multiple services: Lambda@Edge invocations + duration, CloudFront data transfer, and any associated AWS WAF/Shield usage.
  • Good for incremental features on top of an existing AWS stack, but cost modeling can become complex as traffic and services grow.

• Fastly Compute@Edge:

  • Usage-based model for requests, compute, and bandwidth, often combined with CDN services.
  • Attractive for high-performance CDN use cases, but you’ll still need separate line items (and vendors) for full SASE/Zero Trust and network services.

For organizations standardizing on Cloudflare as a connectivity cloud, Workers is typically adopted under the same Enterprise umbrella as Application Services and Cloudflare One, making it easier to control cost and governance at scale.

• Enterprise Plan (Cloudflare Workers & connectivity cloud): Best for organizations needing global edge compute plus unified security (WAF, DDoS, bot), Zero Trust access, and network services — with 100% uptime SLA and enterprise-grade support.
• Self-Service/Usage-Based Plans: Best for teams experimenting with Workers, building individual edge services or AI workloads, and then scaling into Enterprise as they consolidate around Cloudflare’s connectivity cloud.

---

Frequently Asked Questions

Is Cloudflare Workers cheaper than Lambda@Edge and Compute@Edge for global workloads?

Short Answer: Often yes, especially when you factor in security, DDoS, and Zero Trust requirements that would otherwise require separate services.

Details:
With AWS and Fastly, you typically pay separately for CDN, edge compute, WAF, DDoS, bot protection, and Zero Trust/ZTNA. Costs accumulate across services and vendors. Cloudflare Workers is part of a platform where:

• The same edge that runs your Workers also delivers CDN acceleration, WAF, DDoS, and Bot Management.
• Cloudflare One provides Zero Trust access, DNS filtering, and secure outbound connectivity (via Argo Tunnel) without extra hardware.
• Enterprise plans can bundle these under a single contract, often reducing total cost versus assembling and operating a multi-vendor stack.

For teams that need both edge functions and robust security, Workers’ pricing model is usually more predictable and cost-effective at scale.

---

Can I use Cloudflare Workers for AI workloads and agentic apps?

Short Answer: Yes. Workers can run AI inference at the edge and orchestrate AI agents while enforcing security and Zero Trust policies.

Details:
Cloudflare’s Developer Platform pairs Workers with Workers AI, durable storage, and orchestration tools so you can:

• Run AI inference close to users on Cloudflare’s global network.
• Orchestrate AI agents that call APIs, interact with databases, and connect to remote tools (including via secure outbound-only access to MCP servers).
• Enforce identity- and context-based policies using Cloudflare One, so every AI call is evaluated at the edge before it hits sensitive data or systems.

This is a critical difference versus Lambda@Edge or Compute@Edge, which don’t natively provide a unified “build and secure AI agents” framework integrated with Zero Trust and network services. With Workers, the edge is both your execution environment and your enforcement plane.

---

Summary

When you compare global edge functions platforms with usage-based pricing, the real decision isn’t just about per-request cost or cold start times. It’s about whether edge compute lives inside a broader, defensible architecture — one that can connect users and apps globally, protect them with consistent security controls, and give developers a place to build without operational drag.

• Cloudflare Workers sits at the center of a connectivity cloud that unifies SASE/Zero Trust (Cloudflare One), application security and performance (WAF, DDoS, bot, CDN), network services, and a developer platform for AI and edge apps — all on a single global network.
• AWS Lambda@Edge is a strong choice for AWS-centric shops that need to extend CloudFront, but you’ll stitch together multiple AWS services to achieve equivalent security and connectivity.
• Fastly Compute@Edge is compelling for performance-focused teams already invested in Fastly, but you’ll likely layer additional vendors for Zero Trust, AI security, and network modernization.

If you want edge functions to be more than a narrow feature of your CDN — to be the programmable control plane for your global architecture — Workers on Cloudflare’s connectivity cloud is designed for exactly that.

---

Next Step

Get Started