Cloudflare Workers vs AWS Lambda vs Cloud Run: Source-Bounded Trade-offs

Cloudflare Workers, AWS Lambda, and Google Cloud Run are managed compute platforms that let teams run application logic without managing servers, but they package and price that compute in meaningfully different ways. In the supplied sources, Workers is positioned around global network execution and no cold starts [51], Lambda around request and GB-second billing plus a defined function resource envelope [52][53], and Cloud Run around container-based billing for CPU, memory, and requests with a 100 millisecond minimum per request [54].

That distinction matters because platform shape affects architecture, latency behavior, and monthly cost. Cloudflare says Workers run globally on its network and can begin receiving traffic in seconds after deployment [51][58]. AWS documents request and duration metrics in CloudWatch for Lambda, which is the mechanism many teams use to compare latency and cost behavior by workload and region [59].

Pricing mechanics are one of the clearest source-backed differences. Cloudflare Workers lists a Bundled plan starting at $5 per month and including 10 million requests, with additional requests billed beyond that threshold [50]. AWS Lambda in us-east-1 lists pricing at $0.20 per 1 million requests plus $0.0000166667 per GB-second for compute time [52].

Google Cloud Run uses a different model: it bills for CPU, memory, and request count, and includes a request-based minimum billing period of 100 milliseconds per request [54]. Fastly Compute also combines a platform fee with request-based pricing rather than a pure pay-per-invocation formula [56]. These structures do not prove one service is universally cheaper; they give you concrete pricing factors to evaluate against your traffic pattern, average execution time, and concurrency profile.

Cloudflare Workers is explicitly described as global edge execution on Cloudflare’s network, with the paid plan advertising no cold starts [51]. Cloudflare also states that a Workers script can begin receiving traffic in seconds after deployment because workers are deployed globally through its network [58]. That makes Workers especially straightforward to consider for request handling that benefits from being close to users in many geographies.

Fastly Compute and Vercel Edge Functions are useful reference points because both are also framed around edge-adjacent, low-latency execution. Fastly describes Compute as running at the edge with low-latency execution [56]. Vercel says Edge Functions run in the Edge Runtime and are designed for low-latency execution close to users [57].

The supplied sources do not make an equivalent edge-positioning claim for AWS Lambda or Cloud Run. For those platforms, the sources here are more specific about pricing, billing, warm-instance controls, and metrics rather than worldwide edge distribution [52][54][55][59]. As a result, a careful comparison should say Workers has a source-backed global edge claim, while Lambda and Cloud Run in this source set are better compared on metering, limits, and operational controls.

Cloudflare Workers’ paid plan explicitly advertises no cold starts [51]. That is a direct product claim, not an inference. For latency-sensitive use cases such as auth checks, redirects, request normalization, or personalization near the user, that wording is materially different from a platform that offers only partial mitigation.

Google Cloud Run does not make the same guarantee in the supplied pricing source, but it does provide a concrete control: configurable minimum instances [55]. Google documents that minimum instances can reduce cold starts by keeping containers warm [55]. That means Cloud Run gives teams a tunable trade-off between idle cost and startup latency rather than a blanket no-cold-start claim.

For AWS Lambda, the supplied sources here do not provide a cold-start guarantee or mitigation feature comparable to Cloud Run minimum instances. What they do provide is a measurement path: Lambda publishes region-specific duration and request metrics in CloudWatch [59]. In practice, that means Lambda cold-start impact, if relevant to your workload, should be evaluated through workload-specific measurement rather than assumed from this source set.

AWS Lambda has a clearly documented upper bound in the supplied sources: up to 10 GB of memory, up to 6 vCPUs per function, and configurable ephemeral storage up to 10 GB [53]. Those numbers are concrete and useful for screening workloads such as media processing, file transformation, or CPU-heavy background jobs. They do not prove Lambda is categorically superior to every alternative, but they do show Lambda supports a substantial per-function resource envelope in the documented announcement.

The supplied sources for Cloudflare Workers, Fastly Compute, and Vercel Edge Functions here focus on pricing and edge positioning, not equivalent memory-vCPU maxima [50][51][56][57]. The Cloud Run source in this set focuses on billing rather than top-end CPU or memory limits [54]. Because source coverage is asymmetric, the careful editorial move is to treat Lambda’s published 10 GB and 6 vCPU figures as a documented fact, while leaving cross-platform superiority claims unstated unless separately sourced.

A low-latency request path that serves users across many regions often maps naturally to products whose source materials emphasize edge execution. In this set, that includes Cloudflare Workers, Fastly Compute, and Vercel Edge Functions [51][56][57]. If your feature is mostly lightweight logic executed near the user, those services deserve early evaluation.

A task with highly variable execution time may be easier to reason about on Lambda because the pricing formula exposes both requests and GB-seconds directly [52]. A task that is naturally packaged as a container and may benefit from keeping instances warm fits Cloud Run’s documented model of CPU-memory-request billing plus minimum instances [54][55]. These are not absolute rules, but they are practical interpretations anchored to the supplied billing and operational facts.

Example 1: a global redirect and personalization layer for marketing pages. This is a classic edge-shaped problem because the logic is lightweight, request-driven, and geographically distributed. Cloudflare Workers has two directly relevant source-backed properties here: global execution on Cloudflare’s network and no cold starts on the paid plan [51].

Example 2: an image or document transformation pipeline that may need more CPU, memory, or temporary storage per invocation. Lambda’s published ceiling of 10 GB memory, 6 vCPUs, and 10 GB ephemeral storage gives you concrete sizing numbers to test against [53]. Because Lambda also charges per request and GB-second in us-east-1, you can model the cost impact of slower or larger transformations with explicit unit prices [52].

Example 3: an HTTP service already built as a container, where predictable startup matters and the team is willing to pay for warm capacity. Cloud Run supports a configurable minimum number of instances that can reduce cold starts by keeping containers warm [55]. Its billing model then makes you account for CPU, memory, and requests, including the 100 millisecond minimum per request [54].

The safest way to compare platforms is to normalize one workload and test it on each candidate service. For Lambda, AWS explicitly documents region-specific duration and request metrics in CloudWatch, which teams commonly use to compare latency and cost behavior across workloads [59]. That gives you a concrete instrumentation path rather than relying on assumptions.

For Workers and Cloud Run, a similar benchmarking mindset still applies even though the supplied sources emphasize different properties. Workers’ value proposition in this source set is global execution, seconds-fast deployment, and no cold starts on the paid plan [51][58]. Cloud Run’s value proposition in this set is billing transparency by CPU, memory, and requests plus warm-instance control [54][55].

Start by classifying the workload in three dimensions: execution location, runtime footprint, and billing sensitivity. If user proximity is the first requirement, shortlist Cloudflare Workers, Fastly Compute, and Vercel Edge Functions because the supplied sources explicitly position them for edge or low-latency execution [51][56][57]. If per-invocation resource size is the gating factor, test whether Lambda’s documented 10 GB memory, 6 vCPU, and 10 GB ephemeral storage limits match the job [53].

Then estimate cost using each platform’s native meter, not a forced apples-to-apples abstraction. Workers gives you a simple pricing point to evaluate with its $5 monthly Bundled entry and 10 million included requests [50]. Lambda requires request-volume and GB-second estimates [52]. Cloud Run requires CPU, memory, request count, and awareness of the 100 millisecond minimum per request, plus any decision to keep minimum instances warm [54][55].

Cloudflare Workers stands out in this source set for three concrete facts: global execution on Cloudflare’s network, a paid-plan no-cold-start claim, and a $5 per month Bundled entry plan with 10 million included requests [50][51]. AWS Lambda stands out here for explicit unit pricing in us-east-1 and a clearly documented function resource envelope of 10 GB memory, 6 vCPUs, and 10 GB ephemeral storage [52][53]. Google Cloud Run stands out here for container-shaped billing by CPU, memory, and requests, along with configurable minimum instances that can reduce cold starts [54][55].

If you need a single editorial rule, use this one: prefer the platform whose documented billing model and operational controls most closely match your workload’s shape. That advice is more durable than trying to crown one service as universally best. The supplied sources support a careful, practical comparison—not a winner-take-all verdict.