Azure Event Grid

About Azure Event Grid

Azure Event Grid is Microsoft Azure's fully managed publish-subscribe service for distributing events between Azure services, custom applications, partner systems and IoT clients. It supports HTTP-based push and pull delivery for discrete events and MQTT messaging through Event Grid namespaces. Event Grid is strongest when applications need near-real-time event routing, filtering and fan-out without operating their own broker infrastructure. Buyers should distinguish it from Azure Service Bus, which focuses on durable enterprise messaging, and Azure Event Hubs, which focuses on high-throughput event streams and replay.

What is Azure Event Grid used for?

Azure Event Grid is designed for event-driven systems where one service announces that something happened and one or more subscribers react. Common examples include triggering processing when a blob is created, responding to resource state changes, routing custom application events to functions or webhooks, connecting partner SaaS events to Azure handlers, and distributing IoT messages through MQTT-enabled namespaces.

Microsoft describes Event Grid as a publish-subscribe service rather than a work queue. That distinction matters. Events usually describe state changes or facts, while commands and durable business work often fit Service Bus better. Event Grid can still provide reliable delivery controls, but buyers should select it because the event-notification or event-distribution model matches the application architecture.

How do push delivery and pull delivery differ?

Event Grid supports both push and pull delivery for HTTP event messaging. With push delivery, an event subscription points to a destination and Event Grid sends matching events to that handler. Supported destinations include Azure services and custom webhooks. This model is useful when subscribers should react immediately and expose a reachable endpoint.

With pull delivery, subscriber applications connect to Event Grid namespace topics and read events when they are ready. Microsoft positions pull delivery for scenarios where consumers want more control over receive timing and processing. Pull delivery is available through Event Grid namespaces, while Basic-tier custom, system, partner and domain topics use push delivery. Teams should choose the model based on endpoint availability, consumer control and operational requirements.

What are Event Grid Basic and Standard tiers?

Microsoft currently separates Event Grid into Basic and Standard tiers. Basic supports discrete event publishing and push delivery through custom topics, system topics, partner topics and domains. Standard uses the Event Grid namespace resource and adds MQTT broker capability plus pull and push delivery for discrete events.

This makes the tiers architecturally different rather than simple performance levels. Standard namespaces are the route for MQTT and pull-delivery workloads and use throughput units for capacity. Basic remains suitable for many Azure resource events, custom application events and partner-event routing where push delivery is enough. Buyers should confirm which resource model their application needs before estimating cost or limits.

How do namespaces, topics and throughput units work?

An Event Grid namespace is a logical container for topics and related MQTT or event-distribution resources. Microsoft currently documents up to 40 throughput units per namespace by default, with higher limits requiring a support request. Each throughput unit contributes ingress and egress capacity, and Standard-tier namespaces can be scaled manually or, as of July 2026, can use autoscale in preview.

Current namespace limits include up to 100 namespace topics per throughput unit, event ingress of up to 1,000 events per second or 1 MB per second per throughput unit, and event egress of up to 2,000 events per second or 2 MB per second per throughput unit. These limits make capacity planning important for high-volume systems. Teams should estimate event size and event rate together rather than looking only at event count.

How do retries and dead-lettering work?

For push delivery, Event Grid includes retry handling for transient failures. Microsoft's current guidance says the default retry window is 24 hours with up to 30 delivery attempts, and event subscriptions can configure the time-to-live from 1 to 1,440 minutes and maximum retries from 1 to 30. The retry schedule itself is not configurable.

Dead-lettering can send events that cannot be delivered to an Azure Blob Storage container. This is useful for troubleshooting and recovery, but it adds another resource and operational path that teams need to monitor. A production design should define who watches dead-letter storage, how failed events are replayed, and when an event is no longer useful instead of assuming the platform will resolve every delivery failure automatically.

What role does MQTT play in Event Grid?

Event Grid Standard namespaces include MQTT broker capabilities for IoT and device messaging. Microsoft currently supports MQTT 3.1.1 and MQTT 5.0, including WebSocket variants, with additional support for HTTP publishing of MQTT messages. Microsoft also documents MQTT retain support and shared subscriptions as generally available by April 2026.

MQTT does not make Event Grid a drop-in replacement for every IoT broker or edge platform. Organizations should verify session counts, retained-message behavior, topic structure, authentication and regional support. Event Grid can integrate with Azure IoT Operations, but edge, offline and device-management requirements may call for additional services beyond the cloud broker itself.

How does Azure Event Grid pricing work?

Event Grid does not have one fixed monthly price. Microsoft's current pricing page says the Basic tier is pay-per-use based on operations such as published events, advanced filtering and delivery attempts. The Standard tier combines pre-purchased throughput units for namespace capacity with operation charges for MQTT and discrete event operations.

Microsoft currently includes 100,000 free Basic operations per month and 1,000,000 free MQTT operations plus 1,000,000 free event operations per month in Standard. Billing is measured in 64 KB operation units, so larger events count as multiple operations. Pricing was checked on August 25, 2026. Buyers should estimate event size, delivery attempts, filtering, namespace capacity and MQTT traffic instead of using only published-event count.

How does Event Grid compare with Service Bus and Event Hubs?

Azure Event Grid is strongest for event notification, routing and fan-out. Azure Service Bus is better for durable business messages, commands, transactions, sessions, dead-letter queues and ordered work processing. Azure Event Hubs is designed for large continuous streams such as telemetry, logs and clickstreams where consumers read partitions and replay retained events.

The services can be combined. For example, Event Grid can route a storage event to a function, Service Bus can carry the business command created by that function, and Event Hubs can receive operational telemetry from the same application. Buyers should start with the communication pattern rather than forcing all messaging requirements into one Azure service.

What are the main limitations and tradeoffs?

Event Grid is not a general workflow engine and it does not process events by itself. Applications still need handlers, error-management logic, observability, authentication and idempotent behavior where duplicate delivery is possible. Basic-tier topics have different retention and resource limits from Standard namespaces, and the Standard namespace model introduces throughput-unit planning.

Current Microsoft limits also matter. Namespace topics retain events for up to seven days, while Basic custom, system and partner topics retain events for one day. Maximum event size is 1 MB. MQTT has its own session, message-size and throughput limits. These constraints are reasonable for event distribution, but workloads needing long replay windows, richer queue semantics or very large continuous streams may fit another Azure messaging service better.

Who should choose something else?

Teams that need reliable business commands, transactional queues, sessions or richer brokered messaging should compare Azure Service Bus. Workloads centered on high-volume telemetry, ordered partitions and longer stream replay should compare Azure Event Hubs. Organizations needing workflow orchestration rather than event distribution should use an appropriate workflow or integration service instead of turning Event Grid into a state machine.

Azure Event Grid is strongest when the application needs scalable publish-subscribe event routing, Azure-native system events, custom or partner events, flexible push or pull consumption and, where needed, MQTT in the cloud. Buyers should choose it because the event-distribution model fits the workload and because its delivery and capacity limits align with the application's reliability and scale requirements.