The Azure Event Grid namespace introduces a fresh take on this service for me. Historically, I’ve seen Azure Event Grid as a tool that sends events to my applications, a function that notably distinguishes it from Azure Service Bus. Now, we’re presented with a groundbreaking update: Namespaces in Azure Event Grid. What do these namespaces offer? Why might they prompt a move from Azure Service Bus? My article aims to shed light on these questions, providing insights into the new features and advantages of Azure Event Grid namespaces.
You may view all of the series’ articles here.
Azure Event Grid Namespaces structure
First, let’s take a closer look at how this new feature is structured, referring to the diagram:
When an application receives events or carries out tasks that control the event’s status, it specifies a namespace HTTP endpoint, a topic name, and the name of a queue event subscription.
Azure Event Grid Namespace – features
Event Grid namespace topics are designed to accept events that follow the Cloud Native Computing Foundation (CNCF)’s open standard, CloudEvents 1.0. This means you can utilize a widely recognized communication standard.
Azure Event Grid Namespace operates in two modes:
- Pull delivery
- Push delivery
Pull delivery
- Uses HTTP protocol.
- Handle events at a pace that suits you, scaling up or matching the rate your application can manage.
- Choose when to process events based on your needs. For instance, you might process messages overnight due to business requirements. You can release the message for some time, after which it will go back to processing.
- Access events through a private link, ensuring your data travels over private IP space for added security.
- You don’t need to consume events from Azure services or a partner (SASS) system.
- Topic filtering.
- Message processing confirmation.
- Dead lettering events handling.
- Event retention.
Push delivery
- Instead of continuously checking to see if a system’s state has changed, you prefer using Event Grid to automatically notify you when such changes occur.
- If your application is restricted from making outbound calls, perhaps due to concerns about data security, it can still receive events via a public endpoint.
Azure Event Grid Namespace – pricing
Now that we’ve covered the features of this service, let’s discuss pricing. Given the similarities between Azure Event Grid Namespace and Azure Service Bus, a comparison of their costs is worthwhile. If your services require handling messages larger than 1 MB, Azure Service Bus is the necessary choice.
For those interested in Azure Event Grid Namespace, the only available option at the moment is the Standard SKU. In contrast, for Azure Service Bus, the comparable option would be the Premium SKU.
| Azure Event Grid Namespace – Standard | Azure Service Bus – Premium |
| $34.60 ($5.40 for 10 million events) | $677.00 |
The pricing information provided is based on rates from West Europe as of March 22, 2024. For this comparison, I’ve considered the cost of processing 10 million events in Azure Event Grid Namespace.
This comparison highlights a significant price difference between the two services. Unless you have specific requirements that only Azure Service Bus can meet, Azure Event Grid Namespace emerges as the clear choice for cost-effective event handling.
Summary
In this guide, I explored the enhancements Azure Event Grid Namespace brings, and how it compares favourably with Azure Service Bus in terms of features and cost. I focused on its operational modes, security, and compatibility with CloudEvents standard. Through a cost comparison, I aimed to highlight the financial benefits of choosing Azure Event Grid Namespace. I hope my insights help you leverage Azure Event Grid more effectively in your projects, and I look forward to your feedback to further our journey in Azure together.
I truly hope you found it enjoyable, and if that’s the case, I would be grateful for a Like or a Comment on my LinkedIn profile.