How is it different than cloudflare workers?
Workers has 1MB script size limit (post compression), so that's there, too, and can run WASM or JS workloads (which CloudFront Functions can't, but Lambda@Edge can).
As for AWS Lambda Function URLs: Well, it isn't comparable to Workers at all. But if my use case fits Workers, then that's what I'd would prefer. In fact, I've gone many lengths to make my workload fit Workers. Deno Deploy is another viable alternative.
[0] https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...
[1] dated, but relevant: https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
If you need more than 1MB of script size, please reach out to Cloudflare support.
I thought our Unbound Workers are supposed to also be cheaper as well but I need to double-check that piece.
Bundled and Unbound Workers are equally fast.
For most workloads, I'd reckon that Unbound Workers are about the same cost as Bundled. In fact, Unbound will be ~2x cheaper than Bundled if your average workload completes within 50ms IO or 10ms CPU.
As for cost, a Bundled Worker definitely had a price advantage if you have CPU-light but IO-heavy workload. If my math is right then Unbound is cheaper up to roughly 220 ms of wall clock (I used 100M requests as an example). So if it takes > 220ms of time to send the response fully, Unbound will be the same price as Bundled and only get more expensive the longer the response takes. This isn't the RTT time to your origin. It's the total request time. So if you're doing lots of round-trips to origins, proxying WebSocket messages back and forth over a long time, proxying a large response body from somewhere else etc. This gets more complicated since we put in an important optimization that makes Unbound much cheaper if you're just proxying a response without modifying it since billing will stop once you return the Response so now the Unbound Worker has to actually be meaningfully involved in generating the Response body for it to bill until the response finishes sending to your client [2].
[1] https://stackoverflow.com/questions/68720436/what-is-cpu-tim... [2] https://blog.cloudflare.com/workers-optimization-reduces-you...
* If you use waitUntil() to schedule async work that completes after the HTTP response has been sent, this work is limited to 30 seconds.
* In general, if a request runs longer than 30 seconds, the chance of random cancellation increases a lot. For example, when we upgrade the Workers Runtime to a new version, we will give in-flight requests 30 seconds to finish before the process exits, which will cancel all remaining requests. (Of course, any application that relies on long-running connections needs to handle random disconnects regardless, due to the general unreliability of networks.)
I've been using Workers since 2019 and quite haven't kept up with Cloudflare's pace of innovation ever since. It has been dizzying. Looking forward to handling TCP and WebRTC workloads (announced last year) with Workers next.
So TLDR Workers is faster, can run longer, and costs less than Lambda@Edge.