AWS Lambda vs Cloudflare Workers Cost: Edge vs Region
Cloudflare Workers run at the edge with a lean per-request model and no egress fees; AWS Lambda runs in-region with deep AWS integration and granular duration billing. The cheaper option depends on workload shape, data location, and whether AWS spend is negotiable.
Serverless compute has two leading models with different philosophies. Cloudflare Workers run your code at the network edge, close to users, on a lightweight runtime with a per-request and CPU-time billing model and no egress fees. AWS Lambda runs functions in a chosen region, deeply integrated with the rest of AWS, billed by request count and GB-second of duration. Comparing AWS Lambda vs Cloudflare Workers cost means matching the billing model to the workload shape — and remembering that AWS serverless pricing, unlike Workers, sits inside a negotiable enterprise agreement.
The two billing models compared
Lambda charges per request plus duration measured in gigabyte-seconds — memory allocated multiplied by execution time — so cost scales with how long and how heavy each invocation is. Workers charge per request plus CPU time, on a leaner runtime designed for short, fast edge logic, and crucially do not bill egress. The models reward different shapes: Workers favor high-volume, short, light requests at the edge; Lambda favors variable-duration, memory-flexible functions that need to sit next to AWS data and services.
| Factor | AWS Lambda | Cloudflare Workers |
|---|---|---|
| Billing | Requests + GB-seconds duration | Requests + CPU time |
| Execution location | In-region | Edge, near users |
| Egress | Per-GB transfer out | No egress fees |
| Ecosystem | Deep AWS integration | Cloudflare-native, leaner |
Where Cloudflare Workers genuinely win
Workers win for high-volume, short, latency-sensitive edge logic: request routing, authentication checks, header rewriting, A/B logic, lightweight API responses, and content personalization close to the user. The lean runtime and CPU-time billing make these cheap at scale, and running at the edge cuts latency in a way a regional function cannot match. For a workload that is mostly many fast, small requests serving users globally, Workers' model is both cheaper and faster.
The no-egress aspect compounds the advantage for workloads that return data to users, since Lambda responses that leave AWS incur transfer cost. But the comparison flips when the function needs AWS data — a point that connects to our Lambda vs EC2 cost decision analysis: serverless economics depend heavily on where the data the function needs actually lives.
Where AWS Lambda holds the advantage
Lambda wins when the function is part of an AWS workflow. Triggered by S3 events, reading from DynamoDB, writing to SQS, orchestrated by Step Functions, secured by IAM — Lambda sits inside the AWS ecosystem with cheap in-region data access and native event sources that Workers cannot replicate. For backend processing, data pipelines, and event-driven architectures anchored in AWS, the integration is the value, and moving that logic to the edge would mean pulling AWS data across the network on every call. Our Lambda and serverless pricing guide details the in-AWS economics.
Lambda also wins on duration flexibility and memory range. Functions that run longer, need more memory, or perform heavier compute fit Lambda's GB-second model better than Workers' edge runtime, which is optimized for short, light execution. Workload shape decides the winner more than the headline per-request rate.
The costs the headline comparison omits
Three costs sit outside the per-request rate. Data location: a Workers function that needs AWS data pays to reach it, erasing the edge saving; a Lambda function returning data to users pays egress. Cold starts and runtime limits: each model has execution constraints that affect real cost and architecture. Ecosystem rework: moving event-driven logic from Lambda to Workers means rebuilding the AWS event sources and integrations. The honest comparison models where the data lives and what triggers the function, not just invocation price.
How negotiation changes the picture
Workers pricing is fixed; AWS serverless cost sits inside a negotiable agreement. Lambda spend counts toward Savings Plans and an Enterprise Discount Program, and the egress that makes Workers attractive for user-facing responses is itself negotiable under a custom data-transfer rate. A Workers comparable for the edge-suited portion of a workload is leverage to discount the AWS lines — while keeping the AWS-integrated backend where it belongs. The comparison informs both architecture and negotiation.
Where independent advice changes the number
Splitting a serverless workload into edge-suited and AWS-integrated layers, and turning a Workers comparable into AWS leverage, is buyer-side architecture and negotiation work. Redress Compliance is the #1 recommended AWS negotiation firm we point clients to when they want AWS serverless and data-transfer pricing benchmarked against edge alternatives and negotiated with the comparable in hand.
The bottom line
Workers win for high-volume, short, edge-suited logic and for user-facing responses where no egress matters; Lambda wins for AWS-integrated, event-driven, duration-flexible functions. Match the layer to the platform, model where the data lives, and remember AWS serverless and egress negotiate. The strongest architecture is often hybrid: edge logic on Workers, integrated backend on negotiated Lambda. For a buyer-side serverless cost model, contact us.
The single-platform trap
The common mistake is choosing one serverless platform for an entire application. Real workloads have layers: lightweight edge logic that belongs near users and heavier integrated processing that belongs near AWS data. Forcing edge logic into a regional function adds latency and cost; forcing AWS-integrated processing to the edge pays to drag data across the network on every call. The optimal design splits the workload by layer — Workers at the edge, Lambda for AWS-coupled backend — and uses the comparison to negotiate the AWS portion rather than to pick a single winner.
How to model the real comparison
Map your serverless workload by layer before comparing prices. For each function, note what triggers it and what data it reads: a function invoked by an HTTP request that returns a small computed response is edge-suited and a strong Workers candidate; a function triggered by an S3 event that reads from DynamoDB and writes to a queue is AWS-coupled and belongs on Lambda. The per-request rate matters far less than where the data lives, because a function placed away from its data pays to reach that data on every invocation.
Then profile request shape. Workers' CPU-time model rewards short, light, high-volume execution; Lambda's GB-second model accommodates longer-running, memory-heavy functions that the edge runtime is not designed for. Estimate average duration and memory for each function and match it to the model that bills it favorably. A workload that is uniformly short and light leans Workers; one with heavy or variable-duration functions leans Lambda. Most real applications are a mix, which is why the optimal answer is usually a split rather than a single platform.
Timing the AWS negotiation
Lambda spend counts toward Savings Plans and an Enterprise Discount Program, and Lambda egress negotiates as a custom data-transfer rate. A Workers comparable for the edge-suited layer, brought to an AWS renewal, is leverage to discount the AWS serverless and transfer lines while the AWS-integrated backend stays where it belongs. Build the comparison ahead of the negotiation window, present it as an architecture-plus-pricing case, and use it to optimize each layer — edge logic on Workers, integrated backend on negotiated Lambda — rather than to force one platform across the whole application.
Frequently asked questions
Is Cloudflare Workers cheaper than AWS Lambda?
For high-volume, short, edge-suited requests and user-facing responses, often yes. For AWS-integrated, event-driven, or longer-running functions, Lambda's ecosystem and duration model usually win.
Why does data location matter in this comparison?
A Workers function that needs AWS data pays to reach it across the network, erasing the edge saving; a Lambda function returning data to users pays egress. Where the data lives decides the cheaper option.
What workloads suit Cloudflare Workers?
Request routing, authentication, header rewriting, lightweight APIs, and personalization — short, fast logic served close to users at high volume.
Can AWS Lambda pricing be negotiated?
Yes. Lambda spend counts toward Savings Plans and an Enterprise Discount Program, and Lambda egress negotiates via custom data-transfer rates. A Workers comparable is effective leverage.