5 Lambda pitfalls

1. Lambda Overloading

Sometimes you use the same Lambda function for multiple purposes.

Avoid using one Lambda function for two different tasks because both of these workloads can scale independently and would require different memory configurations.

Also, it makes monitoring challenging because It will be difficult to understand what's going on in your Lambda function by looking at the monitoring. Because there is more than one purpose of invocations, you would not able to relate monitoring metrics to different invocations.

Use purpose-built and Small Lambda Functions

One Lambda should do only one thing. Single Responsibility Principle

Function size is part of the cost

Lambda runtime would download the code from S3 or Docker image registry on every cold-start, the larger the code, the longer the wait, the more you pay

• Since 2021 Lambda functions are billed in one millisecond increments, you can now save money for every millisecond your function runs faster.

2. Using CloudWatch PutMetricData API

PutMetricData API Publishes metric data points to Amazon CloudWatch.

It is a common requirement for you need to collect metrics in your Lambda function. A Lot of people use PutMetricData API from the Lambda function to publish the metrics to CloudWatch.

Your Lambda will make a synchronous HTTP call to the PutMetricData API and this would put your Lambda on hold and it will cost you money.

Instead of using Cloudwatch PutMetricData API, use metric filters.

You can simply emit a logline and within that logline, you emit the name of the metric and then the number of counters that you want to pair with that metric.

Example: You want to count the number of legal argument exceptions in your Lambda. You can put leagalarguments=1

Then you can set up a metric filter with a rule to parse that format of the log line and that will be published into Cloudwatch metrics.

This happens offline and it is not part of the lambda execution.

3. Chaining lambda functions synchronously

In synchronous Lambda calls The first one will wait for the second one to finish, and you’ll be paying for the waiting time.

Don’t call a lambda from another lambda. Run the second function using a service like Step Functions.

4. Using lambda functions as an Orchestrator

A lot of people combine Lambda with SQS because it's an easy way to move messages around from your Lambda and let the output of one function be the input of another.

This pattern can be very challenging to analyse what is actually going on in your application when your data is bouncing around in many Lambda functions

Log streams are independent of each lambda function, and it's difficult to pair all the logs that are related to a particular invocation.

Use Step Functions for Lambda Orchestration

Step functions allow you to build workflows, allow fallbacks, error handling, and retries, and it's very easy to analyse what happened in the step function workflow through the AWS Step Function console.

5. Not using batch processing in SQS and Lambda functions for event processing workloads

When you have a message in your SQS you can set it up to invoke your lambda with a single message. When you have many messages, it's a lot of invocations and will become costly.

The ideal way to do this is to use SQS and Lambda batch processing.

The Lambda function will pull multiple messages from the SQS once and pass all of those messages to the event body of the lambda function invocation.

This way you can iterate all the messages in the input and process them independently.

But you have to be careful in this approach because there would be partial failures. When the failure occurs, you have to put those messages back into the SQS to retry later.

There is an easy way to handle partial failures using failure reporting. You can return failed message ids from your Lambda to the SQS. Return the failed message ids that will indicate SQS to put those messages back into the queue. This way only the failed message will reappear in the Queue for processing and the successful will be deleted from the Queue.

Check out my Lambda cost optimization tips here.