6 quick ways to cut cost on your Lambdas

We’ve talked about how serverless architecture is a great option for companies that are looking to optimize costs. Just like with all app building and developments, monitoring the performance of your implementation is crucial and we, the folks at Dashbird, understand this need all too well – this is why we’ve spent the better part of the past year and a half to create a monitoring and observability solution for AWS Lambda and other Serverless services.

One of those important features for serverless users is the cost monitoring solution that Dashbird offers. I’ll walk you through how it works and how you too can use this to your advantage.

Dashbird serverless dashboard

Firstly, you’ll need a Dashbird account. If you don’t have one yet, fear not, you can sign up for free to get you started. 

Sign up now

Before we jump straight in, let’s first take a second to discuss how AWS Lambda pricing works. A quick recap: 

  • You get one million invocations for free and 3.2M seconds of compute time, every month. 
  • You only pay for the invocations you use on top of those. 
  • For every individual invocation, you pay $0.0000002 but it’s important to note that duration plays an important factor too as you’ll have to pay about $0.0000166667 for every Gb/s after that.

I know those numbers have enough zeros to make the AWS Lambda promise of cutting down your server bills seem amazing but the truth is, they add up really quickly. Because of the nature of the serverless architecture, you’ll split every functionality into smaller, little functions that do one thing and return the result so the number of executions will be high. Development environments and production environments are two entirely different beasts when it comes to cost too.

How to keep Lambda costs down?

There are a few ways to get those costs down from reducing cold-starts and optimizing memory utilization to picking a runtime that better fits your needs.

Reducing cold starts impact

We’ve already established the way AWS Lambda works and is priced so it’s going to be of no surprise when I say that cold starts are going to be expensive since you’ll have to pay for the time it takes to spin up those containers.

There are a couple of ways to address these but let’s first look at how you go about seeing which functions have cold start issues and how much of an impact they really have.

Going into Dashbird, you jump into the Lambda view and look on the right side of the screen. From here you can filter to view only the cold starts.

The little anomaly icon you see next to each function is a cold-start.

Now that we have a simple way to identify our cost increasing cold-starts, we need a way to address them.

Use a runtime that boots up fast

One of the most popular ways of dealing with cold-starts is by using a runtime that has faster bootup and right now the fastest way to do that is by using Python. Based on a simple benchmark Nathan Malishev did a while back, it’s clear that Python is the winner.

Use HTTP calls instead of HTTPS

Serkan Özal has looked into this claim and using a simple function that accessed DynamoDB, he concluded that using HTTP instead of HTTPS is a lot faster, especially when using Lambdas with lower memory settings since the transaction is much simpler.

Bump up the memory limit

This might seem counterproductive to the already established goal of saving money on your Lambdas, but since you get charged by execution, it might make sense to increase the memory of your function thus having it execute a lot faster. Lambda containers also spin up considerably faster when the function has more memory so while this is probably not a universal solution to the cold-start issue there are some cases where this might make a lot of sense.

Downgrade the memory of your functions

Sometimes we overestimate the memory needs of a function and instead of upgrading by small memory increments we throw caution to the wind and go big. Since AWS Lambda has a linear pricing model, 1024mb is 8 times more expensive than 128mb and 3008mb is 24 times more expensive than 128mb. So you can imagine a scenario where you could cut Lambda cost down 10x or even more just by making small memory adjustments.

Let’s jump back to our Dashbird Lambda panel to look at the execution speeds of our functions. After a few seconds, I see a function that looks suspicious.

As you see in the photo, our function uses only 3% of the 1024mb of RAM allocated. Before jumping into my AWS console to take drastic measures, let’s look at multiple invocations of the same function over several days to make sure that we’re looking at a one-off or some sort of exception to the rule.

I quickly filter out this function and compare the other invocations I see there, and I can easily tell that this function is using up to 6% of the memory allocated – I’m now comfortable reducing the memory of that function to 128MB saving me about $25 a month on this function alone. Now imagine doing this for 10, 25, or 100 functions. It adds up.

Decrease Lambda execution time

We’ve talked about how Python is great at reducing boot-up times for your containers but as it turns out, for overall execution speed for warm containers Python might not be the best choice.

Yun Zhi Lin wrote an excellent benchmark on this very subject where he went through all the runtimes available for AWS Lambda and compared the execution duration of each one. As it turns out, .Net Core 2.0 wins the race by a good margin with Node and Python coming in second and third.

We hope this has been of help in shedding some light on the different ways to cut AWS Lambda cost and while these might be some of the most popular ways for developers to scale down those AWS bills, they are not the only ones. You might also want to check out our article on how to leverage Lambda cache to cut costs.

Read our blog

ANNOUNCEMENT: new pricing and the end of free tier

Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

AWS Lambda Free Tier: Where Are The Limits?

In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.

More articles

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.