---
title: "Cloudflare Workers vs AWS Lambda"
slug: "cloudflare-workers-vs-aws-lambda"
category: "comparisons"
tags: ["comparisons", "cloudflare", "aws", "serverless", "edge", "workers", "lambda"]
status: "stable"
last_updated: 2026-09-27
summary: "Pick Workers for short, latency-sensitive request handling close to users; pick Lambda for heavy, long-running, memory-hungry, or VPC-bound functions and for runtimes beyond JavaScript and Wasm."
related: ["[[comparisons/aws-vs-cloudflare]]", "[[ops/cloudflare-workers]]", "[[ops/cloudflare-kv]]", "[[ops/cloudflare-r2]]", "[[cheatsheets/aws-cli-commands]]", "[[comparisons/vercel-vs-cloudflare]]"]
---

## Overview

Workers and Lambda are both serverless functions, but they are built on different execution models. Workers runs code in V8 isolates inside every Cloudflare location, so a request is handled near the user and isolates start fast enough that cold starts are rarely a design concern. Lambda runs each function in a Firecracker microVM inside one AWS region, which buys far more memory, longer execution, broad language support, and direct access to resources in a VPC. The choice follows the workload shape more than the vendor. For the wider platform decision, see [[comparisons/aws-vs-cloudflare]].

## When Workers wins

Choose Workers when the function is short, runs on every request, and benefits from being close to the user.

- Latency-sensitive request handling: auth checks, redirects, header rewrites, A/B bucketing, geolocation routing, and API gateways in front of an origin.
- Global by default: one deploy runs in every Cloudflare location. Lambda runs in the regions you deploy to; Lambda@Edge replicates to CloudFront regional edge caches but supports fewer runtimes and tighter limits.
- Billing on CPU time: Workers bills requests plus CPU time, so time spent waiting on a slow upstream fetch costs little. Lambda bills wall-clock duration multiplied by configured memory.
- Edge storage bindings: KV, R2, D1, Durable Objects, and Queues attach to a Worker as bindings without network configuration. See [[ops/cloudflare-kv]] and [[ops/cloudflare-r2]].

## When Lambda wins

Choose Lambda when the function is heavy, long, or needs to live next to AWS resources.

- Memory and duration: Lambda allows up to 10,240 MB of memory and a 15-minute timeout. A Worker isolate has 128 MB of memory and a CPU-time limit (30 seconds by default on paid plans, configurable up to 5 minutes).
- Runtimes: Lambda supports Node.js, Python, Java, .NET, Ruby, custom runtimes, and container images. Workers is JavaScript, TypeScript, and Wasm first, with Python support still maturing.
- VPC access: Lambda functions can attach to a VPC and reach RDS, ElastiCache, or internal services directly. A Worker reaches private resources through Cloudflare Tunnel or Hyperdrive instead.
- Event sources: Lambda is the native handler for S3 events, DynamoDB streams, SQS, EventBridge, and Kinesis.

## Trade-offs at a glance

| Dimension        | Cloudflare Workers                      | AWS Lambda                                  |
| ---------------- | --------------------------------------- | ------------------------------------------- |
| Execution model  | V8 isolates                             | Firecracker microVMs                        |
| Placement        | Every Cloudflare location               | Chosen AWS regions                          |
| Memory           | 128 MB per isolate                      | 128 MB to 10,240 MB                         |
| Time limit       | CPU-time limit, up to 5 min             | Up to 15 min wall clock                     |
| Billing basis    | Requests plus CPU time                  | Requests plus duration times memory         |
| Languages        | JS, TS, Wasm; Python maturing           | Node, Python, Java, .NET, Ruby, containers  |
| Private networks | Tunnel, Hyperdrive                      | Native VPC attachment                       |

## Migration cost

Porting from Lambda to Workers is a rewrite of the handler, not a redeploy.

- Rewrite each handler to the Workers `fetch` API. Enable the `nodejs_compat` flag for Node.js built-ins; dependencies with native modules must be replaced.
- Split work that exceeds the CPU or memory limits into Queues or Durable Objects, or leave it on Lambda.
- Replace direct VPC access with Hyperdrive for databases or Cloudflare Tunnel for internal services.

## Recommendation

- Request middleware, edge redirects, personalization, and API gateways: Workers.
- Image, video, or ML jobs that need gigabytes of memory or minutes of runtime: Lambda.
- Functions triggered by AWS events or bound to a VPC database: Lambda.
- A new app on Cloudflare's storage primitives: Workers end to end, with Lambda only for the heavy jobs.

## Related

- [[comparisons/aws-vs-cloudflare]]
- [[ops/cloudflare-workers]]
- [[ops/cloudflare-kv]]
- [[ops/cloudflare-r2]]
- [[cheatsheets/aws-cli-commands]]
- [[comparisons/vercel-vs-cloudflare]]