What are the pros/cons and use cases of using EventBridge, Lambda with queues, and SNS for event-driven architectures?

Hey Alvaro!

EventBridge really shines for its rules, with the ability to filter based on data within the event. This allow customers to have a central event bus and routing between microservices. See this sample application I built: https://github.com/aws-samples/aws-serverless-ecommerce-platform For example, if you have an e-commerce application and you use the event bus to send when an order is created, you could create a "concierge treatment" service that will react on new orders with a value above 1000 USD. This allow more flexibility in changing the business rules by changing the events within EventBridge.

However, EventBridge will be more limited than SNS when it comes to large-scale fanout (e.g. sending an event to 100 000s of users) or for low-latency use-cases.

If you think about both of them together, you could have an event sent to EventBridge, with a rule sending it to an SNS topic that would then send it to end-users.

In regard to using queues to Lambda, it's mostly about reliability, batching and preventing excessive pressures if the Lambda function contacts non-scalable resources (e.g. a DB). If you invoke a Lambda function asynchronously (e.g. direct EventBridge or SNS to Lambda), you have less control over the retry mechanisms (max 3 invocations), but you can still have a DLQ. With SQS, you'll have more control there. Then, if we're talking about a function that receives lots of messages, with SQS/Kinesis, Lambda uses Event Source Mapping, where an internal system will pull messages, batch them together, and send them to the Lambda execution environment.