{"id":18125,"date":"2026-07-13T11:53:39","date_gmt":"2026-07-13T04:53:39","guid":{"rendered":"https:\/\/www.cipher.co.th\/blogs\/cloudflare-workers-vs-aws-lambda-2\/"},"modified":"2026-07-13T11:53:39","modified_gmt":"2026-07-13T04:53:39","slug":"cloudflare-workers-vs-aws-lambda","status":"publish","type":"post","link":"https:\/\/www.cipher.co.th\/en\/blogs\/cloudflare-workers-vs-aws-lambda\/","title":{"rendered":"Cloudflare Workers vs AWS Lambda: Real Costs and Real Limits"},"content":{"rendered":"

Quick answer:<\/strong> Cloudflare Workers bills CPU time; AWS Lambda bills wall-clock duration. If your API spends most of its life waiting on a database or a third-party API, Workers is dramatically cheaper. If your code is genuinely CPU-bound at modest volume, Lambda is often cheaper, because its free tier of 400,000 GB-seconds per month absorbs a lot. And Workers is capped at 128 MB of memory, which cannot be raised on any plan. Pricing as of July 2026.<\/p>\n

The most common way to get this comparison wrong is to ask which one is cheaper without first asking what your code actually does with its time. The two platforms meter fundamentally different things, so the answer flips depending on your workload shape.<\/p>\n

Every number below comes from the official Cloudflare and AWS pricing documentation as of July 2026. Nothing is estimated. The arithmetic is shown so you can substitute your own traffic and re-run it.<\/p>\n

The difference that matters most: CPU time is not wall-clock time<\/h2>\n

AWS Lambda bills duration: the elapsed time from when the function starts until it returns. The billing unit is the GB-second, computed as the memory you configured multiplied by the elapsed seconds. If your function issues a query to RDS and sits idle for 180 ms waiting for the answer, you pay for all 180 ms even though the CPU did nothing. Cold start time is inside the billed duration too.<\/p>\n

Cloudflare Workers does not work this way. The Cloudflare documentation is explicit: CPU time measures only the time the CPU spends executing your code, and waiting on network requests such as fetch() calls, KV reads, or database queries does not count toward CPU time. The Workers Paid plan is documented as having no charge or limit for duration. You pay only for cycles you actually burn.<\/p>\n

In practice this means a Worker that waits two seconds on an upstream API but does 5 ms of real work costs the same as a Worker that returns instantly after 5 ms. The equivalent Lambda would bill the full two seconds. This is the single lever that moves the numbers most, and it is why the tables further down look the way they do.<\/p>\n

Cloudflare also states that the average Worker uses approximately 2.2 ms of CPU time per request, and that heavier workloads which handle authentication, do server-side rendering, or parse large payloads typically use 10 to 20 ms. That figure is more useful than any estimate, because most people badly overestimate their own CPU consumption.<\/p>\n

The rate cards, as of July 2026<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n
Item<\/th>\nCloudflare Workers<\/th>\nAWS Lambda<\/th>\n<\/tr>\n<\/thead>\n
Monthly subscription<\/td>\n$5 (Workers Paid)<\/td>\nNone, pay per use<\/td>\n<\/tr>\n
Included requests<\/td>\n10 million \/ month<\/td>\n1 million \/ month (free tier)<\/td>\n<\/tr>\n
Additional requests<\/td>\n$0.30 per million<\/td>\n$0.20 per million<\/td>\n<\/tr>\n
Compute billing unit<\/td>\nCPU-millisecond<\/td>\nGB-second (wall-clock)<\/td>\n<\/tr>\n
Included compute<\/td>\n30 million CPU-ms \/ month<\/td>\n400,000 GB-s \/ month (free tier)<\/td>\n<\/tr>\n
Additional compute<\/td>\n$0.02 per million CPU-ms<\/td>\n$0.0000166667 per GB-s (x86)
$0.0000133334 per GB-s (Arm)<\/td>\n<\/tr>\n
Billed while waiting on I\/O<\/td>\nNo<\/td>\nYes, including cold start<\/td>\n<\/tr>\n
Memory<\/td>\n128 MB fixed<\/td>\n128 MB to 10,240 MB, configurable<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Note the detail most people skip: a Workers request costs $0.30 per million against Lambda at $0.20 per million, which is 50 percent more expensive. If your functions are extremely light and extremely high-volume, Lambda wins the per-request line. Whether that matters depends entirely on how big Lambda duration charges get.<\/p>\n

Three worked scenarios<\/h2>\n

All three assume Lambda on x86 with 128 MB of memory in us-east-1, with the AWS free tier applied. Workers is on the Paid plan with its $5 minimum. Pricing as of July 2026.<\/p>\n

Scenario A: a normal API. 50M requests\/month, 200 ms wall-clock, 8 ms CPU<\/h3>\n

Lambda. Requests: (50,000,000 minus 1,000,000 free) \/ 1,000,000 times $0.20 = $9.80. Compute: 50,000,000 times 0.2 s = 10,000,000 seconds, multiplied by 128\/1024 = 0.125 GB gives 1,250,000 GB-s. Subtract the 400,000 GB-s free tier to get 850,000 GB-s, times $0.0000166667 = $14.17. Total: $23.97 per month.<\/p>\n

Workers. Subscription: $5.00. Requests: (50,000,000 minus 10,000,000 included) \/ 1,000,000 times $0.30 = $12.00. CPU: 50,000,000 times 8 ms = 400,000,000 CPU-ms, minus the 30,000,000 included leaves 370,000,000, divided by a million times $0.02 = $7.40. Total: $24.40 per month.<\/p>\n

Effectively a tie, 43 cents apart. If someone has told you Workers is always cheaper, this is the scenario that disproves it.<\/p>\n

Scenario B: an I\/O-bound API. 50M requests\/month, 800 ms wall-clock, 8 ms CPU<\/h3>\n

Same code, but now the upstream is slow: a payment gateway, a legacy ERP, a partner API. The CPU still only does 8 ms of work.<\/p>\n

\n\n\n\n\n\n\n\n\n
Line item<\/th>\nAWS Lambda<\/th>\nCloudflare Workers<\/th>\n<\/tr>\n<\/thead>\n
Subscription<\/td>\n$0.00<\/td>\n$5.00<\/td>\n<\/tr>\n
Requests<\/td>\n$9.80<\/td>\n$12.00<\/td>\n<\/tr>\n
Compute<\/td>\n$76.67<\/td>\n$7.40<\/td>\n<\/tr>\n
Monthly total<\/strong><\/td>\n$86.47<\/strong><\/td>\n$24.40<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The $76.67 comes from 50,000,000 times 0.8 s = 40,000,000 seconds, times 0.125 GB = 5,000,000 GB-s, minus the 400,000 free tier gives 4,600,000 GB-s, times $0.0000166667. The Workers column does not move at all, because the waiting is not billed. Lambda ends up 3.5 times more expensive for identical code.<\/p>\n

This is the most common shape in Thai business systems: an API gateway in front of a legacy backend, a webhook handler that calls a third party, a backend-for-frontend that fans out to several services. If your system looks like this, the difference lands on your invoice.<\/p>\n

Scenario C: CPU-bound work. 5M requests\/month, 120 ms wall-clock, 100 ms CPU<\/h3>\n

Now invert it. The code is doing real computation: encryption, converting a large chunk of data, rendering a complicated template. The CPU is busy almost the whole time.<\/p>\n

Lambda. Requests: (5,000,000 minus 1,000,000) \/ 1,000,000 times $0.20 = $0.80. Compute: 5,000,000 times 0.12 s = 600,000 seconds, times 0.125 GB = 75,000 GB-s, which does not even reach the 400,000 GB-s free tier, so $0.00. Total: $0.80 per month.<\/p>\n

Workers. Subscription: $5.00. Requests: $0.00, since 5 million is inside the 10 million included. CPU: 5,000,000 times 100 ms = 500,000,000 CPU-ms, minus 30,000,000 included leaves 470,000,000, divided by a million times $0.02 = $9.40. Total: $14.40 per month.<\/p>\n

Lambda is 18 times cheaper. This is not a rounding error. The 400,000 GB-second monthly free tier is generous for this traffic level, while Workers starts charging for CPU immediately past 30 million CPU-ms, and 100 ms of CPU per request exhausts that allowance after only 300,000 requests.<\/p>\n

Limits you need to know before you commit<\/h2>\n

Price is only half the decision. The other half is the set of hard limits you cannot engineer around.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n\n
Limit<\/th>\nWorkers Free<\/th>\nWorkers Paid<\/th>\nAWS Lambda<\/th>\n<\/tr>\n<\/thead>\n
Memory<\/td>\n128 MB<\/td>\n128 MB (cannot be raised)<\/td>\n128 MB to 10,240 MB<\/td>\n<\/tr>\n
CPU time per request<\/td>\n10 ms<\/td>\nUp to 5 min (default 30 s)<\/td>\nBilled as wall-clock, max 15 min<\/td>\n<\/tr>\n
Request cap<\/td>\n~100,000 \/ day<\/td>\nNo daily cap<\/td>\nNo cap (concurrency limits apply)<\/td>\n<\/tr>\n
Subrequests per request<\/td>\n50<\/td>\n10,000<\/td>\nNot explicitly limited<\/td>\n<\/tr>\n
Simultaneous outgoing connections<\/td>\n6<\/td>\n6<\/td>\nNot explicitly limited<\/td>\n<\/tr>\n
Bundle size (gzipped)<\/td>\n3 MB<\/td>\n10 MB<\/td>\n50 MB zip \/ 10 GB container image<\/td>\n<\/tr>\n
Filesystem<\/td>\nNone<\/td>\nNone<\/td>\n\/tmp, configurable up to 10,240 MB<\/td>\n<\/tr>\n
Cron \/ Queue consumer ceiling<\/td>\n–<\/td>\n15 minutes<\/td>\n15 minutes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The 128 MB memory ceiling is the one that kills projects. It is identical on Free and Paid, and Cloudflare provides no way to increase it. If you need to load an ML model, process high-resolution images, or buffer a whole file in memory, Workers is out before the conversation about price even begins. Lambda goes to 10,240 MB.<\/p>\n

The other trap is the 15-minute ceiling on Cron Triggers, Queue Consumers and Durable Object Alarms, which happens to be exactly the same as Lambda maximum. Neither platform suits batch jobs longer than that. We covered this class of problem in more detail in when you should not use Cloudflare Workers<\/a>.<\/p>\n

When AWS Lambda is the right answer<\/h2>\n

There are real cases where Lambda wins, and pretending otherwise helps nobody.<\/p>\n

Anything that needs more than 128 MB of memory.<\/strong> This is not a cost question, it is a can-you-run-it-at-all question. Video processing, generating large PDFs, model inference, in-memory joins over large datasets: these belong on Lambda or Fargate.<\/p>\n

CPU-bound work at moderate volume.<\/strong> As Scenario C showed, the Lambda free tier makes this class of workload nearly free, while Workers charges $5 as a floor and starts metering CPU past 30 million CPU-ms.<\/p>\n

Workloads that must reach private resources inside a VPC.<\/strong> Lambda attaches to a VPC natively and talks to RDS, ElastiCache, or any internal service that has no public endpoint. Workers needs Hyperdrive or Cloudflare Tunnel as an intermediary, which is an extra moving part to build and operate.<\/p>\n

Workloads glued to AWS event sources.<\/strong> S3 events, DynamoDB Streams, Kinesis, SQS, EventBridge and Step Functions all wire into Lambda in one line. If your architecture is built on those, moving to Workers means rewriting the whole integration layer, not just the handler.<\/p>\n

Anything needing native binaries or a non-JavaScript runtime.<\/strong> Workers runs in a V8 isolate with no filesystem and no subprocesses. Lambda accepts container images up to 10 GB and whatever runtime you put inside them.<\/p>\n

Data residency requirements.<\/strong> AWS made the Asia Pacific (Thailand) Region, ap-southeast-7, generally available on 7 January 2025 with three Availability Zones. If your regulator or your customer requires data to stay inside Thailand, that constraint outranks any pricing argument.<\/p>\n

So which should you pick<\/h2>\n

The fastest way to decide is to measure the ratio between CPU time and wall-clock time in your existing functions. If your code uses genuinely less than about 20 percent of its elapsed time on CPU, you are paying AWS to wait, and Workers will be meaningfully cheaper. If the ratio is close to 100 percent, or you need more than 128 MB of memory, Lambda is the answer.<\/p>\n

Do not estimate this from intuition. Open CloudWatch, look at the duration percentiles for the functions that actually cost you money, and compare them against the time the CPU is genuinely busy. The two numbers are usually much further apart than anyone expects.<\/p>\n

Cipher designs and builds systems on the Cloudflare Developer Platform for businesses in Thailand, and can assess whether a given workload is worth migrating.<\/p>\n

Frequently Asked Questions<\/h2>\n

Is Cloudflare Workers always cheaper than AWS Lambda<\/h3>\n

No. If your workload is genuinely CPU-bound and your request volume is moderate, Lambda is often cheaper because of its 400,000 GB-second monthly free tier. Workers wins clearly when your code spends most of its time waiting on a database or an external API, because Workers does not bill for that waiting time. Pricing as of July 2026.<\/p>\n

Why does Workers not charge me while my code waits for an API response<\/h3>\n

Because Workers bills CPU time rather than wall-clock time. The Cloudflare documentation states that waiting on network requests such as fetch() calls, KV reads, or database queries does not count toward CPU time. AWS Lambda instead bills the full duration of the invocation, including time spent waiting and including cold start.<\/p>\n

Can I increase the 128 MB memory limit on Workers<\/h3>\n

No. The 128 MB per isolate limit is identical on both the Free and Paid plans and there is no option to raise it. If your workload needs more memory than that, AWS Lambda is configurable from 128 MB up to 10,240 MB and is the more appropriate choice.<\/p>\n

What is the maximum execution time for a Worker<\/h3>\n

On the Workers Paid plan, CPU time can go up to 5 minutes per request, with a default of 30 seconds; the Free plan caps it at 10 milliseconds. Cron Triggers, Queue Consumers and Durable Object Alarms have a 15-minute ceiling, which is the same maximum AWS Lambda allows.<\/p>\n

What should I use if my function needs to reach a database inside a VPC<\/h3>\n

AWS Lambda is the more natural fit, because it attaches to a VPC directly and can reach RDS or ElastiCache instances that have no public endpoint. Cloudflare Workers requires Hyperdrive or Cloudflare Tunnel as an intermediary, which adds a component to build and maintain and may not be worth it if the rest of your backend already lives in AWS.<\/p>\n","protected":false},"excerpt":{"rendered":"

Quick answer: Cloudflare Workers bills CPU time; AWS Lambda bills wall-clock duration. If your API spends most of its life […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_angie_page":false,"content-type":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"page_builder":"","footnotes":""},"categories":[152],"tags":[],"class_list":["post-18125","post","type-post","status-publish","format-standard","hentry","category-technology-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18125","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/comments?post=18125"}],"version-history":[{"count":0,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18125\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/media?parent=18125"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/categories?post=18125"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/tags?post=18125"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}