Serverless Showdown: Cloudflare Workers vs Lambda vs Cloud Functions vs Azure Functions

Introduction

"Serverless" is one of the most overloaded terms in cloud computing. When AWS Lambda launched in 2014, serverless meant event-driven functions that run in response to triggers, scale to zero, and bill per invocation. A decade later, the category has expanded to include edge isolates, container-based functions, orchestration frameworks, and globally distributed compute.

The critical distinction that most comparisons miss: there are two fundamentally different serverless architectures, and they make different trade-offs.

Container-based serverless (AWS Lambda, Google Cloud Functions, Azure Functions) runs your code in containers or microVMs within specific cloud regions. Containers provide full language runtimes, large memory allocations, and access to the operating system — but they take time to start (cold starts), they run in one region at a time, and they bill for wall-clock time including I/O wait.

Isolate-based serverless (Cloudflare Workers) runs your code in V8 isolates at edge locations worldwide. Isolates start in under a millisecond, deploy globally in seconds, and bill for CPU time only — but they are limited to JavaScript/TypeScript/WASM, have smaller memory allocations, and cannot access the file system or native OS APIs.

This architectural difference determines cold start behavior, language support, execution limits, pricing, global distribution, and what you can build. Neither is universally better. Understanding when each model wins is the point of this comparison.

Runtime Architecture

Cloudflare Workers: V8 Isolates at Every Edge

Workers uses V8 isolates — the same JavaScript engine that powers Google Chrome. Instead of spinning up a container for each function invocation, Workers creates a lightweight execution context within an already-running V8 process.

How isolates work:

A V8 isolate is an independent instance of the V8 engine with its own heap memory, garbage collector, and execution context. Multiple isolates run within the same operating system process, separated by V8's security sandbox. Creating a new isolate takes less than 1 millisecond because there is no OS-level container to boot, no runtime to initialize, and no dependencies to load.

Global deployment:

Workers deploys to all 310+ Cloudflare data centers simultaneously. When you run wrangler deploy, your code is pushed to every location worldwide within seconds. There is no region selection — every user, everywhere, hits the nearest Workers instance.

Resource limits:

Resource	Free Plan	Paid Plan ($5/month)
Requests	100,000/day	10 million/month included
CPU time per request	10ms	30ms (50ms with automatic extension)
Wall-clock time	N/A (limited by CPU)	30 seconds
Memory	128 MB	128 MB
Script size	1 MB	10 MB (after compression)
Environment variables	64	128
Subrequests (fetch)	50	1,000

Companion services extend Workers beyond simple request handling:

Service	Description
Workers KV	Global key-value store, eventually consistent, optimized for reads
Durable Objects	Strongly consistent, single-threaded coordination primitives
R2	S3-compatible object storage (zero egress)
D1	SQLite database at the edge
Queues	Message queuing for async processing
Workers AI	ML inference at the edge (Llama, Stable Diffusion, etc.)
Hyperdrive	Connection pooling for external databases (Postgres, MySQL)
Vectorize	Vector database for AI/RAG applications
Workflows	Durable, multi-step execution (beta)

Limitations to acknowledge: 128MB memory is restrictive for data-heavy workloads. No native Python, Java, Go, or .NET runtimes. No file system access. No TCP/UDP sockets (HTTP only via Fetch API, plus WebSockets and TCP via connect API). No native database drivers — you must use HTTP-based database protocols or Hyperdrive for connection pooling.

AWS Lambda: Container-Based Compute Engine

Lambda runs your code inside Firecracker microVMs — lightweight virtual machines purpose-built for serverless workloads. Each function invocation gets an isolated environment with a full operating system, language runtime, and file system.

Language runtimes:

Lambda natively supports Node.js, Python, Java, .NET, Go, and Ruby. Custom runtimes allow any language via the Lambda Runtime API. You can also deploy functions as container images (up to 10GB), bringing any language, any dependencies, and any system libraries.

Resource limits:

Resource	Limit
Memory	128 MB – 10,240 MB (10 GB)
CPU	Proportional to memory (2 vCPUs at 1,769 MB, 6 vCPUs at 10 GB)
Execution timeout	15 minutes
Package size	50 MB (zipped) / 250 MB (unzipped), 10 GB (container image)
Temporary storage (/tmp)	512 MB – 10,240 MB
Concurrent executions	1,000 (default, can be increased)
Payload size	6 MB (sync) / 256 KB (async)

Key features:

• SnapStart for Java: pre-initializes the JVM and snapshots the memory state, reducing Java cold starts from 5-10 seconds to ~200ms
• Provisioned Concurrency: keep a specified number of function instances warm, eliminating cold starts for a price ($0.0000041667/GB-second idle, verified August 2026)
• Lambda Layers: share libraries and dependencies across functions without including them in each deployment package
• Event source mappings: native integration with SQS, Kinesis, DynamoDB Streams, MSK, MQ for event-driven processing
• Lambda@Edge: run Node.js/Python at CloudFront's 13 regional edge caches (not all 600+ PoPs)
• CloudFront Functions: lightweight JavaScript at all CloudFront edge locations (very restricted: 1ms max, 2MB memory, no network)
• Lambda Function URLs: direct HTTPS endpoints without API Gateway
• Powertools for Lambda: official libraries for structured logging, tracing, metrics, idempotency, and validation

Lambda's depth is unmatched. The ecosystem of event sources, integration patterns, and operational tooling has had a decade to mature.

Google Cloud Functions: Two Generations, One Direction

Google Cloud Functions exists in two generations, and the distinction matters:

1st gen is a simple event-driven function runtime. It supports Node.js, Python, Go, Java, .NET, Ruby, and PHP. Functions respond to HTTP requests or events from Google Cloud services (Pub/Sub, Cloud Storage, Firestore). It is the simplest serverless option on any cloud — write a function, deploy it, done.

2nd gen is built on Cloud Run — Google's container-based serverless platform. This means 2nd gen Cloud Functions are actually containers under the hood, giving them:

Feature	1st Gen	2nd Gen
Max memory	8 GB	32 GB
Max timeout	9 minutes (HTTP) / 10 min (event)	60 minutes
Concurrency	1 request per instance	Up to 1,000 concurrent requests per instance
Min instances	0	0 (configurable minimum)
Traffic splitting	No	Yes (via Cloud Run revisions)
Event sources	Native triggers	Eventarc (unified event routing)
VPC connectivity	Serverless VPC Access	Direct VPC Egress

2nd gen's concurrency model is a significant advantage. While Lambda processes one request per function instance (requiring more instances for parallel requests), Cloud Functions 2nd gen can handle up to 1,000 concurrent requests per instance — dramatically reducing cold starts and improving resource efficiency.

Cloud Functions for Firebase provides a streamlined experience for mobile/web backend development, with native triggers for Firestore, Realtime Database, Authentication, and Cloud Storage events.

Azure Functions: Most Flexible Hosting Model

Azure Functions distinguishes itself not through runtime innovation but through hosting flexibility and orchestration capabilities.

Hosting plans:

Plan	Scaling	Cold Starts	Max Memory	Max Timeout	Price Model
Consumption	Auto (0 to N)	Yes (500ms-15s)	1.5 GB	10 minutes	Per-execution
Flex Consumption	Auto with always-ready instances	Reduced	4 GB	Configurable	Per-execution + always-ready
Premium	Auto (1 to N, pre-warmed)	Minimal	14 GB	Unlimited	Per-second + min instances
Dedicated	Manual/auto (App Service)	None	Per VM	Unlimited	Per VM (App Service pricing)
Container Apps	Auto (0 to N)	Container startup	Per container	Unlimited	Per-second

This flexibility means Azure Functions can serve as a true serverless function (Consumption plan), a pre-warmed always-ready service (Premium), or a traditionally deployed application (Dedicated) — all using the same code and programming model.

Durable Functions is Azure's unique differentiator:

Durable Functions is an extension that lets you write stateful workflows using code. Instead of defining state machines in JSON (like AWS Step Functions), you write orchestrator functions in C#, JavaScript, Python, or Java using familiar async/await patterns:

// Azure Durable Functions orchestrator
const df = require("durable-functions");

module.exports = df.orchestrator(function* (context) {
    // Fan-out: run multiple activities in parallel
    const tasks = [];
    tasks.push(context.df.callActivity("ProcessOrder", order1));
    tasks.push(context.df.callActivity("ProcessOrder", order2));
    tasks.push(context.df.callActivity("ProcessOrder", order3));

    // Fan-in: wait for all to complete
    const results = yield context.df.Task.all(tasks);

    // Human interaction: wait for approval (up to 72 hours)
    const approval = yield context.df.waitForExternalEvent("ApprovalEvent", 72 * 60 * 60);

    if (approval.approved) {
        yield context.df.callActivity("FinalizeOrders", results);
    }
});

This code handles fan-out/fan-in parallelism, human interaction patterns, retries, and timeouts — all within a single function. The Durable Functions framework manages checkpointing, replay, and state persistence. AWS Step Functions achieves similar outcomes but with a JSON state machine definition that is separate from your code.

Bindings are another Azure Functions innovation: declarative input/output connections to Azure services. Instead of writing SDK code to read from a queue and write to a database, you declare bindings in configuration:

{
  "bindings": [
    { "type": "queueTrigger", "name": "order", "queueName": "orders" },
    { "type": "cosmosDB", "name": "document", "direction": "out", "databaseName": "orders" }
  ]
}

The runtime handles connection management, serialization, and error handling. This reduces boilerplate significantly for integration-heavy functions.

Language support is the broadest: C#, JavaScript, TypeScript, Java, Python, PowerShell, Go, Rust, and any language via custom handlers.

Cold Starts: The Real Numbers

Cold starts are the most discussed and most misunderstood aspect of serverless computing. Here is what actually happens:

What Causes Cold Starts

A cold start occurs when there is no warm function instance available to handle a request. The platform must:

1. Allocate a compute environment (container/microVM or isolate)
2. Download your code and dependencies
3. Initialize the language runtime
4. Run your initialization code (module imports, connection establishment)
5. Execute the handler

Steps 1-4 are the cold start. Workers eliminates steps 1-3 by using V8 isolates instead of containers.

Measured Cold Start Times

Based on published benchmarks and community testing as of 2025-2026. Actual times vary by runtime, package size, and region.

Scenario	Workers	Lambda (Node.js)	Lambda (Python)	Lambda (Java)	Cloud Functions 2nd gen	Azure Functions (Consumption)
Minimal function	<1ms	80-150ms	100-200ms	800ms-3s	200-500ms	500ms-2s
With dependencies	<5ms	150-300ms	200-500ms	2-5s	500ms-1.5s	1-3s
Large package	<10ms	300-800ms	500ms-1s	3-10s	1-3s	2-5s
With VPC	N/A	+200-500ms (improved)	+200-500ms	+200-500ms	+100-300ms	+1-3s
Warm invocation	<0.5ms	1-5ms	1-5ms	1-5ms	5-20ms	5-20ms

Why Workers Has No Cold Starts

The phrase "no cold starts" sounds like marketing, but it is architecturally accurate. Here is why:

A V8 isolate is created within an already-running V8 process. There is no container to boot, no OS to initialize, no runtime to load. The isolate creation itself takes less than 1 millisecond. Your code is already cached at the edge location (it was pushed there at deploy time). Module instantiation in V8 is measured in microseconds for typical Workers scripts.

The result: the difference between a "cold" and "warm" Workers invocation is less than 5 milliseconds, which is within the noise of network latency. In practical terms, there is no user-perceptible cold start.

The Cost of Eliminating Cold Starts on Hyperscalers

If cold starts are unacceptable on Lambda, you have two options:

Provisioned Concurrency: Lambda keeps a specified number of function instances initialized and ready. Verified August 2026: $0.0000041667/GB-second for idle provisioned instances, plus a separate elevated duration rate of $0.0000097222/GB-second for invocations that actually execute on those provisioned instances. For a 512 MB function with 10 provisioned instances held warm continuously, the idle charge alone is roughly $55/month before a single invocation. Two things follow: provisioned concurrency reintroduces exactly the always-on cost that serverless was meant to eliminate, and the execution rate on provisioned instances is higher than standard on-demand duration — so it is not a straight trade of money for latency.

SnapStart (Java only): Lambda pre-initializes the JVM and takes a memory snapshot. Subsequent cold starts restore from the snapshot instead of re-initializing, reducing Java cold starts from 5-10 seconds to ~200ms. Free to use, but only available for Java.

On Cloud Functions 2nd gen, minimum instances keep instances warm. On Azure Functions, the Premium plan provides pre-warmed instances. Both add cost relative to the pure pay-per-execution model.

Workers' architectural advantage: zero cold starts are free. There is no premium tier, no provisioned capacity, no warm-up strategy required.

Programming Model Differences

The Same API Endpoint, Four Ways

To illustrate the programming model differences, here is a simple JSON API endpoint that reads a query parameter and returns a response:

Cloudflare Workers:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const name = url.searchParams.get("name") || "World";
    return new Response(JSON.stringify({ message: `Hello, ${name}!` }), {
      headers: { "Content-Type": "application/json" },
    });
  },
};

AWS Lambda (Node.js with Function URL):

export const handler = async (event) => {
  const name = event.queryStringParameters?.name || "World";
  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ message: `Hello, ${name}!` }),
  };
};

Google Cloud Functions (2nd gen):

const functions = require("@google-cloud/functions-framework");

functions.http("hello", (req, res) => {
  const name = req.query.name || "World";
  res.json({ message: `Hello, ${name}!` });
});

Azure Functions (Node.js v4 model):

const { app } = require("@azure/functions");

app.http("hello", {
  methods: ["GET"],
  handler: async (request, context) => {
    const name = request.query.get("name") || "World";
    return {
      jsonBody: { message: `Hello, ${name}!` },
    };
  },
});

The differences are subtle in this simple example but reveal important philosophical distinctions:

• Workers uses the Web Standards API (Request/Response, URL, fetch). If you know how to write a Service Worker, you know how to write a Worker. The mental model is "intercept an HTTP request and return an HTTP response."
• Lambda uses an event/context model. The function receives a structured event object and returns a structured response. The mental model is "process an event and return a result."
• Cloud Functions uses an Express-like model (req/res). The mental model is "handle an HTTP request like a Node.js web server."
• Azure Functions uses a trigger/binding model. The HTTP handler is registered declaratively. The mental model is "wire up inputs and outputs to a handler."

Where the Models Diverge

For simple HTTP handlers, all four are adequate. The differences become significant for:

Complex applications with routing:

Workers: Use itty-router, Hono, or other lightweight routers — or simply parse the URL in your fetch handler. The Workers ecosystem favors small, composable tools.

Lambda: Use API Gateway for routing (path-based, method-based), or handle routing within your Lambda function. Framework options include Serverless Framework, SAM, SST, and Architect.

Cloud Functions: Each function typically handles one route. For multi-route APIs, use Cloud Endpoints, API Gateway, or deploy multiple functions behind a load balancer — or use Cloud Run directly for a full web server.

Azure Functions: Each function handles one trigger. For REST APIs, define multiple functions with HTTP triggers or use Azure API Management for routing, versioning, and policies.

State management:

Platform	Key-Value	SQL	Coordination	Files
Workers	KV (global, eventual consistency)	D1 (SQLite, edge)	Durable Objects (strong consistency)	R2 (object storage)
Lambda	DynamoDB, ElastiCache	RDS, Aurora	Step Functions, SQS	S3
Cloud Functions	Memorystore, Firestore	Cloud SQL, Spanner	Workflows, Pub/Sub	GCS
Azure Functions	Cosmos DB, Redis Cache	SQL Database	Durable Functions, Service Bus	Blob Storage

Workers' built-in state primitives (KV, D1, Durable Objects) are notable because they run on the same network without cross-service network hops. Durable Objects in particular solve a problem that is difficult on other platforms: strongly consistent, single-threaded state coordination at the edge — useful for rate limiting, leader election, WebSocket rooms, and real-time collaboration.

Ecosystem and Integration

Capability	Workers	Lambda	Cloud Functions	Azure Functions
Built-in storage	KV, R2, D1	Need S3, DynamoDB	Need GCS, Firestore	Need Blob, Cosmos DB
Relational database	D1 (SQLite), Hyperdrive (Postgres proxy)	RDS, Aurora (same-VPC)	Cloud SQL, AlloyDB	SQL Database, Cosmos DB
Message queue	Queues	SQS, SNS, EventBridge	Pub/Sub, Eventarc	Service Bus, Event Grid
AI/ML inference	Workers AI (on-network)	Bedrock, SageMaker	Vertex AI	Azure OpenAI, Azure AI
Orchestration	Workflows (beta)	Step Functions	Workflows	Durable Functions
API gateway	Built-in (routes/custom domains)	API Gateway, ALB, Function URLs	API Gateway, Cloud Endpoints	API Management, Function URLs
Cron/scheduled	Cron Triggers	EventBridge Scheduler	Cloud Scheduler	Timer trigger
WebSockets	Yes (native, + Durable Objects)	Via API Gateway WebSocket	No	Via SignalR Service
Observability	Tail Workers, Logpush, Analytics Engine	CloudWatch, X-Ray	Cloud Logging, Cloud Trace	Application Insights
Local development	Miniflare (full local emulation)	SAM local, LocalStack	Functions Framework	Azure Functions Core Tools
IaC	Wrangler, Terraform, Pulumi	CloudFormation, SAM, CDK, Terraform	Terraform, gcloud	ARM, Bicep, Terraform
CI/CD	Wrangler in any CI, Workers Builds	CodePipeline, CodeDeploy	Cloud Build, Cloud Deploy	Azure DevOps, GitHub Actions

Lambda's ecosystem is the most mature by a wide margin. The breadth of event sources (200+ AWS services can trigger Lambda), the depth of integration patterns, and the size of the community create a compounding advantage. If you are building event-driven architectures within AWS, Lambda is the gravitational center.

Workers' ecosystem is smaller but architecturally cohesive. Every companion service (KV, R2, D1, Durable Objects, Queues, AI) runs on the same network with zero data transfer cost and minimal latency. The trade-off is fewer integration options — Workers cannot natively trigger on S3 events, DynamoDB streams, or SQS messages.

Pricing Comparison

Pricing verified as of 13 August 2026. Every figure in this section was re-checked against the vendor's own published pricing page on that date. Sources: Cloudflare Workers pricing, AWS Lambda pricing, Cloud Run functions (1st gen) pricing, Azure Functions pricing and the Azure Retail Prices API. All prices USD, US East / Tier 1 regions, on-demand, no committed-use discounts.

What we could not verify. Google publishes no machine-readable price for Cloud Run (the 2nd-gen billing surface) — the pricing page renders its tables client-side and the SKU list omits rates. Azure's Consumption-plan Functions page renders $- placeholders and exposes real rates only through the pricing calculator. Where that is the case we say so below rather than reprinting a number from a third-party blog. This is the single most common defect in serverless pricing comparisons: a confident-looking table of figures that no vendor actually publishes.

Per-Request Pricing

Dimension	Workers (Paid)	Lambda	Cloud Functions 1st gen	Azure Functions (Consumption)
Monthly included	10M requests	1M requests	2M invocations	1M executions
Per request	$0.30/million	$0.20/million	$0.40/million	Not published as text
Free tier	100K/day (free plan)	1M/month + 400,000 GB-sec	2M/month (always free)	1M/month + 400,000 GB-sec

Note the Google column carefully. "Cloud Functions 2nd gen" is no longer a distinct pricing product — Google now bills 2nd-gen functions as Cloud Run, and the Cloud Functions pricing page redirects there. The invocation and GHz-second rates that circulate in most comparisons (including earlier versions of this article) are the 1st gen rates, which Google still publishes. If you are deploying new functions today you are almost certainly on the Cloud Run billing model, and you should price it in the calculator rather than trusting any table you find online, this one included.

Compute Pricing

Dimension	Workers	Lambda	Cloud Functions 1st gen	Azure Functions
Billing unit	CPU milliseconds	GB-seconds	GB-seconds + GHz-seconds	GB-seconds
Included	30M CPU-ms/month	400,000 GB-sec/month	400,000 GB-sec + 200,000 GHz-sec	400,000 GB-sec/month
Price	$0.02/million CPU-ms	$0.0000166667/GB-sec (x86)	$0.0000025/GB-sec, $0.0000100/GHz-sec	Calculator-only (Consumption)
Memory	128 MB (fixed)	128 MB – 10 GB (choose)	128 MB – 32 GB (choose)	128 MB – 1.5 GB (Consumption)
Min charge	$5/month (paid plan)	$0	$0	$0

Two corrections worth calling out, because both appear widely and both are wrong:

Lambda Provisioned Concurrency is $0.0000041667 per GB-second, not the $0.000004646 figure that propagated across comparison articles (including this one until August 2026). AWS also charges a separate, higher duration rate of $0.0000097222/GB-second for invocations that execute on provisioned instances. Budget both.

Workers' paid plan includes 30 million CPU-milliseconds per month, not just the request allowance. Most comparisons quote the $0.02/million CPU-ms rate while omitting the inclusion, which materially overstates Workers' cost at small scale.

Verified Azure figures we can publish, from Microsoft's Retail Prices API rather than the marketing page: Flex Consumption always-ready execution is $0.000016/GB-second with a free grant of 250,000 executions and 100,000 GB-seconds; Premium plans bill $0.173/vCPU-hour and $0.0123/GiB-hour. The classic Consumption plan's per-execution and per-GB-second rates are genuinely not published in retrievable form.

The Billing Dimensions Nobody Compares

Feature grids compare memory and timeout. Bills are decided by which dimensions the vendor meters, and the four platforms meter differently enough that the same workload can differ several-fold in cost:

Metered dimension	Workers	Lambda	Cloud Functions 1st gen	Azure Consumption
Requests	Yes	Yes	Yes	Yes
Wall-clock duration	No	Yes	Yes	Yes
CPU time	Yes (only this)	No	Via GHz-seconds	No
Memory allocated	No (fixed 128 MB)	Yes (you choose, you pay)	Yes	Yes
CPU allocated	No	Coupled to memory	Billed separately (GHz-sec)	Coupled to memory
Response egress	No	Yes	Yes	Yes

The consequences are concrete. On Lambda you pay for memory you provisioned, not memory you used — a function set to 1 GB that touches 200 MB is billed at 1 GB for its whole duration. On Cloud Functions 1st gen, CPU is a separate meter from memory, so the memory/vCPU pairings in Google's table (128 MB gets 0.083 vCPU; 2 GB gets a full vCPU) mean raising memory to get CPU raises two charges. On Workers, memory is not a lever at all — 128 MB, take it or leave it — and duration is free, which is why I/O-bound work is so cheap and why CPU-bound work hits a wall.

Egress: The Charge That Is Missing From Every Serverless Comparison

Serverless comparisons price invocations and duration and then stop. But your function returns data, and three of these four platforms bill you for it. For a response-heavy API this can exceed the compute bill outright.

Verified rates for data transfer out to the internet:

Platform	Egress to internet	Free allowance
Cloudflare Workers	$0	Unlimited
AWS Lambda	$0.09/GB (first 10 TB), $0.085/GB (next 40 TB), $0.07/GB (next 100 TB), $0.05/GB beyond	100 GB/month, account-wide
Cloud Functions 1st gen	$0.12/GB	5 GB/month
Azure Functions	$0.087/GB (100 GB–10 TB), $0.083/GB (10–50 TB), $0.07/GB (50–150 TB), $0.05/GB beyond	100 GB/month

AWS rates confirmed against the AWS Data Transfer price list API for us-east-1; Azure rates against the Retail Prices API for eastus (Microsoft Global Network routing — the cheaper "Internet routing preference" runs $0.08/$0.065/$0.06/$0.04 per GB).

Make it concrete. An API returning a 50 KB JSON payload 100 million times a month moves roughly 4.8 TB. On Lambda that is about $420/month in egress alone — several times the compute cost in Scenario 1 below. On Workers it is $0. That single line, omitted from essentially every serverless comparison including this article's earlier revisions, is often the largest number on the invoice.

The corollary matters too: egress is charged on the way out to the internet. If your Lambda returns data to another AWS service in the same region, that is free; across Availability Zones it is $0.01/GB each direction. Chatty cross-AZ function architectures accumulate this quietly.

Free Tiers and What Happens at the Cliff

The free tiers differ not just in size but in kind, and the failure mode at the limit differs more than the limit itself:

Platform	Free allowance	Permanent?	Behaviour at the limit
Workers (free)	100,000 requests/day, 10 ms CPU per invocation	Yes	Requests are rejected with HTTP 429 until the daily window resets
Workers (paid)	10M requests + 30M CPU-ms	Yes, above $5/mo	Overage billed at $0.30/M and $0.02/M CPU-ms
Lambda	1M requests + 400,000 GB-sec/month	Yes, always-free	Silently billed — no cap, no notification
Cloud Functions 1st gen	2M invocations, 400,000 GB-sec, 200,000 GHz-sec, 5 GB egress	Yes, always-free	Silently billed
Azure Consumption	1M executions + 400,000 GB-sec	Yes, always-free	Silently billed

Workers' free plan is the only one that stops rather than bills. For a hobby project that is a feature — a traffic spike or a scraper cannot generate a surprise invoice. For anything production-facing it is a hard availability risk, and it is the single best reason to be on the $5 paid plan even at trivial volume.

The other three fail the opposite way. There is no spend cap on Lambda, Cloud Functions, or Azure Consumption. A runaway recursive invocation (a function writing to the bucket that triggers it is the classic) bills without limit. Set billing alarms before you need them; none of these platforms will do it for you.

Regional Price Variation

Every rate above is for the cheapest regions. Costs are not uniform:

• Lambda duration and request rates vary by region; egress varies more sharply — the same GB out costs $0.09 from us-east-1 and materially more from São Paulo, Cape Town, and the Middle East regions.
• Cloud Functions 1st gen publishes explicit Tier 1 and Tier 2 rates: $0.0000025 vs $0.0000035 per GB-second and $0.0000100 vs $0.0000140 per GHz-second — a 40% premium for Tier 2 regions on identical code.
• Azure egress is zone-priced. Verified from the Retail Prices API: the first paid tier is $0.087/GB from eastus, $0.08/GB from Detroit, but $0.11/GB from Australia Southeast and $0.1044/GB from the Dallas edge zone.
• Workers has no regional pricing at all. One rate, 330+ locations. Whatever else you conclude, this is a genuine and underrated simplification — there is no region-shopping exercise and no bill surprise when traffic shifts continents.

The CPU Time vs Wall-Clock Time Distinction

This is the most important pricing nuance in the comparison. Workers bills for CPU time. Lambda bills for wall-clock time (duration).

What this means: if your function makes an API call that takes 200ms to respond, and your function uses 5ms of CPU before and after that call:

• Workers charges for: 10ms of CPU time. The 200ms waiting for the API response costs nothing.
• Lambda charges for: 210ms of duration (the full wall-clock time including the wait).

For I/O-heavy workloads (API proxies, data aggregation, fan-out patterns), Workers is dramatically cheaper because most of the execution time is spent waiting for network responses, not computing.

For CPU-heavy workloads (image processing, video transcoding, ML inference, data transformation), Lambda is more cost-effective because the CPU usage equals the duration — and Lambda provides much more memory and CPU power.

Worked Total Cost at Three Realistic Workload Sizes

These are computed from the verified rates above, with the arithmetic shown so you can substitute your own numbers. Egress is included, because leaving it out is what makes most comparisons wrong.

Scenario 1: Global API proxy (I/O-heavy, response-heavy)

100M requests/month · 5 ms CPU · 200 ms wall-clock · 128 MB · 50 KB average JSON response (≈4,882 GB egress)

Provider	Requests	Compute	Egress	Monthly total
Workers	$27.00 (90M × $0.30/M)	$9.40 (470M CPU-ms × $0.02/M) + $5 base	$0	~$41
Lambda	$19.80 (99M × $0.20/M)	$35.00 (2.1M GB-sec × $0.0000166667)	$430.38 (4,782 GB × $0.09)	~$485
Cloud Functions 1st gen	$39.20 (98M × $0.40/M)	~$46 (GB-sec + GHz-sec)	$585.24 (4,877 GB × $0.12)	~$670
Azure Consumption	Not published	Not published	~$416 (4,782 GB × $0.087)	Egress only — compute unquotable

This is the scenario Workers is built for, and the margin is not the 40% that compute-only comparisons report — it is roughly 12×. Two effects compound: Workers bills 5 ms of CPU rather than 200 ms of wall-clock (a 40× difference on the duration meter), and Workers charges nothing for the 4.8 TB going back to users. Note that egress, not compute, is the dominant line item for all three metered platforms. If you take one number from this article, take that one.

Be fair about what this scenario assumes: a workload that fits in 128 MB, needs no native runtime, and is genuinely I/O-bound. Change any of those and the result inverts, as Scenario 2 shows.

Scenario 2: Image processing (CPU-heavy)

10M requests/month · 500 ms CPU · 500 ms wall-clock · 1 GB memory

Provider	Requests	Compute	Monthly total
Workers	—	—	Not viable (128 MB memory ceiling)
Lambda	$1.80 (9M × $0.20/M)	$76.67 (4.6M GB-sec × $0.0000166667)	~$78
Cloud Functions 1st gen	$3.20 (8M × $0.40/M)	~$82 (1 GB config, 500 ms × 10M)	~$85
Azure Consumption	Not published	Not published	Calculator-only

Here Workers does not lose on price — it cannot run the workload at all. 128 MB is not enough to decode, transform, and re-encode a typical image. Lambda and Cloud Functions are within ~10% of each other, and the real selection criteria become runtime support and ecosystem rather than cost. Lambda's Arm/Graviton option reduces the compute line further; AWS publishes a separate, lower Arm GB-second rate, and recompiling for Arm is usually the cheapest optimisation available on this workload.

Scenario 3: Scheduled background jobs (low volume, long duration)

1,000 executions/month · 120 seconds · 2 GB memory

Provider	Billable usage	Monthly total
Workers	—	Not viable (30-second wall-clock limit)
Lambda	240,000 GB-sec — under the 400,000 GB-sec free tier	$0
Cloud Functions 1st gen	240,000 GB-sec (free tier 400,000) + 120,000 GHz-sec (free tier 200,000)	$0
Azure Consumption	240,000 GB-sec — under the 400,000 GB-sec free grant	$0

This scenario is worth including precisely because the honest answer is cost is irrelevant here — all three container-based platforms fall entirely inside their permanent free tiers, and comparisons that quote "$3 vs $4" for this workload (as this article previously did) are comparing rounding error. Choose on timeout limits and operational fit instead: Workers is excluded by its 30-second ceiling, Lambda gives you 15 minutes, Azure Consumption 10 minutes, and Cloud Functions up to 60.

Calculate Your Costs

Use the calculator below to estimate costs for your specific workload:

🧮Try the interactive Serverless calculatorRun it free on inventivehq.com →

Edge vs Region: The Fundamental Architecture Question

This is the strategic question that underlies the entire comparison. Workers runs at the edge (310+ locations). Lambda, Cloud Functions, and Azure Functions run in specific cloud regions (typically 20-30 regions per provider).

When Edge Wins

User-facing API responses. If your API serves users globally and the response can be computed at the edge (from cached data, KV, D1, or R2), Workers provides the lowest possible latency — the response originates from the nearest of 310+ locations.

Authentication and authorization. JWT validation, session checks, API key verification — these are lightweight compute operations that benefit from running as close to the user as possible. Every millisecond of auth latency adds to every subsequent request.

A/B testing and personalization. Splitting traffic, modifying responses based on user segments, or inserting personalized content works best at the edge before the request reaches origin infrastructure.

Geographic routing and content localization. Modifying responses based on user location (language, currency, content variants) is a natural edge workload.

When Regions Win

Database-heavy workloads. If your function queries a database in us-east-1, running the function in us-east-1 gives you ~1ms round-trip to the database. Running it at a Cloudflare edge location 200ms away from your database adds 200ms of latency per query. Cloudflare's Hyperdrive (connection pooling and caching for Postgres) and Smart Placement (automatically running Workers near their backend dependencies) partially address this, but the physics of network latency remain.

Large compute workloads. Image processing, video transcoding, ML inference, and data transformation need more than 128MB of memory and more than 30 seconds of execution time. These belong in regions with powerful compute instances.

Complex multi-service orchestration. If your function calls five AWS services in sequence (DynamoDB, SQS, S3, SES, SNS), running it in the same AWS region eliminates cross-service latency. Running it at the edge would add hundreds of milliseconds per service call.

Compliance and data residency. Some workloads require that compute happens in a specific geographic jurisdiction. While Workers offers jurisdiction restrictions, Lambda's region model provides more granular control (e.g., specifically eu-central-1 for German data sovereignty requirements).

The Hybrid Approach

The most sophisticated architectures use both:

• Edge for request handling: auth, routing, caching, personalization, static content
• Region for heavy processing: database queries, business logic, background jobs, ML inference

Cloudflare Workers can proxy requests to regional backends (Lambda, Cloud Run, Azure Functions) after performing edge operations. This "edge router + regional compute" pattern captures the benefits of both models.

Decision Framework

Choose Cloudflare Workers When:

• Global latency matters — your users are distributed worldwide and every millisecond counts
• Cold starts are unacceptable — real-time APIs, interactive applications, WebSocket endpoints
• I/O-heavy workloads — API aggregation, proxy, data fetching where CPU time is a fraction of wall-clock time
• You want integrated edge state — KV, D1, Durable Objects, R2 on the same network
• Simple deployment is valued — wrangler deploy pushes globally in seconds
• The trade-offs are acceptable — 128MB memory, JS/TS/WASM only, 30-second limit

Choose AWS Lambda When:

• Ecosystem depth matters — 200+ AWS service integrations, the largest serverless community
• You need full language runtimes — Python with SciPy, Java with Spring, .NET with Entity Framework
• Complex event-driven architectures — SQS, Kinesis, DynamoDB Streams, EventBridge
• Heavy compute — up to 10GB memory, 15-minute execution, container image deployments
• You are already on AWS — Lambda is the natural compute layer for S3, DynamoDB, API Gateway workflows

Choose Google Cloud Functions When:

• GCP-native event processing — Pub/Sub, Firestore, Cloud Storage triggers via Eventarc
• Long-running functions — 2nd gen supports up to 60-minute execution
• High concurrency per instance — 2nd gen handles up to 1,000 concurrent requests per instance, reducing cold starts
• Firebase integration — Cloud Functions for Firebase is the most streamlined mobile backend
• You want a simpler serverless model — fewer configuration options than Lambda, fewer surprises

Choose Azure Functions When:

• Orchestration is core — Durable Functions provides code-based workflow orchestration that no other platform matches
• Hosting flexibility — Consumption, Premium, Dedicated, and Container Apps hosting from the same codebase
• .NET/C# is your primary language — Azure Functions has the best .NET experience
• Hybrid deployment — Azure Functions on Kubernetes (KEDA) runs on-premises or in any cloud
• Enterprise Microsoft ecosystem — Azure AD, Azure DevOps, Application Insights integration

The Honest Assessment

Workers represents a genuinely different approach to serverless computing. It is not a "better Lambda" — it is a different thing. The V8 isolate model makes architectural trade-offs that Lambda's container model does not: you get zero cold starts and global deployment, but you give up full language runtimes, large memory, and long execution.

For web-facing workloads — APIs, websites, real-time applications, middleware — Workers' architecture is objectively superior in latency, cold start behavior, and cost efficiency. The 128MB memory and 30-second limit are rarely constraints for these workloads.

For backend processing — data pipelines, batch jobs, ML inference, image processing — Lambda (or Cloud Functions, or Azure Functions) is the right choice. More memory, more CPU, longer execution, deeper ecosystem integration.

The most important insight: these platforms are not mutually exclusive. Many production architectures use Workers for edge routing and real-time response handling while delegating heavy processing to Lambda or Cloud Run. Understanding when each model excels is more valuable than declaring a winner.

Cloudflare Workers' biggest long-term bet is not the isolate runtime itself — it is the ecosystem of edge services (KV, D1, R2, Durable Objects, Queues, AI) that together create a complete application platform at the edge. If that ecosystem continues to mature, the range of workloads that can run entirely on Workers expands significantly. That trajectory is worth watching regardless of which platform you choose today.

Continue the Comparison

Serverless compute is one layer of the stack. These companion analyses apply the same verify-every-price method to the layers around it:

• Cloud pricing models compared: Cloudflare vs AWS vs Azure vs GCP — the full-stack total cost picture, including the egress and cross-AZ charges that dominate real bills.
• Cloudflare Load Balancing vs AWS ALB vs Azure Front Door vs Google Cloud Load Balancing — how traffic reaches your functions, and why Front Door's base fee changes the maths.
• Cloudflare vs AWS Shield vs Azure DDoS vs Google Cloud Armor — protecting those endpoints, where per-request security billing meets per-request compute billing.

To model your own numbers rather than ours, use the cloud cost comparison calculator.