We have to initially write a cron for whenever the solution has to be run. Currently, if the script has to run from Monday to Friday, we have to do some script. It would be easy if we had an option to select multiple things to run the script from Monday to Friday.
An Amazon EventBridge rule can be governed by only a single Cron expression. It would be good if the solution provided a feature to add multiple Cron expressions to one rule.
Cloud Architect at a transportation company with 10,001+ employees
Real User
Mar 17, 2023
Amazon EventBridge doesn't have the feature of event replay. Let's say a customer reports an issue, and you want to reproduce the error. There is no source or feature where you can click on a button or put in a query and then try to reproduce the problem on a dashboard. So there is no such mechanism for that. The only way to debug it is to pass that particular event again and make it live to reproduce. That's not the only feature we need. The second thing is about documentation, but they have improved it a lot now. They started it, but it still needs more improvement. They use open API specifications to document events, but Amazon EventBridge is an async model solution. Therefore, it should have async API documentation, not open API. Open API framework documentation works on rest methods like GET, POST, PUT, etc. However, EventBridge does not work with REST methods at all, and it works with a source and target mechanism or a publisher and subscriber model. So there is a channel, publisher, and subscriber it uses. And in open API, you don't find these things, and you can only find these things in the async API documentation. When you want to tell people about a particular model or schema that an event looks like, you write it in the documentation. Then, you can generate the code of the whole library. For example, if you want to consume an event, you can prepopulate the classes and functions, and developers can easily work on it. These features are available in async API but not in AWS. AWS provides the rest API, which requires a lot of customization. So I would say that's missing in the AWS cloud.
Find out what your peers are saying about Amazon Web Services (AWS), Solace, IBM and others in Message Oriented Middleware (MOM). Updated: December 2025.
Message Oriented Middleware (MOM) abstracts communication between distributed applications by passing messages between them, enhancing interoperability and scalability across diverse platforms.
Widely used in enterprise environments, MOM facilitates asynchronous communication, ensuring that applications can send and receive messages without needing to be online simultaneously. This results in improved system resilience and flexibility. By decoupling the sender and receiver, MOM allows...
We have to initially write a cron for whenever the solution has to be run. Currently, if the script has to run from Monday to Friday, we have to do some script. It would be easy if we had an option to select multiple things to run the script from Monday to Friday.
An Amazon EventBridge rule can be governed by only a single Cron expression. It would be good if the solution provided a feature to add multiple Cron expressions to one rule.
Amazon EventBridge doesn't have the feature of event replay. Let's say a customer reports an issue, and you want to reproduce the error. There is no source or feature where you can click on a button or put in a query and then try to reproduce the problem on a dashboard. So there is no such mechanism for that. The only way to debug it is to pass that particular event again and make it live to reproduce. That's not the only feature we need. The second thing is about documentation, but they have improved it a lot now. They started it, but it still needs more improvement. They use open API specifications to document events, but Amazon EventBridge is an async model solution. Therefore, it should have async API documentation, not open API. Open API framework documentation works on rest methods like GET, POST, PUT, etc. However, EventBridge does not work with REST methods at all, and it works with a source and target mechanism or a publisher and subscriber model. So there is a channel, publisher, and subscriber it uses. And in open API, you don't find these things, and you can only find these things in the async API documentation. When you want to tell people about a particular model or schema that an event looks like, you write it in the documentation. Then, you can generate the code of the whole library. For example, if you want to consume an event, you can prepopulate the classes and functions, and developers can easily work on it. These features are available in async API but not in AWS. AWS provides the rest API, which requires a lot of customization. So I would say that's missing in the AWS cloud.