AWS Lambda Power Tuning

I launched this poll on Apr 17th, and today I am happy to share my results and my new OSS project, powered by the Serverless Framework and AWS Step Functions.

Looking at these results, it turns out that a considerable amount of AWS Lambda developers like to manually tune their Lambda Functions RAM configuration (or let's say "power"). The biggest majority (52%) is just choosing the same power all the time, though. Interestingly, almost 54% of those fixed-choice developers are always going for the "cheapest" configuration. But is it really the cheapest? Well, it is definitely not the fastest, unless your Functions end up in a lucky container.

As many great thinkers pointed out in the Twitter thread, there are many factors involved, and I'd normally tend to agree with the "Always 1GB" group. I guess that many in this group went for manual tuning many times, and their heuristics results convinced them to blindly adopt a reasonable trade-off between speed and cost.

But what if you had a tool that could automatically and quickly provide statistically meaningful results, without any manual tuning or blind guesses?

I started from this simple question a few weeks ago, and I tried to combine my passion for data analysis, FaaS, and new cool AWS services into a single project.

AWS Lambda Power Tuning - Serverless Service

Ultimately, I wanted to build a service that anybody could quickly configure and deploy to optimize any Lambda Function. The technical objectives were to keep it quick, realistic, language agnostic, and easy to deploy. That's why I chose the Serverless Framework, so I didn't have to reinvent the wheel. I also chose AWS Step Functions to orchestrate my Lambda Functions and design a solution via visual workflows.

Since you don't always want to test every possible configuration (there are 23 of them!), I build a simple tool that can generate a dynamic state machine where each parallel branch will run your Lambda Function a reasonable number of times with a specific power configuration (i.e. 128MB, 256MB, etc.). Ideally, the output of this state machine will be the optimal configuration.

State Machine Customization

Of course, you can configure a few parameters and provide a payload that will be used for every invocation.

In order to reduce the impact of cold starts and provide statistically relevant results, the Executor will execute your Lambda Function N times (I'd recommend N >= 100) and compute duration and prices by applying a trimmed mean (i.e. the lowest and highest values will be discarded).

You can also decide whether the N invocations will be executed sequentially or in parallel: I'd recommend parallel invocations, but I decided to make it sequential by default to avoid throttling issues for newcomers.

Unless you provide a comma-separated list of power values at generation time, every possible configuration will be tested (yes, 23 parallel branches). During my tests, I used only a subset of the power values. You can generate a smaller state machine as follows:

npm run generate -- -A YOUR_ACCOUNT_ID -P 128,256,512,1024,1536

Once the state machine is generated, the Serverless Framework will take care of deploying everything to your AWS Account and you will be able to execute the state machine directly on the AWS Console.

Conclusions

I hope this project will be useful to some of you and will also evolve over time. New optimizations strategies could be implemented, we could support dynamic payloads, multi-region tests, and much more. I'm already planning to remove any manual operation at all, and reduce code complexity by using other serverless plugins (for example, this one).

Feel free to contribute or open new issues here. Any other personal feedback will be very welcome too :)