Lower Your AWS Lambda Bill by Increasing Memory Size— yep!

Lambda allows you to allocate memory for your functions in increments of 1 MB, ranging from a minimum of 128 MB to a maximum of 10,240 MB (10 GB). When we specify the memory size for a Lambda function, AWS will allocate CPU proportionally. For example, a 256 MB function will receive twice the processing power of a 128 MB function. That looks simple and straightforward, but…

I had this question: would there be an ideal memory size that minimizes the cost of running a given task on Lambda?

In order to answer that, I tested the same task running on multiple memory sizes to check whether such cost/memory trade-off sweet spot exists.

Benchmark Lambdas

I created two Lambda functions to run this test:

  • Fibonacci: basic code that generates a sequence of… you guessed it, Fibonacci numbers. It’s just a low-memory, CPU-intensive task.
  • Benchmarker: invokes the Fibonacci function (or any other function) multiple times, switching memory sizes; in the end, it averages out the results to determine which memory size optimizes speed and cost.

The code is open sourced, in case you’d like to test your own Lambdas. The results presented below will certainly vary according to the function you test, so I encourage you to download the Benchmarker Lambda and run it for yourself.

Photo by Stephen Dawson

Test Parameters

  • AWS region: us-east-1 (N. Virginia)
  • Memory sizes tested: 128, 256, 512, 768, 1024, 1280, 1536, 1792, 2048, 2304, 2560, 2752, 3008
  • Fibonacci was invoked 20 times for each memory size
  • Invocations ran in batches of 10 concurrent requests to speed up the process
  • On each invocation, the Fibonacci function built a sequence of the first 30 Fibonacci numbers
  • Cold starts were ignored to standardize duration results

Test Results

aws lambda memory and cost chart

Average cost (USD) per million executions of the Fibonacci sequence builder (n=30)

The sweetest spots in terms of cost were:

  • 768 MB: that’s the cheapest we can get for this task on Lambda; why 128 MB isn’t cheaper? It takes longer to process, long enough to make it more expensive in total!
  • 2048 MB: although the price is ~3% higher than 768 MB, it runs 2.5x faster; in some cases, it might be worth spending the extra pennies to speed up the processing.

It’s counter-intuitive that a task running with 768 MB can cost less in comparison to 128 MB, for example. It means we can actually lower our AWS bill by increasing memory size in some cases. Of course, we need to know what is the minimum memory our function requires when considering changing our settings. We created Dashbird to make it easier to profile Lambda memory usage and identify thresholds for this kind of benchmarking analysis.

The sharp rise in the line slope (chart above) for higher memory sizes caught my attention. From that point on, it has been reported — although not officially — that Lambda provides two cores. My hypothesis is that the processing power is split among cores and, since my job was using only one core, the test was actually punishing the dual-core function setting. That’s something to look more closely in a future test, with a task that can take advantage of multiple cores.

aws lambda duration and memory chart

Average duration (milliseconds) for running the Fibonacci sequence builder (n=30)

In terms of duration, the chart above seems to have no surprises, but I actually found something consistently weird in the results: 2048 MB always performs faster than 2304 and 2560 MB, which is unexpected. Zooming in to the highest memory sizes we can notice the difference.

Average duration (milliseconds) for running the Fibonacci sequence builder (n=30)

It might be negligible since it represents roughly 2% in extra execution time. Nonetheless, if we’re running this function millions of times or if latency is super important, those extra milliseconds will be relevant.

Understanding exactly which factors are playing a role in producing these unexpected results is hard. Lambda infrastructure is sort of a black box. Maybe there are differences in hardware serving each request, which would introduce some undesirable variability in our tests. Bottom line is: if you want to optimize your Lambda usage for either the fastest execution or lowest cost, you should definitely benchmark your functions.

Improve Lambda performance

We’ve also released the benchmarking function so that you can deploy and test your own Lambda functions for yourself.

How to manage Lambda memory settings?

You can manage the memory settings for your AWS Lambda functions through a few different ways, namely:

  1. AWS Management Console: In the Lambda function configuration page, there is a setting for Memory. You can adjust this slider to increase or decrease the memory allocation.

  2. AWS Command Line Interface (CLI): You can use the update-function-configuration command to change the memory allocation. Here’s an example:

    aws lambda update-function-configuration --function-name my-function --memory-size 512
    
  3. AWS SDKs: You can use the AWS SDKs (such as for Python, Node.js, Java, etc.) to change the memory setting programmatically. Here’s an example with the AWS SDK for Python (boto3):

    import boto3
    
    client = boto3.client('lambda')
    
    response = client.update_function_configuration(
        FunctionName='my-function',
        MemorySize=512
    )
    
  4. AWS CloudFormation: If you’re using AWS CloudFormation to manage your infrastructure, you can specify the MemorySize property in the AWS::Lambda::Function resource. Here’s an example:

    MyLambdaFunction:
      Type: 'AWS::Lambda::Function'
      Properties:
        Handler: index.handler
        Role: arn:aws:iam::123456789012:role/lambda-role
        Code:
          S3Bucket: 'lambda-functions'
          S3Key: 'my-function.zip'
        Runtime: nodejs12.x
        MemorySize: 512

Save Money with Real-Time Lambda Cost Tracking

To reap the benefits and save even more on Lambda you can sign up to Dashbird, a performance monitoring tool tailored specifically for AWS Lambdas. It’s the industry’s favorite end-to-end serverless monitoring platform that is free for the first 1 million invocations.

Sign up to Dashbird

Get detailed overviews of your Lambda functions, how healthy and efficient they are, and how much each one is costing. With full Lambda metric knowledge, you’ll be able to identify trends to help save money.

Dashbird helps you build and operate complex Serverless applications by monitoring, providing observability and insights, with real-time error alerts.

  • Quick 3-minute setup. Start here!
  • Zero code changes
  • Quick overview of memory and cost
  • Start debugging, monitoring, and receiving alerts immediately
  • Centralized, easy-to-access data
  • Monitoring for errors, cold starts, and anomalies 
  • Automatic alerts already set up
  • Customized insights for optimization
  • Complex data visualized
  • No security or performance implications

Read our blog

Making serverless applications reliable and bug-free

In this guide, we’ll talk about common problems developers face with serverless applications on AWS and share some practical strategies to help you monitor and manage your applications more effectively.

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.

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.