In a setup involving DynamoDB Streams and Lambda, it’s useful to trigger actions whenever data changes on a specific table. This can improve response times for end users, as the process runs asynchronously.

However, there is a small but significant inefficiency:

In this structure, not every change to a DynamoDB item actually need to trigger a Lambda. At times we only care about a subset of attributes, but DynamoDB Streams would trigger the Lambda every time — regardless of whether the updated attribute is relevant. Insertions, updates on irrelevant fields — everything trigger the sync Lambda. This seems wasteful, especially when considering the cost of Lambda invocations.

This leads us to explore filter events on DynamoDB Streams.

What are Filter Events?

Think of filter events as a smart gatekeeper for your Lambda triggers.

Instead of invoking the Lambda for every single change in the stream, you can define rules such as:

• “Only invoke me if the event is an INSERT,” or
• “Only if a specific attribute equals a specific value.”

Important to know:
It accepts up to 5 filter patterns by default, and up to 10 with a quota extension. If an event matches at least one pattern, the Lambda will be triggered.

List of supported filter operator

How We Used Filter Events

We applied a simple set of filter rules to the Lambda trigger:

• Only invoke the Lambda for MODIFY events.
• Additionally, filter based on key attribute values when necessary, in our case invitationStatus.

The impact was huge:

• We significantly reduced the number of Lambda invocations, as the table contains around 100 attributes, but the Lambda is triggered by changes to only a single attribute.
• Saved on AWS costs.
• Reduced processing load, making the system faster and lighter.

Example: Filter Events Setup in Serverless Framework

Here’s how we defined it using the Serverless Framework (serverless.yml):

functions: dynamoDbStreamHandler: handler: handler.preprocess events: stream: arn: streamArn filterPatterns: eventName: [ MODIFY ] dynamodb: NewImage: invitationStatus: [ ACCEPTED ]

Which converts in below format in console:

"eventName" "MODIFY" "dynamodb" "NewImage" "invitationStatus" "S" "ACCEPTED"

Quick breakdown:

• First filter: Only trigger Lambda for MODIFY events.
• Second filter: Only if the invitationStatus attribute (a String) equals "ACCEPTED"

You can customise and combine more filters based on your table structure and needs!

Common Mistakes to Watch Out For 🔥

Here are a few things that can trip you up while setting up filter events:

1. Incorrect Attribute Path

Use the correct path format for DynamoDB records.

DynamoDB event filtering doesn’t support numeric operators (like numeric equals or numeric range). Even if items are stored as numbers, they appear as strings in the JSON event record. For example:

"quantity" "N" "50"

We know it’s a number because of the "N" property.

If you miss the N, the filter won’t match!

2. Event Name Matching is Case-Sensitive

Event names must be in ALL CAPS.
Use INSERT, MODIFY, REMOVE — not Insert or Modify.

3. Filters are ANDed Together

Multiple conditions in a filter pattern are combined with AND logic — all conditions must be satisfied for the Lambda to trigger.

So: it must be a MODIFY event and the attribute condition must be met.

4. Local Testing Can Be Limited

Some local DynamoDB emulators don’t fully support Streams + filtering.

Always test your filter configurations directly in AWS.

5.Using the Exists operator

Because of the way that JSON event objects from DynamoDB are structured, using the Exists operator requires special care. The Exists operator only works on leaf nodes in the event JSON, so if your filter pattern uses Exists to test for an intermediate node, it won’t work. Consider the following DynamoDB table item:

"ID" "S" "UID" "IdentityDocType" "L" "S" "Aadhar" "S" "Passport" "S" "Voter Card"

You may want to check if "IdentityDocType" exists:

"dynamodb" "NewImage" "IdentityDocType" "exists" true

However, this filter pattern would never return a match because "IdentityDocType" is not a leaf node. Correct format to check existance would be:

"dynamodb" "NewImage" "IdentityDocType" "L" "S" "exists" true

Final Thoughts

DynamoDB Streams + Lambda is a powerful combination for async processing, especially when you don’t want to implement an SQS queue. But if you’re not careful, you might pay for a lot of unnecessary noise.

Using filter events helps you focus only on the changes that actually matter to your app — saving costs, reducing processing, and keeping your architecture clean.

Small change, massive impact. 🚀

Thanks for reading!
Have you used filter events in your projects? Faced similar challenges? Drop a comment below! 👇