Cloudflare Workers vs AWS Lambda Comparison

Compute that runs on the global edge with V8 isolates, with no VM cold starts

VS
AWS Lambda

Serverless compute running on Firecracker microVMs, deeply integrated with the AWS ecosystem

17 min readBackend

Quick Verdict

There's no outright winner: for short, latency-sensitive, globally distributed request handling (auth, routing, personalization, API gateways, webhooks), Cloudflare Workers is both cheaper and has less cold-start friction. For long-running, memory-heavy work or jobs that depend on VPC-bound AWS resources, Lambda leads: its ceilings are higher and private-network access is GA — Workers' equivalent is still in beta. The most common production pattern is hybrid: Workers as a thin edge layer, Lambda handling the heavy lifting behind it.

Cloudflare WorkersAWS Lambda
Read the full verdict

Score Comparison

Loading chart...

Detailed Scoring

Detailed Scoring: Cloudflare Workers and AWS Lambda — category-by-category scores out of 10
CategoryCloudflare WorkersAWS Lambda
Performance
8/10
7/10
Ease of Learning
7/10
6/10
Ecosystem
6/10
9/10
Community
6/10
8/10
Job Market
6/10
8/10
Future-Proof
9/10
8/10

Pros & Cons

Cloudflare Workers

Pros

  • V8 isolates start roughly 100x faster than a Node process, in Cloudflare's own words
  • CPU-time-based pricing; I/O wait time is free
  • A data layer — KV, D1, R2, Durable Objects, Hyperdrive — on the same platform
  • Lightweight local development and single-command global deploys with Wrangler
  • 100,000 requests/day on the Free plan; $5 base + a generous included quota on the Paid plan
  • The workerd runtime is open source under Apache-2.0
  • Connection pooling to existing Postgres/MySQL (including AWS RDS) via Hyperdrive
  • Node.js API compatibility (e.g. node:fs) makes it easier to port existing libraries

Cons

  • CPU-time defaults to 30 sec, capped at 5 min for HTTP requests (paid) — not suited to long synchronous work
  • Memory is fixed at 128 MB and can't be increased
  • Even Cron Triggers and Queue Consumers cap a single invocation at 15 min (for Cron only at intervals of 1 hour or more; 30 s below that) — batch jobs running for hours aren't native
  • The V8 isolate model doesn't support native Node.js addons
  • CPU-time is capped at 10 ms on the Free plan; the Paid plan is required for production traffic
  • Lacks the depth of AWS's direct trigger/event source mapping; the ecosystem is narrower

Best For

Short, latency-sensitive global request handling — auth, routing, personalizationA thin layer in front of an API gateway or webhookA/B testing and response manipulation at the edgeLightweight dynamic logic adjacent to a CDNLow-latency responses for a geographically dispersed user base

AWS Lambda

Pros

  • Flexible memory configuration from 128 MB to 10,240 MB
  • Maximum runtime of 15 minutes, with a path to longer workloads via Managed Instances
  • VPC access for direct connections to private-network resources like RDS and ElastiCache
  • Native integration with AWS services — S3, DynamoDB, SQS, Kinesis, EventBridge, API Gateway, and Cognito can all trigger the function directly
  • Deep observability with CloudWatch + X-Ray
  • Broad runtime support: Node.js, Python, Java, Go, .NET, Ruby, custom runtime
  • Free tier: 1M requests + 400,000 GB-seconds/month

Cons

  • Firecracker microVM cold start is slower than a V8 isolate (reduced but not eliminated in VPC via Hyperplane ENI)
  • GB-second-based pricing; billed on memory × duration
  • A function attached to a VPC loses internet access by default — a NAT Gateway/VPC endpoint is required
  • No global PoP footprint; it runs per region and doesn't do automatic nearest-edge routing
  • Local development with SAM/CDK isn't as lightweight as Wrangler
  • The broad service-integration surface carries complexity and vendor lock-in risk

Best For

Workloads dependent on private AWS resources inside a VPC, like RDS/ElastiCacheLong-running data processing, ETL, batch/queue consumer tasksHigh-memory image/video processing or ML inferenceEvent-driven orchestration in an AWS-native architecture (S3, DynamoDB, Step Functions)Enterprise teams already deeply invested in AWS

Code Comparison

Cloudflare Workers
// Cloudflare Workers - API connecting to Postgres via Hyperdrive
import { Hono } from "hono";
import postgres from "postgres";

interface Env {
  HYPERDRIVE: Hyperdrive;
}

const app = new Hono<{ Bindings: Env }>();

app.get("/api/users/:id", async (c) => {
  // Opening a new client on every request is cheap — Hyperdrive
  // already pools connections on the platform side.
  const sql = postgres(c.env.HYPERDRIVE.connectionString, {
    max: 5,
    fetch_types: false,
  });

  // Hyperdrive cleans up the connection itself when the request ends; no need to call sql.end().
  const id = c.req.param("id");
  const rows = await sql`
    SELECT id, name, plan FROM users WHERE id = ${id} LIMIT 1
  `;

  if (rows.length === 0) {
    return c.json({ error: "not_found" }, 404);
  }

  return c.json(rows[0]);
});

export default app;

/*
wrangler.jsonc
{
  "name": "edge-api",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-01",
  "hyperdrive": [
    { "binding": "HYPERDRIVE", "id": "<hyperdrive-config-id>" }
  ]
}
*/
AWS Lambda
// AWS Lambda (Node.js) - handler connecting to RDS Postgres inside a VPC
import { Client } from "pg";

let client; // persists across container reuse (warm start)

export const handler = async (event) => {
  const id = event.pathParameters?.id;

  if (!client) {
    client = new Client({
      host: process.env.DB_HOST, // RDS private endpoint (inside the VPC)
      port: 5432,
      database: process.env.DB_NAME,
      user: process.env.DB_USER,
      password: process.env.DB_PASSWORD,
      ssl: { rejectUnauthorized: true },
    });
    await client.connect();
  }

  try {
    const result = await client.query(
      "SELECT id, name, plan FROM users WHERE id = $1 LIMIT 1",
      [id]
    );

    if (result.rows.length === 0) {
      return { statusCode: 404, body: JSON.stringify({ error: "not_found" }) };
    }

    return { statusCode: 200, body: JSON.stringify(result.rows[0]) };
  } catch (err) {
    console.error(err);
    return { statusCode: 500, body: JSON.stringify({ error: "internal" }) };
  }
};

/*
template.yaml (AWS SAM) — VPC + memory + timeout
Resources:
  UsersFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      MemorySize: 512
      Timeout: 15 # seconds (ceiling 900 = 15 min)
      VpcConfig:
        SecurityGroupIds: [sg-xxxxxxxx]
        SubnetIds: [subnet-xxxxxxxx, subnet-yyyyyyyy]
      Policies:
        - VPCAccessPolicy: {}
*/

Conclusion

There's no outright winner: for short, latency-sensitive, globally distributed request handling (auth, routing, personalization, API gateways, webhooks), Cloudflare Workers is both cheaper and has less cold-start friction. For long-running, memory-heavy work or jobs that depend on VPC-bound AWS resources, Lambda leads: its ceilings are higher and private-network access is GA — Workers' equivalent is still in beta. The most common production pattern is hybrid: Workers as a thin edge layer, Lambda handling the heavy lifting behind it.

Get Free Consultation
FAQ

Frequently Asked Questions

It depends — you need to run the numbers for your workload. The Workers Paid plan is $5/month base, including 10M requests and 30M CPU-ms, with overages at $0.30/million requests + $0.02/million CPU-ms; I/O wait time is free. Lambda charges per request plus GB-seconds (memory × duration), and its free tier includes 1M requests + 400,000 GB-seconds/month. For short, I/O-heavy work, Workers' CPU-time model can come out cheaper; for long, CPU-intensive work, Lambda's GB-second model varies by workload.

Related Blog Posts

View All Posts

Related Projects

View All Projects
All Comparisons