In this article, we take a look at the value proposition offered by AWS Event Bridge and Azure Event Grid. The two services are similar, because of this the main focus is to identify what they have in common and what are the differences between them.
Purpose of these services
Enable us to build solutions based on event-driven architecture by connecting the event producer to the consumer(s). The way how is done is similar to the concept of ESB (Enterprise Service Bus) where the producer is not aware of the no. of consumers. There are just one or multiple streams of events delivered to them that can be filtered and sent to the consumers that are registered for that specific data stream.
In a world driven by data where serverless and microservices are becoming a standard, systems that play the role of a serverless event bus between our applications and components are mandatory to enable us to scale and in the same time to keep the cost low.
Terminology
The terminology for each service is different, because of this it is hard to switch between services. You can find below a mapping that might be useful when you want to have an overview of both services. It is not a perfect one-to-one mapping, because the mechanism for each service is a little different.
AWS Event Bridge
|
Azure Event Grid
|
Definition
|
Partner event source
|
-
|
A partner event source is used by an AWS partner to send events to an AWS customer account.
|
Event
|
Event
|
The thing that happened or took place
|
Source
|
Event Source
|
Where the event took place
|
Event bus
|
Topics
|
The endpoint where events are sent
|
Event bus
|
Event Subscription
|
The build-in mechanism used to root the event to the destination(s)
|
Target
|
Event Handler
|
The system that is processing the events - consumer
|
Rule
|
Event Filters
|
A rule/filter that matches the incoming events and redirects them to specific consumers.
|
Data Source
For both services, the list of data sources that are supported is represented by the core services from each provider. Data sources like event, messages and internal notifications and alerts are supported. AWS has the concept of partners that can create custom event sources. A good example is DataDog that can push alerts or events directly to AWS Event Bridge.
Additional to this, each service is allowing us to fetch events from services that are not directly supported using cloud services like AWS Cloud Trail.
Below you can find a list of data sources for each service.
AWS Event Bridge
|
Azure Event Grid
|
|
|
Consumers
The no. of consumers for each service is irrelevant because it is a representation of specific services from each cloud provider. It is important to notice that in both cases there is strong support for serverless services (AWS Lambda and Azure Functions) and the capability to connect directly or indirectly to a custom API (e.g. WebHook).
Below you can find a list of consumers(Target/Event Handler) for each service.
AWS Event Bridge
|
Azure Event Grid
|
|
|
Temporary consumers
Azure Event Grid is offering us the capability to temporary event subscriptions that expire after a specific time interval. This feature is useful during the operation phase or when we want to do specific testing or debugging, by creating event subscriptions that expire after a specific time interval.
At this moment in time, this feature is not available inside AWS Event Bridge but can be implemented using an AWS Lambda with TTL value as input.
Batch support
Both services are allowing us to push events as a batch of events, and not one by one. This feature has a positive impact on the performance level, especially when we are working with a high number of events.
Delivery Retry
Even if both solutions do not have a mechanism to protect for data duplication and multiple deliveries of the same message, each of them has protection mechanisms. Azure Event Grid has a mechanism that waits for delivery confirmation for a specific time interval. If the confirmation is not received, the event becomes available for consumption again. The retry mechanism is an exponential backoff algorithm that starts with 10s interval and goes up to 1d or 30 retries. A similar mechanism is implemented by AWS Event Bridge, with a retry mechanism that goes up to 1d using an exponential backoff algorithm.
AWS Eventbridge deletes automatically all the events that cannot be delivered in 1d, without the ability to trace them. In general, this is not an issue, mainly because 1d it is a long period and in an event-driven architecture, losing some of the messages is not so critical. Azure Event Grid has the concept of death-letter that can be configured to push all the events that cannot be consumed inside the storage for later analyses.
Disaster Recovery
Both services are available inside one region, no data replication is supported cross regions. For AWS Eventbridge the content it is replicated in multiple availabilities zones in the same region. Inside a region none of the services provides data replication across availability zones from the same region.
For Azure EventGrid the SLAs for RPO and RTO are well documented and it is using a geo disaster recovery strategy, when a new instance of Azure Event Grid is created in another region once the main one goes down.
- RPO for metadata: 0 minutes
- RTO for metadata: 60 minutes
- RPO for Data: 5 minutes
- RTO for Data: 60 minutes
For AWS Eventbridge, I was not able to identify if there is a disaster recovery strategy offered out of the box and what is the RPO and TRO.
Throughput and limits
It is hard to make a comparison between the two services and to make a comparison of the maximum limits of each service it is a little bit artificial. Both of them can manage a high no. of events from multiple data sources and in most of cases you have the mechanism that would enable you to overcome a limitation.
For example, you can create multiple instances of the same service and you can connect two AWS Eventbridge directly allowing you to increase the complexity of the rules.
Security
AWS Eventbridge security mechanism is built around IAM and Resource-based policies. There is granular access control that you can provide at Rule and Event Bus allowing you to define any access and management policies.
Azure Event Grid is based on WebHook, event subscription and custom topic publishing access control based on validation codes and tokens. There is full support of SAS (Shared Access Signature) that provides limited access to a specific resource. Like any other Azure Service, full support for RBAC exists, with similar concept provided by IAM and resource-based policies.
Pricing model
The pricing model for both services is around the no. of operations. Azure Event Grid is charging you for each operation/call to the service. Each publish, delivery or event delivery attempt is counted separately. If you are doing advanced match, it is counted separately as different operations. The first 100.000 operations are free, and the rest of them are charged with €0.60 per 1M operations.
AWS Eventbridge has a different strategy. We are charged only for the publish operations to the service. There are no extra charges for event delivery or rules. The price for 1M operations (publish events) is $1.00. It is interesting to find out that events that are published by AWS Services are free.
Even if the pricing model is different between the two services, the final price that you pay is similar. It looks like that AWS has a better offer in comparison with Azure, but at the same time the features list of Azure Event Grid it is a little bit more reach.
Conclusion
Take into account that both of them are similar, with the same core functionality. The list of functionalities is pretty similar, and both of them are well connected to external services. There is only a small difference between both of them that are relevant only for specific cases. Depending on what cloud provider you are using, you will end up using the specific service that it is included.
In the below table I tried to catch different perspectives of both services.
Perspective
|
AWS Eventbridge
|
Azure Event Grid
|
Internal data sources support
|
YES
|
YES
|
External data source support
|
YES
|
YES
|
Support for external partners
|
YES
|
NO*
|
Internal data consumer support
|
YES
|
YES
|
Serverless integration
|
YES
|
YES
|
REST API & WebHooks
|
YES
|
YES
|
Temporary data source consumers
|
NO**
|
YES
|
Batch support
|
YES
|
YES
|
Delivery retry
|
YES
|
YES
|
Death letter support
|
NO
|
YES
|
Cross-region replication
|
NO
|
NO
|
Cross availability zone replication
|
YES
|
NO
|
Automatic DR strategy
|
NO***
|
YES
|
RPO
|
NO
|
0 minutes for metadata
5 minutes for data
|
RTO
|
NO
|
60 minutes for metadata
60 minutes for data
|
IAM/RBAC integration
|
YES
|
YES
|
Pricing model
|
Per event
|
Per no. of operations
|
Filtering support
|
YES
|
YES
|
Fully managed
|
YES
|
YES
|
Scheduled events
|
YES
|
NO**
|
* Nothing stops partners to publish their events, but in comparison with AWS, Azure Event Grid does not have the marketplace concept
** Can be implemented using custom mechanisms
*** I was not able to identify in the AWS documentation. Inside Azure, the DR strategy is well documented.
Comments
Post a Comment