Cloudflare Workers vs AWS Lambda vs Vercel Functions

The Serverless Landscape Shifted While You Were Shipping Features

Two years ago, picking a serverless platform was straightforward. You were probably choosing between AWS Lambda and whatever your frontend framework pushed you toward. Lambda had the ecosystem, the integrations, the battle scars of a decade in production.

That calculus has changed. Cloudflare Workers went from “neat toy for edge redirects” to a legitimate application platform. Vercel killed off its Edge Functions branding and rolled everything into Fluid Compute. And Lambda, the incumbent, added ARM pricing and SnapStart to stay competitive on the two things people actually complained about: cost and cold starts.

If you’re starting a new project today, you have a real choice to make. And the wrong one can lock you into an architecture that either costs too much at scale or can’t handle your workload at all. I’ve run production traffic on all three, and the answer isn’t as obvious as the marketing pages suggest.

How They Actually Work Under the Hood

These three platforms don’t just differ in pricing. They’re built on fundamentally different isolation models, and that shapes everything from cold start behavior to what languages you can use.

Cloudflare Workers: V8 Isolates

Workers don’t spin up containers. They run your code inside V8 isolates — the same JavaScript engine that powers Chrome. Think of it like running thousands of tiny scripts inside a single process, each in its own sandbox. No filesystem, no native binaries, no full Node.js runtime. Just JavaScript, TypeScript, and WebAssembly.

The upside? Isolate creation takes less than a millisecond. There’s effectively no cold start. Your code runs on whichever Cloudflare PoP is closest to the user, across 300+ locations worldwide.

The downside? You’re constrained. 128MB memory. CPU time limits (10ms on the free plan, 30 seconds on paid). No Python. No Java. No spawning processes. If your workload doesn’t fit in that box, Workers physically can’t run it.

AWS Lambda: MicroVMs via Firecracker

Lambda runs each function invocation inside a Firecracker microVM — a lightweight virtual machine that boots in ~125ms. You get a full Linux environment with the runtime of your choice: Node.js, Python, Java, Go, Ruby, .NET, or custom runtimes via container images.

You can allocate up to 10GB of memory and run for up to 15 minutes per invocation. That’s enormous flexibility compared to Workers. But it comes with the cold start tax. A Node.js function typically sees 100-300ms cold starts. Java? Easily 1-3 seconds unless you’re using SnapStart. And your function runs in a single AWS region unless you set up Lambda@Edge or replicate across regions yourself.

Vercel Functions: Lambda Under a Better DX Layer

Here’s what Vercel doesn’t always make obvious: their serverless functions are AWS Lambda functions. Vercel is a deployment platform that provisions and manages Lambda on your behalf, with tighter integration into Next.js and other frameworks.

The old “Edge Functions” product (which ran on Cloudflare’s network, ironically) is deprecated. Vercel now pushes everything toward their Fluid Compute model on the Node.js runtime, which adds smart optimizations like connection reuse and active CPU billing on top of Lambda’s infrastructure.

So when comparing Vercel to Lambda, you’re largely comparing a managed Lambda experience with better DX against raw Lambda with more control. The underlying compute model is similar.

Cold Starts: The Gap Is Enormous

This is where Cloudflare Workers absolutely dominates, and it’s not close.

Workers’ sub-5ms cold starts aren’t a benchmark trick. V8 isolates genuinely start that fast because there’s no VM to boot, no runtime to initialize. The “cold” path and “warm” path differ by single-digit milliseconds.

For Lambda, AWS has made improvements. SnapStart (currently Java-only) pre-snapshots your function state, cutting cold starts by up to 90%. Provisioned concurrency eliminates cold starts entirely but costs you money for keeping instances warm 24/7. These are workarounds for an architectural limitation, not a fix.

For a globally distributed API where p99 latency matters, Workers wins by default. A user in Tokyo hitting a US-East Lambda sees 150-200ms of network latency before the cold start even factors in. That same request to Workers resolves at the Tokyo PoP in under 50ms total.

But cold starts aren’t everything. If your function runs for 10 seconds processing a file upload, a 200ms cold start is noise.

Pricing: The Math Gets Interesting at Scale

Serverless pricing is notoriously hard to compare because every platform bills differently. Let me break it down at three scale points.

Cloudflare Workers

• Base: $5/month
• Included: 10 million requests, 30 million CPU-milliseconds
• Overage: $0.30 per million requests + $0.02 per million CPU-ms
• Egress: Free. Always.

AWS Lambda (x86, us-east-1)

• Requests: $0.20 per million (1M free/month)
• Compute: $0.0000166667 per GB-second (400,000 GB-seconds free/month)
• Egress: $0.09/GB after first 100GB/month
• ARM (Graviton): 20% cheaper on compute

Vercel Functions (Pro Plan)

• Base: $20/month per team member
• CPU: $0.128 per CPU-hour (active CPU only)
• Memory: $0.0106 per GB-hour
• Bandwidth: 1TB included, then $0.15/GB

Scenario: 1 Million Requests/Month

A lightweight API averaging 5ms CPU time per request.

At this scale, Lambda’s free tier makes it essentially free. Workers costs $5 flat. Vercel’s per-seat pricing makes it the most expensive option for small workloads.

Scenario: 10 Million Requests/Month

Same lightweight API at 10x scale.

Workers’ flat $5 is remarkable here. You’re getting 10 million requests for the cost of a latte. Lambda scales linearly. Vercel’s base price dominates.

Scenario: 100 Million Requests/Month

Now things get real. Same API, 100M requests.

At 100M requests, Workers is roughly 4.5x cheaper than Lambda for lightweight, CPU-efficient workloads. The key word there is “lightweight.” If your functions are CPU-heavy or memory-hungry, the comparison shifts dramatically because Workers caps you at 128MB.

The Hidden Cost: Egress

This is Lambda’s dirty secret. Every byte that leaves AWS costs money — $0.09/GB after the first 100GB. For an API returning 10KB responses at 100M requests/month, that’s roughly 1TB of egress, costing about $82 on top of your compute bill. Cloudflare charges zero for egress. Always. That alone can make Workers the cheaper option even if compute costs are similar.

Runtime Support: Where Workers Hits a Wall

Here’s the trade-off nobody mentions in the “Workers is amazing” blog posts.

If you need to process images with Sharp, run a Python ML model, or connect to an RDS instance inside a VPC — Workers can’t do it. You’re limited to what runs in a V8 isolate with HTTP-only database access.

Lambda gives you a full Linux box. You can install whatever you want via layers or container images. That flexibility matters when your function needs to do more than route requests and transform JSON.

Vercel sits in the middle. You get a Node.js runtime with most standard capabilities, minus the raw control of Lambda. The DX is excellent if you’re in the Next.js ecosystem, but you’re paying for that abstraction.

The CPU Trap: When Edge Computing Backfires

There’s a pattern I see constantly: a team reads about Workers’ zero cold starts and global distribution, migrates their API, and then gets a surprise bill because their functions are CPU-intensive.

Workers bills on CPU time, and the limits are tight. If your function does anything computationally heavy — parsing large JSON payloads, running crypto operations, compressing data — you’ll burn through your 30 million CPU-milliseconds fast. The free plan’s 10ms CPU limit per invocation means even moderate computation can fail.

Edge computing is optimal for:

• Request routing and URL rewriting
• Auth token validation (JWT decoding)
• A/B testing and feature flagging
• API response transformation
• Caching logic and cache key computation
• Geolocation-based content serving

Edge computing is a poor fit for:

• Image/video processing
• PDF generation
• Data aggregation from multiple backend sources
• ML inference (even lightweight models)
• Anything requiring more than 128MB memory
• Long-running background jobs

The mental model is: if your function spends most of its time waiting on I/O (database queries, API calls, reading from KV), Workers is cheap and fast. If it spends most of its time computing, Lambda’s pay-per-GB-second model scales better because you can throw memory at the problem.

The Hybrid Play: Per-Route Runtime Selection

The real answer for most teams isn’t picking one platform. It’s using each where it’s strongest.

Next.js and other modern frameworks support per-route runtime selection. You can mark lightweight middleware routes to run at the edge while keeping heavy API routes on Node.js:

// app/api/auth/route.ts — runs at the edge, sub-5ms globally
export const runtime = 'edge';
 
export async function GET(request: Request) {
  const token = request.headers.get('authorization');
  // Fast JWT validation, return user context
}

// app/api/reports/route.ts — needs full Node.js
export const runtime = 'nodejs';
 
export async function POST(request: Request) {
  // Heavy data processing, PDF generation, etc.
}

If you’re on Vercel, this is built-in. If you’re self-managing, you can architect the same pattern with Cloudflare Workers handling the edge layer and proxying heavy requests to Lambda behind an API Gateway.

Cloudflare’s own ecosystem is building toward making this less necessary. D1 (SQLite at the edge), R2 (S3-compatible storage), Queues, and Durable Objects are all designed to keep more of your stack on Workers. But the ecosystem is still younger than AWS’s, and you’ll hit gaps.

Developer Experience: The Soft Stuff Matters

Numbers aside, how these platforms feel day-to-day matters more than most comparisons admit.

Cloudflare Workers has excellent tooling. Wrangler (the CLI) handles local development, deployment, and log tailing. wrangler dev gives you a local environment that closely matches production. Deployments take seconds, not minutes. The dashboard is clean. But debugging in production can be frustrating — you don’t get a shell, you don’t get breakpoints, and console.log shipped to Workers Logpush is your main observability tool.

AWS Lambda is powerful but sprawling. You’re managing IAM roles, API Gateway configurations, CloudWatch log groups, VPC settings, and layer versions. The deployment story without a framework like SAM or SST is genuinely painful. But when something goes wrong, you have X-Ray tracing, CloudWatch Insights, and the ability to SSH into a related EC2 instance to reproduce issues. The ecosystem depth is unmatched.

Vercel has the smoothest DX of the three, especially if your project is a Next.js app. Push to Git, get a preview deployment in 30 seconds. Environment variables, domains, and analytics are one dashboard away. The trade-off is control: when you need to customize the underlying Lambda configuration, tweak VPC settings, or use non-standard runtimes, you’re fighting the platform.

The Vendor Lock-In Question

Switching costs vary more than you’d expect.

Workers lock-in is moderate. Your JavaScript code is portable, but if you’re using D1, KV, R2, Durable Objects, or Queues, those are Cloudflare-specific. Migrating off means rewriting your data layer.

Lambda lock-in varies. If you’re using Lambda with API Gateway, DynamoDB, SQS, and Step Functions, you’re deep in the AWS ecosystem. But the function code itself is just code — it runs anywhere that has a Node.js/Python/whatever runtime.

Vercel lock-in is high for Next.js projects that use Vercel-specific features (ISR caching, image optimization, analytics). Lower for generic serverless functions, but then you’re paying for DX you could get cheaper elsewhere.

The practical answer: if you’re building a startup that needs to ship fast, pick the platform that matches your stack and worry about migration when you’re profitable. If you’re an enterprise, the multi-cloud story matters, and Lambda’s standardized container-based approach is the most portable.

Decision Matrix: Cut Through the Noise

What I’d Pick for a New Project

If I’m building an API-first product that serves a global audience, I’d start with Cloudflare Workers. The pricing is aggressive, the cold start story is unbeatable, and the platform has matured enough that D1 + R2 + KV cover most data needs. I’d only reach for Lambda when I hit Workers’ constraints — and I’d architect the boundary cleanly from the start.

If I’m building a Next.js app for a startup, Vercel is the obvious choice. The DX wins compound over months. You’ll ship features faster, and the cost premium over self-hosted Lambda is less than what you’d spend on DevOps time configuring everything yourself.

If I’m in an enterprise with existing AWS infrastructure, Lambda is still the default. The ecosystem integration is too deep to ignore, and the cold start problem is manageable with provisioned concurrency or SnapStart.

The worst decision? Picking one platform religiously and forcing every workload through it. Use edge where edge makes sense. Use heavy compute where heavy compute makes sense. The serverless platforms have made it easier than ever to mix and match — take advantage of that.