Menu
I'm trying to understand the behavior of S3 Event Notification trigger. I have s3 events to trigger lambda. Lambda captures the event and file metadata to dynamodb. There would be around 50k event triggers in short burst across the day. If I had to add SNS in the workflow and have SNS trigger lambda, what are the advantages with sns vs s3 directly invoking lambda?
388
When working with AWS S3 Events that require processing in AWS Lambda, there are two common event-driven design patterns because S3 Notifications can target Lambda, SNS and SQS: Invoke the Lambda directly through S3 event. Send the S3 event to an SNS/SQS queue which in turn triggers the Lambda.
Amazon SNS and AWS Lambda are integrated so you can invoke Lambda functions with Amazon SNS notifications. When a message is published to an SNS topic that has a Lambda function subscribed to it, the Lambda function is invoked with the payload of the published message.
You can use a Lambda function to process Amazon Simple Notification Service (Amazon SNS) notifications. Amazon SNS supports Lambda functions as a target for messages sent to a topic. You can subscribe your function to topics in the same account or in other AWS accounts.
Having SQS in between SNS and Lambda allows reprocessing older unprocessed events in case Lambda fails to process. SQS allows to put a delay, so that message gets processed after some time, it may be useful in the scenario where data takes time to be available.
There is no gained advantage. Both S3 and SNS events are asynchronous event sources and behave the same way. See: Lambda supported event sources And: Lambda Retry on Errors (Asynchronous invocation part), which highlights nicely the lambda behavior with specific types of event sources.
Simply doing S3 -> Lambda is sufficient.
140
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
