Event Grid subscriptions and filters in Azure - Deep Dive

Overview - Event Grid subscriptions and filters

What is it?

Event Grid subscriptions and filters are ways to control which events a service or application receives from Azure Event Grid. A subscription tells Event Grid where to send events, like a mailbox address. Filters let you choose only certain events to receive based on their properties, so you don't get overwhelmed with unwanted information. This helps systems react only to the events they care about.

Why it matters

Without subscriptions and filters, every service would get all events, causing confusion and wasted resources. Imagine getting every email from every person in the world instead of just your friends. Filters help reduce noise and improve efficiency, making cloud systems faster and cheaper to run. They also improve security by limiting event exposure.

Where it fits

Before learning this, you should understand basic Azure Event Grid concepts like events and topics. After this, you can learn about event handlers and how to process events in Azure Functions or Logic Apps. This topic fits in the middle of the event-driven architecture learning path.

Mental Model

Core Idea

Event Grid subscriptions define who gets events, and filters decide which events they actually receive.

Think of it like...

It's like subscribing to a magazine and choosing only the sections you want to read, so your mailbox isn't full of unwanted pages.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Event Grid  │──────▶│ Subscription  │──────▶│ Event Handler │
│    Topic      │       │   (Endpoint)  │       │   (Receiver)  │
└───────────────┘       └───────────────┘       └───────────────┘
         │                      │
         │                      ▼
         │               ┌───────────────┐
         │               │   Filters     │
         │               │(Event Select) │
         │               └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is an Event Grid Subscription

Concept: Introduces the idea of a subscription as a destination for events.

An Event Grid subscription is like telling Azure Event Grid where to send events. You provide an endpoint, such as a web URL or Azure service, and Event Grid delivers matching events there. Without a subscription, no events are sent anywhere.

Result

You understand that subscriptions are the basic way to receive events from Event Grid.

Knowing that subscriptions are the connection point between event sources and receivers is key to building event-driven systems.

2

Foundation

Basic Event Delivery Flow

Concept: Shows how events flow from source to subscriber.

Events are created by a source and sent to an Event Grid topic. The topic then forwards events to all subscriptions registered to it. Each subscription has an endpoint where events are delivered. This flow ensures events reach the right place.

Result

You can visualize the path an event takes from creation to delivery.

Understanding the event flow helps you design where to place subscriptions and handlers.

3

Intermediate

Why Use Filters in Subscriptions

🤔Before reading on: do you think subscriptions send all events or only some? Commit to your answer.

Concept: Filters let you pick which events a subscription receives based on event details.

Filters are rules you add to subscriptions to receive only events that match certain criteria. For example, you can filter by event type, subject prefix, or custom data fields. This reduces unnecessary event traffic and processing.

Result

You know how to limit event delivery to relevant events only.

Using filters prevents overload and improves system efficiency by focusing on important events.

4

Intermediate

Types of Filters Available

🤔Before reading on: do you think filters can only check event type or also other properties? Commit to your answer.

Concept: Explains the different filter options: subject filters, advanced filters, and system filters.

Subject filters match events based on their subject string, like a folder path. Advanced filters allow complex rules on event data, such as numeric ranges or string patterns. System filters use built-in event properties like event type or time. Combining these gives precise control.

Result

You can choose the right filter type for your scenario.

Knowing filter types helps tailor event delivery to exactly what your application needs.

5

Intermediate

How Filters Affect Event Routing

Concept: Filters act as gatekeepers deciding if an event passes to the subscriber.

When an event arrives at Event Grid, it checks each subscription's filters. If the event matches, it is sent to that subscription's endpoint. If not, it is ignored for that subscription. This selective routing saves bandwidth and processing.

Result

You understand that filters control event flow at the subscription level.

Recognizing filters as routers clarifies how Event Grid efficiently manages many events and subscribers.

6

Advanced

Combining Multiple Filters in Subscriptions

🤔Before reading on: do you think multiple filters combine with AND or OR logic? Commit to your answer.

Concept: Shows how multiple filters combine logically to refine event selection.

Multiple filters on a subscription combine with AND logic, meaning an event must satisfy all filters to be delivered. Within advanced filters, multiple conditions can combine with AND or OR. This lets you build complex rules to precisely target events.

Result

You can create sophisticated filtering rules to control event delivery.

Understanding filter logic prevents mistakes that cause missing or extra events.

7

Expert

Performance and Cost Implications of Filters

🤔Before reading on: do you think filters reduce cost and improve performance or add overhead? Commit to your answer.

Concept: Explains how filters impact system efficiency and billing.

Filters reduce the number of events sent to endpoints, lowering processing and network costs. However, complex filters add some processing overhead inside Event Grid. Balancing filter complexity and event volume is key to optimizing performance and cost.

Result

You can design filters that save money and keep systems responsive.

Knowing the tradeoff between filter complexity and cost helps build scalable event-driven architectures.

Under the Hood

Event Grid stores subscriptions and their filters in its control plane. When an event is published, Event Grid evaluates each subscription's filters against the event's properties. This evaluation happens in memory using efficient matching algorithms. If the event passes, it is queued for delivery to the subscription's endpoint using reliable HTTP or other protocols with retries.

Why designed this way?

This design separates event publishing from delivery, allowing many subscribers with different filters to coexist without slowing event producers. Filters reduce unnecessary network traffic and processing downstream. The push model with retries ensures reliable delivery even if endpoints are temporarily unavailable.

┌───────────────┐
│   Event Grid  │
│   Control     │
│   Plane       │
├───────────────┤
│ Subscriptions │
│ + Filters     │
└─────┬─────────┘
      │
      ▼
┌───────────────┐
│ Event Arrives  │
│  (Properties) │
└─────┬─────────┘
      │
      ▼
┌───────────────┐
│ Filter Check 1│───▶ Pass? ──▶ Deliver
│ Filter Check 2│───▶ Fail? ──▶ Skip
│    ...        │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do filters guarantee 100% event delivery of matching events? Commit yes or no.

Common Belief: Filters always guarantee that matching events are delivered without loss.

Reality: Filters only decide which events to send; delivery depends on endpoint availability and retries. Events can be lost if endpoints are down too long or misconfigured.

Why it matters: Assuming filters guarantee delivery can lead to missed events and data loss if endpoints are not monitored or retried properly.

Quick: Can you filter events based on any custom data field? Commit yes or no.

Common Belief: You can filter on any part of the event data, no matter how nested or complex.

Reality: Filters support only certain data types and paths; very complex or deeply nested data may not be filterable.

Why it matters: Expecting full data filtering can cause design errors and require extra processing downstream.

Quick: Do multiple filters on a subscription combine with OR logic? Commit yes or no.

Common Belief: Multiple filters on a subscription combine with OR, so any matching filter triggers delivery.

Reality: Multiple filters combine with AND logic; all must match for delivery.

Why it matters: Misunderstanding filter logic can cause events to be unintentionally dropped.

Quick: Does adding filters increase event delivery latency significantly? Commit yes or no.

Common Belief: Filters add noticeable delay to event delivery.

Reality: Filters are evaluated very quickly inside Event Grid and add minimal latency.

Why it matters: Overestimating filter delay may discourage their use, leading to inefficient event handling.

Expert Zone

1

Filters are evaluated before any retry logic, so filtering reduces retry traffic and costs.

2

Advanced filters support case-insensitive string matching and array contains operations, enabling flexible rules.

3

Dead-lettering works independently of filters; events filtered out are not dead-lettered.

When NOT to use

Avoid using very complex filters for extremely high event volumes; instead, consider pre-processing events with Azure Functions or Event Hubs for filtering. Also, if you need guaranteed event ordering, filters alone won't help; use partitioning or sequencing features.

Production Patterns

In production, teams use filters to route events to microservices based on event type or customer ID. Filters reduce load on downstream systems and improve scalability. Combining filters with dead-letter queues helps catch unexpected events.

Connections

Publish-Subscribe Messaging

Event Grid subscriptions and filters implement a publish-subscribe pattern with selective delivery.

Understanding pub-sub helps grasp why subscriptions and filters are essential for scalable event distribution.

Firewall Rules

Filters act like firewall rules that allow or block traffic based on criteria.

Knowing firewall filtering concepts clarifies how event filters control event flow and security.

Library Book Categorization

Filters are like library cataloging systems that direct readers to books by genre or topic.

This cross-domain link shows how organizing information efficiently is a universal challenge solved by filtering.

Common Pitfalls

#1 Expecting filters to deliver events that only partially match criteria.

Wrong approach:

Creating a subscription with multiple filters expecting OR logic:
{
"subjectBeginsWith": "orders/",
"subjectEndsWith": ".json"
}
// expecting events with either condition to be delivered

Correct approach:

Combine filters understanding AND logic or use advanced filters with OR conditions explicitly:
{
"advancedFilters": [
{"operatorType": "StringContains", "key": "subject", "values": ["orders/"]},
{"operatorType": "StringEndsWith", "key": "subject", "values": [".json"]}
],
"advancedFilterOperator": "Or"
}

Root cause:

Misunderstanding that multiple filters on a subscription combine with AND logic by default.

#2 Filtering on unsupported event data fields causing no events to be delivered.

Wrong approach:

Setting a filter on a deeply nested JSON field not supported by Event Grid:
{
"advancedFilters": [
{"key": "data.details.customer.id", "operatorType": "StringEquals", "values": ["123"]}
]
}

Correct approach:

Filter only on supported top-level or indexed fields, or preprocess events to flatten data before filtering.

Root cause:

Assuming Event Grid supports filtering on any JSON path without limitations.

#3 Not monitoring subscription endpoints leading to silent event loss.

Wrong approach:

Creating subscriptions with filters but no health checks or dead-letter setup.

Correct approach:

Configure dead-letter destinations and monitor endpoint health to catch delivery failures.

Root cause:

Believing filters alone guarantee event delivery without operational monitoring.

Key Takeaways

Event Grid subscriptions define where events are sent, and filters decide which events are delivered to each subscription.

Filters reduce noise and cost by sending only relevant events to subscribers, improving system efficiency.

Multiple filters on a subscription combine with AND logic, requiring all conditions to match for delivery.

Filters are evaluated quickly inside Event Grid, adding minimal latency but significant value in event routing.

Understanding filter capabilities and limits helps design reliable, scalable event-driven architectures.

Practice

1. What is the main purpose of using filters in Azure Event Grid subscriptions?

easy

A. To receive only specific events based on criteria like event type or subject

B. To increase the number of events sent to subscribers

C. To block all events from being delivered

D. To change the event data before delivery

Solution

1. Step 1: Understand Event Grid subscriptions

   Subscriptions let you receive events from Azure services.

2. Step 2: Role of filters in subscriptions

   Filters help select only the events you want, based on event type or subject.

3. Final Answer:

   To receive only specific events based on criteria like event type or subject -> Option A

4. Quick Check:

   Filters select events = B [OK]

Hint: Filters pick events you want, ignoring others [OK]

Common Mistakes:

• Thinking filters increase event volume
• Believing filters block all events
• Assuming filters modify event data

2. Which of the following is the correct JSON snippet to filter events by subject prefix in an Event Grid subscription?

easy

A. "filter": { "subjectBeginsWith": "/blobServices/default/containers/images" }

B. "filter": { "subjectEndsWith": "/blobServices/default/containers/images" }

C. "filter": { "eventType": "Microsoft.Storage.BlobCreated" }

D. "filter": { "subjectContains": "images" }

Solution

1. Step 1: Identify subject prefix filter syntax

   The correct property to filter by subject prefix is "subjectBeginsWith".

2. Step 2: Match the correct JSON snippet

   "filter": { "subjectBeginsWith": "/blobServices/default/containers/images" } uses "subjectBeginsWith" with the correct path prefix.

3. Final Answer:

   "filter": { "subjectBeginsWith": "/blobServices/default/containers/images" } -> Option A

4. Quick Check:

   Prefix filter uses subjectBeginsWith = A [OK]

Hint: Prefix filters use subjectBeginsWith property [OK]

Common Mistakes:

• Confusing subjectEndsWith with subjectBeginsWith
• Using eventType instead of subject filter
• Using subjectContains which is not valid

3. Given this Event Grid subscription filter configuration:

{ "subjectBeginsWith": "/devices/", "subjectEndsWith": "/temperature" }

Which event subject will be delivered to the subscriber?

medium

A. /sensors/device123/temperature

B. /devices/device123/humidity

C. /devices/device123/temperature

D. /devices/temperature/device123

Solution

1. Step 1: Understand filter conditions

   The event subject must start with "/devices/" and end with "/temperature".

2. Step 2: Check each option

   /devices/device123/temperature matches both start and end. Others fail one condition.

3. Final Answer:

   /devices/device123/temperature -> Option C

4. Quick Check:

   Subject starts with /devices/ and ends with /temperature = A [OK]

Hint: Match both start and end strings exactly [OK]

Common Mistakes:

• Ignoring subjectEndsWith condition
• Confusing similar paths
• Assuming partial matches are enough

4. You wrote this filter in your Event Grid subscription:

{ "subjectBeginsWith": "/orders/", "subjectEndsWith": "/completed" }

But no events are received even though events exist. What is the likely issue?

medium

A. The subscription is disabled

B. The filter syntax is invalid JSON

C. Event Grid does not support subject filters

D. The subject filter is case-sensitive and event subjects differ in case

Solution

1. Step 1: Check filter syntax and support

   The JSON syntax is valid and Event Grid supports subject filters.

2. Step 2: Consider case sensitivity and subscription status

   Subject filters are case-sensitive; if event subjects differ in case, no match occurs. Subscription being disabled would stop all events, but question implies filter issue.

3. Final Answer:

   The subject filter is case-sensitive and event subjects differ in case -> Option D

4. Quick Check:

   Subject filters are case-sensitive = D [OK]

Hint: Remember filters are case-sensitive in Event Grid [OK]

Common Mistakes:

• Assuming filters ignore case
• Blaming JSON syntax without checking
• Ignoring subscription status

5. You want to create an Event Grid subscription that only receives events of type Microsoft.Storage.BlobCreated where the blob is in the container named images. Which filter configuration achieves this?

hard

A. { "eventType": "Microsoft.Storage.BlobDeleted", "subjectBeginsWith": "/blobServices/default/containers/images/" }

B. { "eventType": "Microsoft.Storage.BlobCreated", "subjectBeginsWith": "/blobServices/default/containers/images/" }

C. { "eventType": "Microsoft.Storage.BlobCreated", "subjectEndsWith": "/images" }

D. { "eventType": "Microsoft.Storage.BlobCreated" }

Solution

1. Step 1: Filter by event type

   The event type must be exactly "Microsoft.Storage.BlobCreated" to get blob creation events.

2. Step 2: Filter by subject prefix for container

   The subject prefix for blobs in the "images" container is "/blobServices/default/containers/images/".

3. Step 3: Combine filters correctly

   { "eventType": "Microsoft.Storage.BlobCreated", "subjectBeginsWith": "/blobServices/default/containers/images/" } combines both eventType and subjectBeginsWith correctly.

4. Final Answer:

   { "eventType": "Microsoft.Storage.BlobCreated", "subjectBeginsWith": "/blobServices/default/containers/images/" } -> Option B

5. Quick Check:

   Event type and subject prefix filter combined = C [OK]

Hint: Combine eventType and subjectBeginsWith for precise filtering [OK]

Common Mistakes:

• Using wrong event type
• Using subjectEndsWith instead of subjectBeginsWith
• Omitting container path in subject filter