Cloudflare recently unveiled new pricing for Cloudflare Workers. Previously, pricing compared with AWS Lambda has been fairly neck and neck, making the choice between the serverless services a matter of specific use cases and preferences. However, with these new pricing changes, will Cloudflare take a strong lead in cost-effectiveness, or will they remain close competitors?
In Scenario 1, Lambda offers a cost savings of 20-25% compared to Workers, while in Scenario 2, Workers provides a 10-200% cost advantage over Lambda (read scenarios).
Cloudflare Workers New Pricing
Something that interested us in the new Workers pricing was the simplicity. If you remember the old pricing models, there were two options - Bundled and Unbound. Each with specific use cases. Now there is just one option, that does not charge or limit duration:
|$5 per month||$0.30 per 1 Million||$0.02 per 1 Million CPU milliseconds|
The main difference in the new Cloudflare pricing model that they emphasized heavily is billing is “based on CPU time, and never for the idle time that your Worker spends waiting on network requests and other I/O”. This is great for saving on costs since you’re only paying for computing resources you use and also because it makes estimating costs much easier.
For a practical example of what consumes I/O time vs CPU time, consider a scenario where you are loading a container:
- I/O Time: The time your application inside the container spends waiting for data to be read from storage, fetched from a database, or received from external sources. So if your containerized application retrieves a large dataset from a database or access files stored in a remote location, the time spent waiting for these operations to complete is considered I/O time.
- CPU Time: The time your application actively utilizes the CPU resources during the process of loading, initializing, and executing tasks within the container. It encompasses tasks such as application startup, running setup scripts, and handling any computational processes required during container initialization.
AWS Lambda Pricing
Lambda pricing has more factors to take into consideration. Pricing is based on the amount of memory allocated to your Lambda functions, the duration of execution, and the number of requests processed. Pricing varies per region and there are different pricing models for x86 and Arm architectures. The cost is tiered based on the number of requests and duration.
|Duration (GB-seconds / month)||Price per Million Requests||x86 Price per GB-second|
|First 6 Billion||$0.20||$0.000016|
|Next 9 Billion||$0.20||$0.000015|
|Over 15 Billion||$0.20||$0.000013|
|Duration (GB-seconds / month)||Price per Million Requests||ARM Price per GB-second|
|First 7.5 Billion||$0.20||$0.000013|
|Next 11.25 Billion||$0.20||$0.000012|
|Over 18.75 Billion||$0.20||$0.000010|
With Lambda, you are charged for the duration, which encompasses the time when your code begins executing until it finishes or is terminated. This duration includes both the time spent actively using CPU resources and the time spent waiting for I/O operations. Because idle time is included in the charge, optimizing your code for shorter durations is crucial for effective cost management.
You can allocate any amount of memory to your AWS Lambda function between 128 MB and 10,240 MB. Keep in mind this allocation affects both the cost and the performance of your function.
|Memory (MB)||x86 Price per Millisecond||ARM Price per Millisecond|
Users of Lambda have long complained about its cold start problem (the delay or latency that occurs when a serverless function is invoked for the first time or after a period of inactivity) that results in extra charges. One existing feature meant to improve the issue is Provisioned Concurrency. This feature reserves a specific number of function instances, ensuring quick response times to incoming requests, although it comes at an additional cost. Note that Cloudflare also has a Provisioned Concurrency feature at no additional charge.
However, AWS’s recent re:Invent announcement of SnapStart provides “up to 90% reduction in cold start latency” at no additional cost. It addresses cold start latency by creating and caching snapshots. The new feature is currently only available for Java but is predicted to continue to expand offerings.
Initial Observations on Workers vs Lambda Pricing
- Workers pricing is more straightforward, with less factors to consider and no charges for execution duration.
- Lambda pricing is more granular, allowing you to fine-tune costs based on memory allocation, duration, and requests.
- Workers pricing seems to be more cost-effective for moderate use cases with predictable costs and no charges for execution duration.
- Lambda can be more flexible but may require careful optimization to achieve cost efficiency.
Comparing Free Tiers: Workers vs Lambda
Workers and Lambda both have impressive monthly offerings for free requests and CPU times.
|10,000,000 per month||30 million CPU milliseconds included per month|
|1,000,000 per month||400,000 GB-seconds
(Up to 3.2 million seconds of compute time)
Workers offers roughly 10 times the free requests and CPU time as Lambda. The number of requests in particular is significant, perhaps to attempt to make up for the per request cost being 30% more.
|100,000 per day||10 CPU milliseconds per invocation|
Cloudflare also offers a free plan that does not include a subscription fee. It’s more limited since you cannot exceed 100,000 requests per day, 1000 requests/min, or 10 CPU milliseconds per invocation, but is still an option if you’re looking for a basic level of serverless computing without a subscription fee.
Scenario 1: Image Recognition and Processing
Say you have a service that processes user-uploaded images for recognition and processing. About 5 million images (requests) are uploaded and processed each month. The average duration is 5 seconds per task. The average CPU time is 2.5 seconds of CPU time per task.
Workers Price Calculations
CPU Time 5 million requests * (2.5*1000) milliseconds CPU time = 12,500,000,000 CPU milliseconds 12,500,000,000 CPU milliseconds - 30 million free monthly CPU milliseconds = 12,470,000,000 CPU milliseconds 12,470,000,000 CPU milliseconds/1 million * $0.02 = $249.4 Requests 5 million requests - 5 million free monthly requests (5 million free monthly requests still leftover) = 0 requests 0 requests * $0.3 = $0 Subscription $5 a month Total $249.4 CPU Time + $0 Requests + $5 Subscription = $254.4
Lambda Price Calculations
Duration To accommodate the requests configure your function with 512 MB of memory on an x86 based processor. 5 million requests * 5 second duration = 25 million seconds 25 million seconds * 512 MB/1024 MB = 12,500,000 GB-s 12,500,000 GB-s – 400,000 free monthly GB-s = 12,100,000 GB-s 12,100,000 GB-s * $0.0000166667 monthly compute price = $201.67 Requests 5 million requests - 1 million free monthly requests = 4 million requests 4 million requests/1 million * $0.2 = $0.8 Total $201.67 CPU Time + $0.8 Requests = $202.47
In this scenario, Lambda is 25% cheaper than Workers. If we do the exact same calculations for 1 billion requests Workers costs $50,301 and Lambda costs $41,859, still a 20% savings.
Lambda is a great choice for scenarios like this with requests that require a lot of processing.
Scenario 2: Mobile App Analytics
You are the owner of a popular mobile app with millions of worldwide users. The app gathers analytical data from users, tracking various user actions and events, such as clicks, page views, and user interactions. You’d like to gain insights into user behavior to improve the app’s performance and user experience.
In this scenario there are a lot of requests that don’t need much processing. On average there are 10 billion requests per month. The average duration is 220 milliseconds per task. The average CPU time is 15 milliseconds of CPU time per task.
Workers Price Calculations
CPU Time 10 billion requests * 15 milliseconds CPU time = 150 billion CPU milliseconds 150 billion CPU milliseconds - 30 million free monthly CPU milliseconds = 149,970,000,000 CPU milliseconds 149,970,000,000 CPU milliseconds/1 million * $0.02 = $2,999.4 Requests 10 billion requests - 10 million free monthly requests = 9,900,000,000 requests 9,900,000,000 requests/1 million * $0.3 = $2,970 Subscription $5 a month Total $2,999.4 CPU Time + $2,970 Requests + $5 Subscription = $5969.4
Lambda Price Calculations
Duration To accommodate the need configure your function with 128 MB of memory on an x86 based processor. 10 billion requests * (220/1000) second duration = 2,200,000,000 seconds 2,200,000,000 million seconds * 128 MB/1024 MB = 275,000,000 GB-s 275,000,000 GB-s – 400,000 free monthly GB-s = 274,600,000 GB-s 274,600,000 GB-s * $0.0000166667 monthly compute price = $4,576.68 Requests 10 billion requests - 1 million free monthly requests = 999,900,000,000 requests 9,900,000,000 requests/1 million * $0.2 = $1,980 Total $4,576.68 CPU Time + $1,980 Requests = $6556.68
In this scenario Workers is 10% cheaper than Lambda. Scaling down to 50 million requests Workers costs $31 compared to $94 with Lambda, that’s 200% savings.
So, when it comes to low processing requests, particularly with smaller volumes of requests, Workers reigns supreme.
Upstash, a serverless data platform, highlighted other operational considerations for deploying and choosing Workers or Lambda. Among them:
- Performance: Of course we have to mention Lambda’s infamous cold start problem here too. Although there are ongoing efforts to address this problem, they’re not widely supported, and in the meantime require extra configuration/cost, such as by adding Provisioned Concurrency. In contrast, Workers provide faster response times as they do not suffer from the cold start problem.
- Configuration: Lambda provides more flexibility in several respects:
- Memory: Lambda permits memory configuration ranging from 128 MB to 10,240 MB, while Workers have a fixed memory setting at 128 MB.
- Execution Duration: Lambda functions can run for up to 900 seconds, while Workers are limited to 30 seconds.
- Node Dependencies: Lambda supports packages with Node dependencies, whereas Workers do not have Node-based support for such packages.
- Tools and Resources: Lambda offers a more extensive set of tools and resources, including third-party management and deployment tools.
Additional Costs for Workers and Lambda
There are additional paid features and costs around storage, streaming, and tracing to be aware of when building a full application with Workers or Lambda.
Cloudflare charges extra for the following features:
- Workers KV: This key-value data storage can accrue charges for read, write, delete, and list requests as well as stored data.
- Workers Trace Events Logpush: Incurs charges for the delivery of request logs after undergoing filtering or sampling.
- Durable Objects: This feature offers an API for coordinating clients or users, with charges for both requests and duration.
- Durable Objects Transactional Storage API: When your Durable Object code calls methods on
state.storagethere are charges for read request units, write request units, delete requests, and stored data.
AWS charges extra for the following features:
- Ephemeral Storage: Charges are based on the amount of ephemeral storage function allocation and function execution duration.
- Provisioned Concurrency: With Provisioned Concurrency charges are for concurrency configured and period of time configured, as well as requests and duration.
- Lambda HTTP Response Stream Pricing: This feature serves to improve Time to First Byte performance and charges per GB your function writes to the response stream.
- Data Transfer: The data transferred in and out of functions in different regions may incur charges.
- Lambda@Edge Pricing: This feature that enables you to run code closer to application users charges based on the total number of requests and duration.
These new changes mark a significant shift in Workers vs Lambda pricing. Workers’ new pricing model introduces simplicity and transparency, emphasizing billing based on CPU time rather than idle time. This approach not only ensures cost savings but also simplifies cost estimation. We observed huge savings for requests with lower processing times.
On the other hand, Lambda’s pricing structure is more granular, offering users the flexibility to fine-tune costs based on memory allocation, execution duration, and request volume. Lambda’s extensive language support, wider toolset, and flexibility in memory allocation and execution duration make it a great choice for those who require more configurability. We saw that savings for requests with high processing times were significant and scalable.