When not to use a Lambda function
It’s not always necessary to use a Lambda function. In some situations, you may have other alternatives that can improve performance.
For functions that act as orchestrators, calling other services and functions and coordinating work, this can result in idle time in the function. The function typically waits while other tasks are performed, increasing cost. In most cases, moving the orchestration flow to AWS Step Functions creates a more maintainable and resilient state machine, and can help reduce cost.
Lambda functions that transport data from one service to another without performing any business logic on that data can often be replaced with service integrations. For example, it’s usually not necessary to put a Lambda function between API Gateway and DynamoDB to read an item from a table. This can be achieved by using VTL in an API Gateway service integration directly with DynamoDB. This can help improve scalability and decrease cost.
If a microservice sends all events to a Lambda function for filtering, and only operates on a small subset of events, you may be able to implement the filtering before invoking the function. For example:
-
S3 events can be filtered on prefix and suffix patterns, enabling you to filter on only certain object keys.
-
SNS can filter messages before invoking targets.
-
With Amazon EventBridge, you can use powerful content filtering logic within the rules to be highly selective in which events trigger your functions.
Using filters can reduce cost and improve efficiency because you are only invoking Lambda functions for events that your application cares about.
