The Lambda Function Sizing tool parses Lambda function CloudWatch logs to pull billable duration and memory metrics. It’s primarily used to calculate a memory utilization metric, calculated off the max used and billable memory values. These values are then sent to Metricly. The CloudFormation template is the easiest way to start using the project.
aws.lambda.billed are the metrics created upon installation. You can find these throughout the product in dashboards, the Metric Explorer page, and the Resource Utilization report.
Use the following steps to evaluate if the function can have its memory reduced. We recommend only re-sizing functions utilizing <50% of their memory.
Lambda Functions using more than 128mb of RAM should be vetted for optimization. 128mb is the minimum amount required to run a function.
You can do this by looking at its min-max memory utilization. If it varies greatly (spiking up to 70-90%), it is dangerous to reduce the memory any further without risking the occasional invocation to error out. This usually means your function is not a good candidate for resizing–but if your application can gracefully handle failures, then continue on this checklist.
If your function is CPU intensive, you may not save much money reducing the memory utilization. Less memory means less CPU. Lowering the memory increases invocation duration, thus increasing cost. For small memory allocations (less than 1.5GB) and medium invocation duration (~5-60 sec) a 50% decrease in memory usage can lead to a 100% increase in run time, resulting in the same cost. Refer to experimentation and this Medium article for more information.
Reducing the memory can increase the invocation duration which could cause more functions to time out.
If so, your function is a perfect candidate to optimize memory. Network intensive Lambda functions don’t usually see much of an increase in invocation duration, which means a 50% reduction in memory is a 50% reduction in cost.