AWS Lambda vs Cloudflare Workers

At a glance

1. Two vendors, three meters, two definitions of work

Lambda now publishes two price sheets. Event Functions bill requests plus duration in GB-seconds: $0.0000133334 per GB-second on Arm, $0.0000166667 on x86, and $0.20 per million requests. Web Functions bill active CPU at $0.0000276944 per vCPU-second, memory at $0.0000036667 per GB-second for as long as the environment exists, and $0.30 per million requests.

Workers bill one thing that matters: CPU milliseconds, $0.02 per million after 30 million included, plus $0.30 per million requests after 10 million on a $5 plan. The page is explicit that there is no charge for duration, for egress or for bandwidth.

2. A GB-second is a memory meter wearing a clock

Duration billing multiplies wall time by allocated memory, and both factors are yours to set. A 512 MB function that takes 200 ms bills 0.5 GB × 0.2 s = 0.1 GB-s per request. At 100 million requests that is 10 million GB-seconds, or $133.34 on Arm at $0.0000133334.

Workers bills the 10 ms of actual work instead: 100 million × 10 ms = 1,000 million CPU-milliseconds, which is 970 million after the 30 million included, at $0.02 per million CPU-ms = $19.40.

So the ratio between the two vendors is not a rate difference. It is the fraction of the request that is CPU: 10 ms of 200 ms is 5%, and that 5% is what Workers meters. Make the handler heavier and the gap narrows; make it wait on a database and the gap widens.

3. The bills cross at about 7.5 million requests

Same shape everywhere below: 200 ms duration, 512 MB, 10 ms of CPU, one function.

The crossover is a free-tier artefact, not a policy: 1 million requests and 400,000 GB-seconds are free on Lambda, and 30 million CPU-ms are free on Workers. Below roughly 7.5 million requests the Lambda allowance is worth more than the CPU savings. Above it, the $5 plan floor disappears into the noise.

4. Lambda's second sheet splits the same request in two

Web Functions are AWS's answer to active-CPU billing, and they price the same 100 million requests differently.

Web Functions bill $62.45 for the same traffic, 42% of the Event price, and still 21% above the Workers bill. The memory meter is why: it bills the environment for its whole life, idle time included, and AWS's own examples quietly assume exactly one environment stays up for the entire month.

5. Where Lambda wins on the same sheet

The free tier, for one. Five million requests a month cost $2.13 on Lambda and $5.40 on Workers, and a hobby project that sends three million costs $2.73 by AWS's own worked example.

Memory ceiling is the second. Lambda allocates up to 10,240 MB per function, which covers a model that will not fit in a V8 isolate. Workers caps a single invocation at 5 minutes of CPU, 30 seconds by default.

The third is everything around the function: VPC access, IAM, SQS, Kinesis, Step Functions and the rest of the event-source catalogue. On an AWS shop, the compute line is frequently cheaper than the integration you would rewrite to leave it.

6. The exit door has a rewrite behind it

Workers runs JavaScript on V8 with a fetch-shaped API. A Lambda handler that imports a native module, spawns a process or needs a writable filesystem does not run there, and the 5-minute CPU cap is not negotiable with a support ticket.

The reverse move is easier and still not free: Workers' egress is $0 and Lambda's is not, so a byte-heavy service that moves back to Lambda picks up a data transfer line it never had.

Price the traffic, not the platform. If your p50 request spends most of its time waiting on a database, the CPU meter is the cheaper meter and the rewrite is the only real cost. If your requests are heavy, synchronous and mostly compute, the two bills converge and the free tier decides.

Cost arithmetic at volume

These are computed from the published unit prices, not measured. Each row prints its own formula, so you can replace our assumption with your traffic and redo it.

Decision matrix

Rows are the situation you are actually in. Pick the row before you read the pricing page again.

Code and configuration

// Event Function: the meter starts at invocation and runs through the wait.
export const handler = async (event) => {
  const user = await db.users.findUnique({ where: { id: event.userId } }); // 180 ms here
  const digest = render(user);                                            // 10 ms here
  return { statusCode: 200, body: digest };
};
// Breaks when: the lookup takes 1 s. You are billed 1.01 s of 512 MB, so the wait
// is 99% of the invoice. Web Functions bill only the 10 ms of active CPU.

// Workers: nothing here is billed by the clock, only the CPU this code burns.
export default {
  async fetch(request, env) {
    const userId = new URL(request.url).searchParams.get("id");
    const user = await env.DB.prepare("SELECT * FROM users WHERE id = ?")
      .bind(userId).first();            // 180 ms of waiting, not billed
    return new Response(render(user), {
      headers: { "content-type": "text/html" },
    });
  },
};
// Breaks when: render() parses a 5 MB XML feed on every request. CPU is the meter,
// and the 30M CPU-ms allowance is 30 million milliseconds of exactly that.

What you gain, what you give up

Migration path

Common questions

Sources & verification

Prices and limits were read from these pages on 2026-11-10. Vendor marketing claims are quoted as claims. Anything derived is arithmetic on the numbers below.

Keep reading