Easily build complex reports
Monitoring and efficiency metrics
Custom cost allocation tags
Network cost visibility
Organizational cost hierarchies
Budgeting and budget alerts
Discover active resources
Consumption-based insights
Alerts for unexpected charges
Automated AWS cost savings
Discover cost savings
Unified view of AWS discounts
COGS and business metrics
Model savings plans
Collaborate on cost initiatives
Create and manage your teams
Automate cloud infrastructure
Cloud cost issue tracking
Detect cost spikes
by Emily Dunenfeld
Contents
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).
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:
Workers pricing table
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:
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.
Lambda pricing table for x86 architecture
Lambda pricing table for ARM architecture
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.
Lambda memory pricing for x86 and architectures
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.
Workers and Lambda both have impressive monthly offerings for free requests and CPU times.
Workers Free Per Month ($5 subscription)
Lambda Free Per Month
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.
Workers Free Plan
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.
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.
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
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.
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.
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
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:
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:
state.storage
AWS charges extra for the following features:
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.
Cloudflare has created a disruptive pricing model by charging only for CPU time. While some serverless workloads will benefit from Lambda’s more granular cost structure, Cloudflare Workers are now the definitively cheaper option for Javascript backends.
MongoDB Atlas is the cost-effective choice for production workloads where high-availability is a requirement.
Grafana is a strong competitor to the monitoring and observability features of Datadog for a fraction of the price.
AWS is implementing a policy update that will no longer allow Reserved Instances and Savings Plans to be shared across end customers.