This post was written by Prashanth HN, CTO & co-founder of Antstack.io, a Lumigo partner company. Antstack is a born-in-the-cloud, serverless-focused consulting company.
Serverless is a great way to reduce the cost of running applications. Lambda functions, by nature, make it very easy to use the exact amount of resources we need at any given point. In this post, we deep dive into Lambda costs, how they are calculated, and explore how to optimize them.
How are Lambda costs calculated?
Lambda costs are calculated from two parameters (all prices are for AWS N.Virginia, US-EAST-1):
- $0.20 per 1M requests
- Duration $0.0000166667 for every GB-second
While there are ways to optimize the number of requests, we will focus on optimizing our GB-second, i.e., the time our Lambda takes to execute our code. Here’s a reference table for lambda runtime costs by memory size:
GB-Second = (Allocated Memory/1024) * Runtime
Example: Say we have a Lambda function that takes an average of 1 second for each run, and we ran it 1000 times. Our total runtime is 1000 seconds. Let’s assume that the allocated memory for this Lambda function is 1024MB. The GB-second calculation will is:
*(1024/1024)1000 = 1000 GB-Seconds
And our total GB-second cost would be
1000*0000166667 = $0.0166667
We will have to add a cost of 1000 requests on top of this.
How to calculate your Lambda costs?
You can do all the math yourself, or you can use the lumigo-cli to do the heavy lifting. You can get the Lumigo CLI here: https://github.com/lumigo-io/lumigo-CLI#usage and then use the command lumigo-cli analyze-lambda-cost.
Lumigo-CLI is an open-source CLI from Lumigo that is like a Swiss Army Knife of tools and utilities that help you develop and manage serverless applications.
Running the command in the CLI gives you a list of all your functions, costs for the last 30 days, and the average cost per invocation.
If you are using the Lumigo Platform in your stack, you can also find this with a nice chart under the dashboard of each function:
As well as in the Transactions page for each transaction listed:
Now that we know how to find our current costs, let’s explore how we can optimize Lambda and reduce costs.
Optimizing Lambda Costs
The lowest config is not the cheapest
Those of us who come from the world EC2 instances are used to thinking the lowest config will result in the lowest cost. But that’s not the case with Lambda functions. Let’s explore this with an example:
Lambda cost for 128MB = 0.00000104, Time: 448ms
Lambda cost for 512MB = 0.00000083. Time: 81ms
We are getting ~5X better performance at a lower cost!
Of course, this isn’t the case with all the Lambda functions, but generally, there is always the potential for a large performance advantage with little or no cost implications (or even lower costs). When we increase the memory, we are also proportionately increasing the vCPU available to that Lambda, improving the Lambda function’s overall performance. This is how you can end up with an overall lower cost.
From the AWS docs:
“Lambda allocates CPU power linearly in proportion to the amount of memory configured. At 1,792 MB, a function has the equivalent of one full vCPU (one vCPU-second of credits per second).”
Source: https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html
That’s awesome, but how?
AWS Lambda Power Tuning
One answer is the AWS Lambda Power Tuning tool:
AWS Lambda Power Tuning is an open-source tool that can help you visualize and fine-tune the memory/power configuration of Lambda functions. It runs in your own AWS account – powered by AWS Step Functions – and it supports three optimization strategies: cost, speed, and balanced.
Source: https://github.com/alexcasalboni/aws-lambda-power-tuning
The Lambda Power Tuning Tool runs a specified lambda function through multiple memory configurations using step-functions. It makes it easy for us to visualize how our code behaves in different memory configurations. Once we find the best config for the Lambda function, we could go ahead and change that.
The Lumigo-CLI programmatic Lambda Power Tuning
The best memory configuration for today’s needs may not be the best a few months down the line. There could be a change in code, implementation, or even dependencies. Using Lumigo-CLI, we can run AWS Lambda Power Tuning programmatically. We can run Lumigo-CLI post-deployment and optimize Lambda functions on each deployment.
The command looks like this:
lumigo-cli powertune-lambda -f data.json -n functionName -r region -s cost|speed|balanced --autoOptimize -z
These look at the options we used in the command:
-f data.json – The file that contains the input event for the Lambda function. The input file is crucial because the Lambda function will be tuned based on the amount of time it takes to process it. So be very careful with this as you could potentially mistune the Lambda.
-n functionName – Name of the function to be tuned
-r region – Region
-s, –strategy – The strategy we want to apply to tuning the function. Available options are cost, speed, and balanced. Which one we should use depends on our business objectives, whether the cost is more important than response time. If you choose ‘balanced,’ you could optionally pass the weightage for the balance using -w, –balancedWeight=balancedWeight
–autoOptimize – If this flag is passed, the tool will automatically update the Lambda function with the desired configuration
-z, -noVisualization – This is specifically useful when using in CI/CD automation as we don’t want it to prompt us to see the visualization, which is the default behavior
For all available options, please see –https://github.com/lumigo-io/lumigo-CLI#lumigo-cli-powertune-lambda
Every time we run this command, we will auto-optimize the lambda function and update it with the new config.
Other Opportunities to Reduce Lambda Costs
Optimizing for warm starts while using NodeJS
The code in your Lambda function outside of the exports block is loaded/executed only once (cold start). On a repeat execution (warm start), this block of code will be ignored, and only what’s inside your module will be executed. This is an excellent opportunity for us to push out stuff that is going to remain constant — and only execute it on the first start, for example:
//Block of code which is executed only during cold start
'use strict'
const message = "Hello Serverless"
//Block of code which is executed every time
module.exports.hello = async (event) => {
return {
statusCode: 200,
body: JSON.stringify(
{
message,
input: event,
},
null,
2,
),
}
}
Optimizing Lambda functions using tree-shaking
If you deploy a NodeJS app on Lambda, dependencies inside ‘node_modules’ can get very big very fast. Ideally, we should bundle only the code/dependencies that are required by a particular Lambda function. Doing this could improve the cold start performance as there is much less code to load. Lumigo even went ahead and did a performance test to check this hypothesis. We can achieve optimal bundling using tree-shaking through webpack. You can read Antstack’s detailed guide on bundling Lambda functions using Webpack tree shaking.
Lumigo Lambda CPU Extension:
Lumigo recently added the CPU extension, which gives you the CPU load. It can help you determine whether your function is CPU-bound or IO-bound. For IO-bound functions, you can use a configuration with less memory and still get the same performance.
Savings Plan for Lambda:
Earlier this year AWS announced the availability of “Savings Plan” for Lambda. Savings Plan lets you save up to 17% of the cost by giving a 1-year or 3-year commitment. If you already have a “Compute Savings Plan”, that can be extended to Lambda as well. If you are new to Savings Plan, you can find recommendations based on your usage under the AWS Cost Explorer -> Savings Plan -> Recommendations.
Want to learn more? Have questions? Join our webinar
Join me and Uri Parush of Lumigo for a live webinar with a Q&A session this Thursday, December 3 at 10:00 AM PST, 1:00 PM ET, 19:00 CEST. In addition to what we believe will be very helpful information about Lambda cost optimization, Lumigo will send you one of these cool t-shirts of your choice, if you connect the Lumigo tracer to your Lambdas.
You can register for the webinar here: https://info.lumigo.io/webinar-optimizing-lambda-costs