Welcome back. In this video, I want to dive a little deeper into AWS Lambda and discuss how we can optimize the execution time and memory allocation for our Lambda functions, which in turn will help us reduce our costs.

Now, like I mentioned earlier, the cost to run a Lambda function is going to equal the number of requests to that function, multiplied by the execution time in milliseconds and the total memory allocated to that function. So the two factors in this equation that we're likely going to have the most control over are a function's execution time and memory allocation.

So let's start by discussing some best practices for reducing the execution time for your Lambda functions. After all, the faster your function runs, the less it's going to cost you to run it. You should avoid including any unnecessary dependencies in your deployment packages, and use a technique like tree shaking to remove any dependencies you don't need.

You can also use Lambda Layers to share common dependencies across multiple functions. Consider using a tool like webpack to bundle and minify your packages before deployment. Keeping your Lambda packages smaller will reduce your function’s cold start time, and therefore its total execution time. And we covered Lambda cold starts and the challenges they posed for cost optimization in a lot more detail in our lesson on Container and Serverless Cost Savings in AWS, so I encourage you to check that out if you haven't already.

You'll also want to leverage your function’s execution context whenever possible, storing any reusable objects like database connections and SDK clients outside of your Lambda function handler to avoid having to reinitialize them every time your function is executed. It's also a good idea to cache any static data outside the handler whenever possible as well. Whenever a warm start occurs, any code you've placed outside the handler doesn't need to be run, which reduces your function's execution time and therefore its cost.

Beyond that, you may want to investigate switching your functions to use ARM-based AWS Graviton2 processors if possible, as this can offer improved performance at up to a 20% lower cost compared to Lambda functions that run on x86 processors. And it's easy to migrate to Graviton2, especially if your functions don't have any binary dependencies. Nearly all current Lambda runtimes are supported, though you will need to rebuild any binaries in your function packages if they aren't already built for the ARM architecture.

And no matter which architecture you use, it's always a good idea to leverage profiling and tracing tools like Amazon CodeGuru Profiler, an AWS X-ray, to identify any bottlenecks or slow external calls within your functions that could increase their execution time.

Now let's take a look at memory allocation.

When you configure a Lambda function, you have to allocate a certain amount of memory to it, anywhere from 128 up to 10240 megabytes in 1MB increments. And with Lambda, the amount of CPU power allocated to your function scales proportionately based on the amount of memory you've allocated to it. This in turn can impact your function's execution time.

So, as you can imagine, this creates an interesting balancing act. If you allocate a lower amount of memory to your function, it will have less CPU power, which might mean it takes longer to execute. This would result in a lower cost per second, but a higher cost overall due to the longer execution time. Or if you allocate a higher amount of memory to your function, the greater CPU power might reduce your function's execution time enough to lower your overall cost.

For instance, let's say that when you allocate 512 megabytes of memory to your function, it takes two seconds to execute. And maybe if you double its memory up to 1024 megabytes, maybe that cuts the execution time in half down to one second. So our goal here is to find that sweet spot where the combination of memory and execution time is just right to result in the lowest possible cost.

And to do that, we can leverage the open-source AWS Lambda Power Tuning tool, which is available on GitHub. It uses an AWS Step function that runs your Lambda function several times with different memory configurations in an effort to help you find that sweet spot. It will even output a graph that plots each memory allocation amount against its associated execution time and execution cost, along with a summary that shows which memory allocation amounts resulted in the best and worst cost.

So putting all this together, you can start by doing a baseline measurement of your code's memory allocation, average execution time, and cold start frequency. Then you can do some code profiling and local build time optimizations with tools like CodeGuru Profiler and webpack. Then finally you can use the AWS Lambda Power Tuning tool to find the ideal memory setting for your function.

And of course, you should continue to monitor your function over time and repeat this process anytime your production workloads change.

Optimizing Lambda Execution Time and Memory Allocation

About