What Is Azure Event Grid?

Azure Event Grid is a fully managed event-routing service that enables you to build reactive, event-driven applications. Instead of constantly polling for changes, your applications receive notifications the instant something happens — a file is uploaded, a resource is created, or a configuration changes.

Event-Driven Architecture Basics

Traditional applications often use polling — repeatedly checking "has anything changed?" This wastes compute resources and introduces latency. Event-driven architecture flips this model: producers push notifications when something happens, and consumers react immediately.

Think of it like a doorbell vs. repeatedly opening your door to check if someone is there. Event Grid is the doorbell system for your Azure infrastructure.

Key principles of event-driven architecture:

The Publish/Subscribe Model

Event Grid uses a pub/sub (publish/subscribe) pattern:

1. Publishers (event sources) emit events when something happens — they don't know who is listening
2. Event Grid receives the event and routes it based on subscriptions
3. Subscribers (event handlers) receive only the events they've registered interest in

This decoupling means you can add new subscribers without modifying the publisher. A blob upload can simultaneously trigger a thumbnail generator, an audit logger, and a search indexer — none of which know about each other.

How Event Grid Fits in the Azure Ecosystem

Azure has three main messaging services. Here's when to use each:

Use Event Grid when:

• You need to react to state changes (blob created, VM deleted, key rotated)
• You want fan-out — one event triggers multiple handlers
• You need sub-second latency between event and reaction
• Events are lightweight notifications, not large data payloads

Use Service Bus when:

• You need guaranteed ordering (FIFO)
• Messages represent commands or transactions
• You need request/reply patterns
• Payload size exceeds 1 MB

Use Event Hubs when:

• You're ingesting millions of events per second (telemetry, IoT)
• You need to replay historical events
• You're feeding data into analytics pipelines (Stream Analytics, Spark)

How Events Flow from Source to Handler

┌──────────────┐     ┌──────────────┐     ┌──────────────────┐
│ Event Source │────▶│  Event Grid  │────▶│  Event Handler   │
│ (Blob Store) │     │  (routing)   │     │  (Azure Function)│
└──────────────┘     └──────────────┘     └──────────────────┘
                            │
                            ├────────────▶ Logic App
                            │
                            └────────────▶ Webhook

1. An event source (e.g., Azure Blob Storage) publishes an event to a topic
2. Event Grid evaluates all subscriptions on that topic
3. Each subscription has filters — only matching events are forwarded
4. The event is pushed via HTTP POST to each matching handler
5. If delivery fails, Event Grid retries with exponential backoff

Pricing Model

Event Grid pricing is simple and consumption-based:

An "operation" includes: event ingress, delivery attempts, management calls, and advanced match evaluations. For most small-to-medium workloads, Event Grid costs are negligible.

Real-World Scenarios

Image Processing Pipeline

User uploads image to Blob Storage
    → Event Grid detects BlobCreated event
        → Azure Function generates thumbnail
        → Another Function runs image classification
        → Logic App notifies user via email

Audit Logging

Any resource change in a Resource Group
    → Event Grid captures ResourceWriteSuccess events
        → Function writes structured log to Cosmos DB
        → Alerts on specific resource deletions

Key Vault Secret Rotation

Secret nears expiration in Key Vault
    → Event Grid emits SecretNearExpiry event
        → Function rotates the secret automatically
        → Logic App notifies the security team

Quick CLI Example

# Register the Event Grid resource provider (one-time setup)
az provider register --namespace Microsoft.EventGrid

# Check registration status
az provider show --namespace Microsoft.EventGrid --query "registrationState"

# List all Event Grid topics in your subscription
az eventgrid topic list --output table

# View available event types for a resource provider
az eventgrid topic-type list --output table

Common Mistakes

• Confusing Event Grid with Event Hubs — Event Grid is for discrete state-change notifications; Event Hubs is for high-throughput data streaming
• Expecting large payloads — Event Grid events have a 1 MB size limit (64 KB for the free tier). Send a reference/URL to the data, not the data itself
• Forgetting endpoint validation — When using webhooks, Event Grid sends a validation request first. Your endpoint must echo back the validation code
• Not registering the provider — You must run az provider register --namespace Microsoft.EventGrid before using the service

Key Takeaways

• Event Grid is a fully managed, serverless event-routing service for reactive applications
• It uses a push-based pub/sub model with sub-second delivery latency
• Choose Event Grid for lightweight state-change notifications; Service Bus for commands; Event Hubs for streaming
• Pricing is consumption-based with a generous free tier (100K operations/month)
• Events flow: Source → Topic → Subscription (with filters) → Handler
• Real-world uses include image pipelines, audit logging, secret rotation, and infrastructure automation
• Event Grid handles retry logic and dead-lettering automatically