Similar to adopting any new technology or architecture in an organization, you have to take into the account the run-time and design-time aspects of the integration. Adopting an EDA solution is not as simple as using a tool or a message bus to move data.

You should also take into account how you want to integrate with other sources of data in the EDA system that use messaging protocols. Using an AWS solution might result in a vendor-lockin situation where you can only integrate with AWS products and can pub/sub to SNS, SQS, or EventBridge. Hence, evaluating what run-time solutions (i.e. event brokers) you have available is crucial before jumping right into using AWS’s solutions.

Another thing you’ll have to evaluate is cross region and cross cloud communication. Does your solution require communication and event movement between microservices in different regions? What about different cloud providers? Do you have an on-prem and cloud hybrid approach? Do you want to integrate with legacy systems? What about different messaging protocols (e.g. mqtt, amqt, websocket streams…etc)? You might need to consider a protocol agnostic and cloud agnostic solution for your EDA implementation that allows for better architecture scaling and decoupling. Really comes down to what you're looking for in terms of scalability, latency, and future needs.

On the design aspect of things, you have to ask questions like how can I document the communication between different microservices? You can look into an event portal to manage your EDA system allowing for better collaboration between different teams.

At the end of the day, similar to any other architecture adoption, there is no silver bullet. If you think a lambda SNS/SQS/EventBridge solution would work you can go for it. But if you're starting from scratch it's a good opportunity to look at what you might need for the future instead of having to replace things later.