Developing serverless REST APIs with API Gateway and AWS Lambda is now a common practice. With Amazon extending the API Gateway timeout beyond 29 seconds), serverless REST APIs can now handle complex workflows like long-running machine learning predictions and Generative AI tasks.
In this article, we’ll explore how to leverage the AWS Lambda Power Tuning tool to optimize serverless REST APIs (API Gateway configured with proxy integration + AWS Lambda) for both performance and cost efficiency.
AWS Lambda Power Tuning
The AWS Lambda Power Tuning tool is an AWS Step Functions-based state machine designed to test Lambda performance under various memory configurations. It helps optimize for cost or performance (or a balance of both) and is compatible with any Lambda runtime.
Getting Started
To deploy the AWS Lambda Power Tuning tool, follow the instructions in the deployment guide. Once deployed, the state machine will appear in AWS Step Functions, as shown below:
Executing the Tool
When executing the state machine, you can customize several parameters. Below is a summary:
Parameter | Description |
---|---|
lambdaARN | Required. ARN of the Lambda function to optimize. |
num | Required. Number of invocations per power configuration (min: 5, recommended: 10–100). |
powerValues | Optional. Memory values to test (128MB–10,240MB). Defaults to values set at deployment. |
payload | Optional. Request payload for the API. Can support a static payload for every invocation or a payload from a list with relative weights |
payloadS3 | S3 object location for payloads >256KB. |
parallelInvocation | Runs all invocations in parallel if set to true (default: false). |
strategy | It can be "cost" or "speed" or "balanced"; if you use "cost" the tool will suggest the cheapest option, while if you use "speed" the state machine will suggest the fastest option. When using "balanced" the state machine will choose a compromise between "cost" and "speed" according to the parameter "balancedWeight". |
balancedWeight | Parameter that represents the trade-off between cost and speed. Value is between 0 and 1, where 0.0 is equivalent to "speed" strategy, 1.0 is equivalent to "cost" strategy. Default :0.5 |
preProcessorARN | ARN of a Lambda function to run before each invocation of the target function. |
postProcessorARN | ARN of a Lambda function to run after each invocation of the target function. |
includeOutputResults | Includes average cost and duration for each configuration in the final output (default: false). |
onlyColdStarts | Forces all invocations to be cold starts |
Refer to the official official documentation. for detailed explanations.
Example Input
{
"lambdaARN": "<arn of the function being executed>",
"powerValues": [ 128, 256, 512, 1024, 1536, 2048, 2560, 3072],
"num": 10,
"strategy": "speed",
"payload": {...},
"parallelInvocation": true,
"includeOutputResults": true,
"onlyColdStarts": true
}
Input Payloads for Proxy Integration
Inputs to test Lambda functions behind API Gateway can vary by HTTP method. Below are sample payload links for common methods:
HTTP Method | GitHub URL |
---|---|
POST | Click for sample input |
PUT | Click for sample input |
GET | Click for sample input |
GET (With Path Parameters) | Click for sample input |
GET (With QueryString) | Click for sample input |
DELETE | Click for sample input |
PATCH | Click for sample input |
Weighted Payloads
The tool also offers the option to define multiple payloads for HTTP methods, making it suitable for scenarios where payload structures vary significantly and can impact performance or speed. Refer Weighted Payloads in official documentation to understand how weighted payloads work
HTTP Method | GitHub URL |
---|---|
POST (With Weighted Payloads) | Click for sample input |
Pre/post-processing functions
The tool also provides the ability to run custom logic before and after the execution of the lambda function. This logic should be implemented as lambda functions. Refer Pre/Post-processing functions in official documentation to understand how weighted payloads work
HTTP Method | GitHub URL |
---|---|
Post (With Pre/Post functions) | Click for sample input |
Output
A sample execution output is shown below:
{
"output": {
"power": 2048,
"cost": 0.0000018816000000000001,
"duration": 54.95933333333334,
"stateMachine": {
"executionCost": 0.00075,
"lambdaCost": 0.0013002423000000002,
"visualization": "https://lambda-power-tuning.show/#encodeddata"
},
"stats": [
{"value": 128, "averagePrice": 9.345e-7, "averageDuration": 443.8995},
{"value": 2048, "averagePrice": 0.0000018816, "averageDuration": 54.9593}
]
}
}
A brief description of the output is given below
Key | Description |
---|---|
output.power | The optimal memory configuration (RAM). |
output.cost | The corresponding average cost (per invocation). |
output.duration | The corresponding average duration (per invocation). |
output.stateMachine.executionCost | The AWS Step Functions cost corresponding to this state machine execution (fixed value for "worst" case). |
output.stateMachine.lambdaCost | The AWS Lambda cost corresponding to this state machine execution (depending on number of executions and average execution time). |
output.stateMachine.visualization | A URL to visualize and inspect average statistics about cost and performance. Note: Average statistics are NOT shared with the server, as all data is encoded in the URL hash, client-side only. |
output.stats | The average duration and cost for every tested power value configuration. Only included if includeOutputResults is set to a truthy value. |
Visualizing the output
The element - output.stateMachine.visualization provides a visualization URL - https://lambda-power-tuning.show/#encodeddata that can be used to visualize the result.
The source code of the UI is also open source - https://github.com/matteo-ronchetti/aws-lambda-power-tuning-ui
The outputs of POST / GET (With Path Parameters) are shown below
POST
GET (With Path Parameters)
The tool includes a feature to compare the results of function invocations. To see how this functionality is applied in practice, check out the article Secrets Management in .NET Lambda, where we demonstrate its use to compare the performance of reading secrets in a .NET Lambda.
Top comments (0)