Skip to main content

The value proposition of AWS Eventbridge and Azure Event Grid

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 
  1. External Partners 
  1. Amazon EC2 instances 
  1. AWS Lambda functions 
  1. Streams in Amazon Kinesis Data Streams 
  1. Delivery streams in Amazon Kinesis Data Firehose 
  1. Log groups in Amazon CloudWatch Logs 
  1. Amazon ECS tasks 
  1. Systems Manager Run Command 
  1. Systems Manager Automation 
  1. AWS Batch jobs 
  1. Step Functions state machines 
  1. Pipelines in CodePipeline 
  1. CodeBuild projects 
  1. Amazon Inspector assessment templates 
  1. Amazon SNS topics 
  1. Amazon SQS queues 
  1. Built-in targets: EC2 CreateSnapshot API call, EC2 RebootInstances API call, EC2 StopInstances API call, and EC2 TerminateInstances API call. 
  1. The default event bus of another AWS account 
  1.  
  1. Azure Subscriptions 
  1. Container Registry 
  1. Custom Topics 
  1. Event Hubs 
  1. IoT Hub 
  1. Media Services 
  1. Resource Groups 
  1. Service Bus 
  1. Storage Blob 
  1. Azure Maps 
  
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 
  1. Lambda functions 
  1. Amazon EC2 instances 
  1. Streams in Amazon Kinesis Data Streams 
  1. Delivery streams in Amazon Kinesis Data Firehose 
  1. Log groups in Amazon CloudWatch Logs 
  1. Amazon ECS tasks 
  1. Systems Manager Run Command 
  1. Systems Manager Automation 
  1. AWS Batch jobs 
  1. AWS Step Functions state machines 
  1. Pipelines in AWS CodePipeline 
  1. AWS CodeBuild projects 
  1. Amazon Inspector assessment templates 
  1. Amazon SNS topics 
  1. Amazon SQS queues 
  1. Built-in targets: EC2 CreateSnapshot API call, EC2 RebootInstances API call, EC2 StopInstances API call, and EC2 TerminateInstances API call 
  1. The default event bus of another AWS account 
  1. Azure Automation 
  1. Azure Functions 
  1. Event Hubs 
  1. Hybrid Connections 
  1. Logic Apps 
  1. Microsoft Flow 
  1. Queue Storage 
  1. Service Bus 
  1. WebHooks 
  
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

Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.
publ…