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 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 Azure resource 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. Events usually describe state changes or facts, while commands and durable business work often fit Service Bus better. Event Grid can 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. Pull delivery is available through Event Grid namespaces and lets subscribers read events when they are ready.

Basic-tier custom, system, partner and domain topics use push delivery. Teams should choose the model based on endpoint availability, consumer control, latency and back-pressure requirements.

What are Event Grid Basic and Standard tiers?

Microsoft 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.

The tiers are 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.

What are the current namespace and event limits?

Microsoft currently documents a default maximum of 40 throughput units per Event Grid namespace and 50 Event Grid namespaces per Azure subscription. Standard namespace topics are limited to 100 topics per throughput unit, 500 subscriptions per topic and a maximum event size of 1 MB. Event ingress is limited to 1,000 events per second or 1 MB per second per throughput unit, whichever is reached first. Event egress through push or pull APIs is up to 2,000 events per second or 2 MB per second per throughput unit.

Basic custom and partner topics have a different profile. Microsoft currently limits publish ingress to 5,000 events or 5 MB per second per topic, whichever comes first. Custom topics are limited to 100 per Azure subscription, while Event Grid domains can support up to 100,000 topics. Event subscriptions are generally limited to 500 per topic.

How do retries and failed deliveries work?

For Basic push delivery, Event Grid retries transient failures. Microsoft's current guidance says the default event time-to-live is 1,440 minutes, or 24 hours, and the default maximum delivery attempts is 30. TTL can be set from 1 to 1,440 minutes and maximum attempts from 1 to 30. Event Grid uses an exponential backoff schedule and adds some randomization, so delivery timing should not be treated as an exact retry clock.

Optional failed-delivery storage can send undeliverable events to an Azure Blob Storage container. Production designs should define who monitors failed events, how they are replayed and when an event is no longer useful. Applications should still be idempotent because duplicate delivery can occur.

What role does MQTT play in Event Grid?

Event Grid Standard namespaces include an MQTT broker for IoT and device messaging. Microsoft supports MQTT 3.1.1 and MQTT 5.0, including WebSocket variants. The current service limits allow 10,000 MQTT sessions per throughput unit and 10,000 registered client resources per throughput unit.

The maximum MQTT message size is 512 KB. Retained MQTT messages are more constrained: the maximum retained-message size is 64 KB, with up to 10,000 retained messages or 640 MB of retained storage per throughput unit, whichever limit is reached first. MQTT 3.1.1 retained messages have a default retention of 365 days, while MQTT 5.0 can use the message expiry interval up to 365 days.

How much event retention is available?

Standard namespace topics retain events for up to seven days. Basic custom, system and partner topics retain events for up to one day. Event retention is useful for temporary delivery resilience, but Event Grid is not a long-term replay platform.

If an architecture requires long retention windows, partitioned replay, consumer offsets or repeated historical processing, Azure Event Hubs or another streaming platform is usually a better fit.

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. Standard 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 billable operations. Pricing was checked on September 4, 2026. Buyers should estimate event size, delivery attempts, filtering, throughput units 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 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. 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 resources have different retention and throughput limits from Standard namespaces, and Standard introduces throughput-unit planning.

The 1 MB maximum event size also means Event Grid should usually carry event metadata or references rather than large payloads. MQTT adds a separate set of session, retained-message and topic limits. Workloads needing long replay windows, stronger queue semantics, large payload transfer or deep broker control may fit another Azure 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.