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.
The basic workflow of the function is as follows:
- A cron defaulted to run every 5 minutes kicks off execution of the Lambda function
- The Lambda function collects REPORT logs from 2-1 durations ago (e.g. 10 min to 5 min ago for the default)
- REPORT logs are the last line of each execution’s logs reporting the usage
- Logs are paged, so high throughput functions may cause high Lambda Utilization run times
- Each log from CloudWatch is parsed and produces Metricly samples
- Samples from all logs are collapsed into a single Metricly ingest payload and sent to Metricly
Quickstart via CloudFormation Script
- Open this link to be redirected to your AWS console: Launch CloudFormation Script.
- Provide your Metricly Custom API key to obtain your APIKey parameter. This can be found here.
- Add any Lambda function names you want monitored to the FunctionNames parameter in a comma delimited list. (This function monitors itself by default.)
- Check I acknowledge… checkbox at the bottom.
- Click Create. In about 5 minutes, you’ll start seeing the additional metrics in Metricly!
Rightsizing Lambda Functions
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.
1. Check How Much RAM the function is using.
Lambda Functions using more than 128mb of RAM should be vetted for optimization. 128mb is the minimum amount required to run a function.
2. Determine if the function’s memory is highly volatile.
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.
3. Gauge how CPU intensive your function is.
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.
4. Check if the function’s normal invocation durations are close to the Lambda limit of 300 seconds.
Reducing the memory can increase the invocation duration which could cause more functions to time out.
5. Determine if the function primarily makes network calls or performs CPU limited calculations.
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.