AzureMessaging & Eventsintermediate

Service Bus vs Event Grid vs Event Hubs

Compare Azure Service Bus, Event Grid, and Event Hubs for messaging, event routing, and streaming in event-driven architectures.

CloudToolStack Team24 min readPublished Feb 22, 2026

Prerequisites

Basic understanding of messaging patterns (queues, topics, pub/sub)
Familiarity with Azure Functions
Experience with distributed systems

Event-Driven Architecture on Azure

Event-driven architecture (EDA) is a design paradigm in which the flow of a program is determined by events: state changes, user actions, sensor outputs, or messages from other systems. Azure provides three primary messaging and eventing services, each designed for different patterns and workloads: Azure Service Bus for enterprise messaging with transactional guarantees, Azure Event Grid for reactive event routing at massive scale, and Azure Event Hubs for high-throughput streaming data ingestion.

Choosing the right service, or combination of services, is one of the most consequential architectural decisions in an Azure-based system. The wrong choice can lead to overly complex solutions, unnecessary costs, missed ordering guarantees, or throughput bottlenecks that are difficult to resolve without significant rearchitecture. This guide provides a deep technical comparison of all three services, covering their architectures, capabilities, messaging patterns, error handling, and integration approaches.

In practice, many production architectures use multiple messaging services together. For example, Event Grid might route resource lifecycle events to a Service Bus queue for reliable processing, while Event Hubs captures telemetry streams for real-time analytics. Understanding the strengths and design trade-offs of each service enables you to build robust, scalable event-driven systems.

Event vs Message

Understanding the distinction between an event and a message is fundamental. An event is a lightweight notification that something happened; the publisher does not expect or require a specific action from the consumer. A message is a piece of data sent with the intent that the receiver will process it in a specific way, and there is an implicit contract between sender and receiver. Service Bus is designed for messages; Event Grid is designed for events; Event Hubs handles both events and streaming data.

Azure Service Bus Deep Dive

Azure Service Bus is a fully managed enterprise message broker that supports queues (point-to-point) and topics/subscriptions (publish-subscribe). It provides advanced features like message sessions, transactions, dead-letter queues, scheduled delivery, duplicate detection, and auto-forwarding, capabilities that distinguish it from simpler queue services like Azure Queue Storage.

Queues vs Topics

A Service Bus queue enables point-to-point communication: one sender sends a message, and one receiver consumes it. Messages are stored durably in the queue and delivered in FIFO order (with sessions enabled). A Service Bus topic works like a queue with multiple virtual subscriptions, and each subscription receives a copy of every message that matches its filter rules, enabling fan-out to multiple consumers.

Feature	Service Bus Queue	Service Bus Topic
Pattern	Point-to-point (1:1)	Publish-subscribe (1:N)
Consumers	Single competing consumer group	Multiple subscriptions, each with own consumer(s)
Filtering	No filtering (all messages delivered)	SQL-like or correlation filters per subscription
Max Size	1–100 GB (Premium: up to 100 GB)	1–100 GB (Premium: up to 100 GB)
Sessions	Supported (FIFO per session)	Supported per subscription

Terminal: Create a Service Bus namespace with queue and topic

# Create a Service Bus namespace (Premium tier for production)
az servicebus namespace create \
  --resource-group rg-messaging-prod \
  --name sb-orders-prod \
  --location eastus \
  --sku Premium \
  --capacity 1

# Create a queue with dead-letter and duplicate detection
az servicebus queue create \
  --resource-group rg-messaging-prod \
  --namespace-name sb-orders-prod \
  --name order-processing \
  --max-size 5120 \
  --default-message-time-to-live P14D \
  --lock-duration PT5M \
  --max-delivery-count 10 \
  --enable-dead-lettering-on-message-expiration true \
  --duplicate-detection-history-time-window PT10M \
  --enable-duplicate-detection true

# Create a topic with subscriptions
az servicebus topic create \
  --resource-group rg-messaging-prod \
  --namespace-name sb-orders-prod \
  --name order-events \
  --max-size 5120 \
  --default-message-time-to-live P7D

# Create subscriptions with filters
az servicebus topic subscription create \
  --resource-group rg-messaging-prod \
  --namespace-name sb-orders-prod \
  --topic-name order-events \
  --name high-value-orders \
  --max-delivery-count 10

az servicebus topic subscription rule create \
  --resource-group rg-messaging-prod \
  --namespace-name sb-orders-prod \
  --topic-name order-events \
  --subscription-name high-value-orders \
  --name high-value-filter \
  --filter-sql-expression "orderTotal > 1000 AND region = 'US'"

Service Bus SDK Example

OrderProcessor.cs: Sending and receiving Service Bus messages

using Azure.Messaging.ServiceBus;

// --- Sending Messages ---
await using var client = new ServiceBusClient(connectionString);
var sender = client.CreateSender("order-processing");

// Send a single message with custom properties
var message = new ServiceBusMessage(BinaryData.FromObjectAsJson(new
{
    OrderId = "ORD-2024-001",
    CustomerId = "CUST-500",
    Total = 1599.99,
    Region = "US"
}))
{
    MessageId = "ORD-2024-001",       // For duplicate detection
    SessionId = "CUST-500",           // For session-based FIFO
    ContentType = "application/json",
    Subject = "OrderCreated",
    TimeToLive = TimeSpan.FromDays(14)
};

message.ApplicationProperties["orderTotal"] = 1599.99;
message.ApplicationProperties["region"] = "US";

await sender.SendMessageAsync(message);

// --- Receiving Messages ---
var processor = client.CreateProcessor("order-processing", new ServiceBusProcessorOptions
{
    MaxConcurrentCalls = 10,
    AutoCompleteMessages = false,
    PrefetchCount = 20
});

processor.ProcessMessageAsync += async args =>
{
    var order = args.Message.Body.ToObjectFromJson<OrderCreatedEvent>();
    Console.WriteLine($"Processing order {order.OrderId}");

    try
    {
        await ProcessOrderAsync(order);
        await args.CompleteMessageAsync(args.Message);
    }
    catch (TransientException)
    {
        // Message will be retried after lock timeout
        await args.AbandonMessageAsync(args.Message);
    }
    catch (PoisonMessageException)
    {
        // Send to dead-letter queue with reason
        await args.DeadLetterMessageAsync(args.Message,
            deadLetterReason: "ProcessingFailed",
            deadLetterErrorDescription: "Order validation failed permanently");
    }
};

processor.ProcessErrorAsync += args =>
{
    Console.WriteLine($"Error: {args.Exception.Message}");
    return Task.CompletedTask;
};

await processor.StartProcessingAsync();

Azure Event Grid Deep Dive

Azure Event Grid is a fully managed event routing service that uses a publish-subscribe model. It is designed for reactive programming patterns where you want to respond to state changes in Azure resources, custom applications, or SaaS services. Event Grid delivers events at massive scale. It can handle millions of events per second with sub-second latency, and charges per operation, making it extremely cost-effective for event distribution.

Event Grid excels in scenarios where you need to react to events without polling. For example, when a blob is uploaded to Azure Storage, when a resource is created or deleted, when an IoT device sends telemetry, or when a custom application publishes a domain event. Event Grid routes these events to subscribers (Azure Functions, Logic Apps, webhooks, Service Bus queues, Event Hubs) based on filtering rules.

Event Grid Concepts

Concept	Description
Event Source	Where the event originates (Azure service, custom app, SaaS partner)
Topic	Endpoint where events are published (system topics or custom topics)
Event Subscription	A routing rule that directs events to a handler with optional filtering
Event Handler	The destination that receives events (Function, webhook, queue, hub)
Event Schema	Event Grid schema or CloudEvents v1.0 schema
Domain	Management container for grouping related topics (multi-tenant scenarios)

Terminal: Create Event Grid topic and subscription

# Create a custom Event Grid topic
az eventgrid topic create \
  --resource-group rg-messaging-prod \
  --name egt-orders-prod \
  --location eastus \
  --input-schema cloudeventschemav1_0

# Create an event subscription that routes to an Azure Function
az eventgrid event-subscription create \
  --name sub-process-orders \
  --source-resource-id /subscriptions/<sub-id>/resourceGroups/rg-messaging-prod/providers/Microsoft.EventGrid/topics/egt-orders-prod \
  --endpoint /subscriptions/<sub-id>/resourceGroups/rg-app/providers/Microsoft.Web/sites/func-order-handler/functions/ProcessOrder \
  --endpoint-type azurefunction \
  --event-delivery-schema cloudeventschemav1_0 \
  --subject-begins-with "/orders/" \
  --advanced-filter data.orderTotal NumberGreaterThan 100

# Create a system topic for blob storage events
az eventgrid system-topic create \
  --resource-group rg-messaging-prod \
  --name egst-storage-events \
  --location eastus \
  --topic-type Microsoft.Storage.StorageAccounts \
  --source /subscriptions/<sub-id>/resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/stmydata

# Subscribe to blob created events
az eventgrid system-topic event-subscription create \
  --resource-group rg-messaging-prod \
  --system-topic-name egst-storage-events \
  --name sub-blob-processing \
  --endpoint /subscriptions/<sub-id>/resourceGroups/rg-app/providers/Microsoft.Web/sites/func-blob-handler/functions/ProcessBlob \
  --endpoint-type azurefunction \
  --included-event-types Microsoft.Storage.BlobCreated \
  --subject-begins-with "/blobServices/default/containers/uploads/" \
  --subject-ends-with ".csv"

CloudEvents Schema

When creating new Event Grid topics, use the CloudEvents v1.0 schema instead of the proprietary Event Grid schema. CloudEvents is a CNCF specification for describing event data in a common way, and it provides better interoperability with non-Azure systems, other cloud providers, and open-source event processing frameworks. Azure Event Grid supports CloudEvents natively for both publishing and delivery.

Azure Event Hubs Deep Dive

Azure Event Hubs is a big-data streaming platform and event ingestion service capable of receiving and processing millions of events per second. Unlike Service Bus (which delivers messages to individual consumers) and Event Grid (which routes events to handlers), Event Hubs stores events in a partitioned, append-only log that multiple consumers can read independently at their own pace. This makes it ideal for telemetry ingestion, log aggregation, real-time analytics, and stream processing.

Event Hubs Architecture

Event Hubs uses a partitioned consumer model inspired by Apache Kafka. Events are written to partitions (the unit of parallelism) and retained for a configurable period (1–90 days, or unlimited with the Premium/Dedicated tier). Consumers read from partitions using consumer groups, where each consumer group maintains its own read position (offset) independently.

Feature	Basic	Standard	Premium	Dedicated
Throughput	1 TU (1 MB/s in, 2 MB/s out)	1–40 TUs (auto-inflate)	1–16 PUs	1+ CUs (self-managed)
Partitions	32	32	100	1024
Retention	1 day	1–7 days	Up to 90 days	Up to 90 days
Consumer Groups	1	20	100	1000
Capture	No	Yes (to Blob/ADLS)	Yes	Yes
Schema Registry	No	Yes	Yes	Yes
Kafka Protocol	No	Yes	Yes	Yes

Terminal: Create Event Hubs namespace and hub

# Create an Event Hubs namespace (Standard tier)
az eventhubs namespace create \
  --resource-group rg-messaging-prod \
  --name evhns-telemetry-prod \
  --location eastus \
  --sku Standard \
  --capacity 2 \
  --enable-auto-inflate true \
  --maximum-throughput-units 10

# Create an Event Hub with 8 partitions and 3-day retention
az eventhubs eventhub create \
  --resource-group rg-messaging-prod \
  --namespace-name evhns-telemetry-prod \
  --name device-telemetry \
  --partition-count 8 \
  --message-retention 3

# Create consumer groups for different processing pipelines
az eventhubs eventhub consumer-group create \
  --resource-group rg-messaging-prod \
  --namespace-name evhns-telemetry-prod \
  --eventhub-name device-telemetry \
  --name analytics-pipeline

az eventhubs eventhub consumer-group create \
  --resource-group rg-messaging-prod \
  --namespace-name evhns-telemetry-prod \
  --eventhub-name device-telemetry \
  --name alerting-pipeline

# Enable Event Hub Capture to blob storage
az eventhubs eventhub update \
  --resource-group rg-messaging-prod \
  --namespace-name evhns-telemetry-prod \
  --name device-telemetry \
  --enable-capture true \
  --capture-interval 300 \
  --capture-size-limit 314572800 \
  --destination-name EventHubArchive.AzureBlockBlob \
  --storage-account /subscriptions/<sub-id>/resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/sttelemetryarchive \
  --blob-container capture \
  --archive-name-format "{Namespace}/{EventHub}/{PartitionId}/{Year}/{Month}/{Day}/{Hour}/{Minute}/{Second}"

Service Bus vs Event Grid vs Event Hubs

The following comprehensive comparison table helps you choose the right service based on your specific requirements. In many architectures, you will use two or even all three services together, each handling the pattern it was designed for.

Characteristic	Service Bus	Event Grid	Event Hubs
Primary Pattern	Command/message processing	Event notification/routing	Stream ingestion/processing
Delivery	Pull (receiver fetches)	Push (delivered to handler)	Pull (consumer reads from partition)
Ordering	FIFO with sessions	No ordering guarantee	Per-partition ordering
Protocol	AMQP 1.0, HTTP	HTTP (webhooks, push)	AMQP 1.0, HTTP, Kafka
Max Message Size	256 KB (Standard), 100 MB (Premium)	1 MB (Event Grid), 1 MB (CloudEvents)	1 MB (Standard), 1 MB (Premium)
Throughput	Thousands/sec per queue	Millions/sec	Millions/sec per partition
Retention	Until consumed (up to 14 days TTL)	24-hour retry window	1–90 days (time-based)
Dead-Letter	Built-in DLQ per queue/subscription	Dead-letter to blob storage	No built-in (handle in consumer)
Transactions	Yes (cross-entity transactions)	No	No
Pricing Model	Per messaging unit (Premium) or operations	Per million operations	Per throughput/processing unit + ingress

When to Combine Services

A common pattern is to use Event Grid for reactive event routing (e.g., blob created, resource modified) and deliver those events to a Service Bus queue for reliable, ordered processing with dead-letter support. Similarly, Event Hubs handles high-volume ingestion while Service Bus manages the downstream command processing. The key principle is: let each service handle what it does best rather than forcing one service to cover all patterns.

Message Patterns & Integration

Beyond simple send-and-receive, Azure messaging services support several advanced patterns that are essential for building robust distributed systems.

Competing Consumers

Multiple consumer instances read from the same Service Bus queue, enabling horizontal scaling of message processing. Service Bus ensures each message is delivered to exactly one consumer through its peek-lock mechanism. This pattern is the foundation of most background processing architectures.

Claim Check Pattern

When message payloads exceed the size limits of the messaging service, use the claim check pattern: store the large payload in blob storage and send only a reference (the claim check) through the messaging service. The consumer retrieves the full payload from blob storage using the reference.

ClaimCheckSender.cs: Claim check pattern implementation

public class ClaimCheckSender
{
    private readonly BlobContainerClient _blobClient;
    private readonly ServiceBusSender _sender;

    public async Task SendLargePayloadAsync(byte[] payload, string messageId)
    {
        // 1. Store large payload in blob storage
        var blobName = $"messages/{messageId}/{Guid.NewGuid()}.bin";
        await _blobClient.UploadBlobAsync(blobName, new BinaryData(payload));

        // 2. Send claim check reference via Service Bus
        var claimCheck = new ServiceBusMessage(BinaryData.FromObjectAsJson(new
        {
            BlobContainer = _blobClient.Name,
            BlobName = blobName,
            PayloadSize = payload.Length,
            ContentType = "application/octet-stream"
        }))
        {
            MessageId = messageId,
            Subject = "LargePayload",
            ContentType = "application/json"
        };

        claimCheck.ApplicationProperties["pattern"] = "claim-check";
        await _sender.SendMessageAsync(claimCheck);
    }
}

Dead-Letter Queues & Error Handling

Dead-letter queues (DLQs) are a critical component of reliable messaging architectures. When a message cannot be processed successfully after the maximum number of delivery attempts, or when it expires before being consumed, it is moved to the dead-letter queue for manual inspection, reprocessing, or archival. Service Bus provides built-in DLQ support; Event Grid supports dead-lettering to blob storage; Event Hubs requires you to implement your own error handling in the consumer.

Service Bus Dead-Letter Processing

DlqProcessor.cs: Processing dead-lettered messages

public class DeadLetterProcessor
{
    private readonly ServiceBusClient _client;
    private readonly ILogger<DeadLetterProcessor> _logger;

    public async Task ProcessDeadLettersAsync(string queueName,
        CancellationToken cancellationToken)
    {
        // DLQ path is: <queue-name>/$deadletterqueue
        var receiver = _client.CreateReceiver(queueName,
            new ServiceBusReceiverOptions
            {
                SubQueue = SubQueue.DeadLetter
            });

        while (!cancellationToken.IsCancellationRequested)
        {
            var message = await receiver.ReceiveMessageAsync(
                TimeSpan.FromSeconds(30), cancellationToken);

            if (message == null) continue;

            _logger.LogWarning(
                "Dead-lettered message: Id={MessageId}, Reason={Reason}, Description={Description}",
                message.MessageId,
                message.DeadLetterReason,
                message.DeadLetterErrorDescription);

            // Analyze and decide: retry, archive, or alert
            if (IsRetryable(message))
            {
                // Re-enqueue to the main queue
                var sender = _client.CreateSender(queueName);
                var retryMessage = new ServiceBusMessage(message);
                retryMessage.ApplicationProperties["dlq-retry-count"] =
                    (int)(message.ApplicationProperties
                        .GetValueOrDefault("dlq-retry-count", 0)) + 1;

                await sender.SendMessageAsync(retryMessage);
                await receiver.CompleteMessageAsync(message);
            }
            else
            {
                // Archive to blob storage for investigation
                await ArchiveToBlob(message);
                await receiver.CompleteMessageAsync(message);
            }
        }
    }
}

Monitor Your Dead-Letter Queues

A growing dead-letter queue is a symptom of a systemic issue, either a bug in your processing logic, a downstream service failure, or a schema mismatch. Always set up alerts on dead-letter queue depth. For Service Bus, create a metric alert on theDeadletteredMessages metric. For Event Grid, monitor the dead-letter blob container. Unattended DLQs lead to data loss when messages expire or storage fills up.

Schema Registry & Validation

Azure Schema Registry (part of Event Hubs) provides a centralized repository for managing schemas used in event-driven applications. It supports Avro, JSON Schema, and custom schema formats. By centralizing schema management, you ensure that producers and consumers agree on the structure of events, prevent breaking changes, and enable schema evolution with backward/forward compatibility.

Terminal: Create and manage schemas

# Create a schema group in the Event Hubs namespace
az eventhubs namespace schema-registry create \
  --resource-group rg-messaging-prod \
  --namespace-name evhns-telemetry-prod \
  --name device-schemas \
  --schema-compatibility Forward \
  --schema-type Avro

# Register a schema (using REST API)
# POST https://<namespace>.servicebus.windows.net/$schemaGroups/<group>/schemas/<schema>
# Content-Type: application/json; serialization=Avro
# Body: Avro schema JSON

# Example Avro schema for device telemetry
cat <<'SCHEMA'
{
  "type": "record",
  "name": "DeviceTelemetry",
  "namespace": "com.company.iot",
  "fields": [
    { "name": "deviceId", "type": "string" },
    { "name": "timestamp", "type": "long" },
    { "name": "temperature", "type": "double" },
    { "name": "humidity", "type": "double" },
    { "name": "pressure", "type": ["null", "double"], "default": null },
    { "name": "location", "type": {
        "type": "record",
        "name": "GeoLocation",
        "fields": [
          { "name": "latitude", "type": "double" },
          { "name": "longitude", "type": "double" }
        ]
      }
    }
  ]
}
SCHEMA

Security & Networking

Securing your messaging infrastructure is critical because message brokers often carry sensitive business data and serve as the backbone of distributed systems. Azure provides multiple layers of security for all three messaging services.

Authentication & Authorization

All three services support Microsoft Entra ID (Azure AD) authentication with role-based access control, which is the recommended approach over connection strings. RBAC roles like Azure Service Bus Data Sender, Azure Service Bus Data Receiver, and Azure Event Hubs Data Owner provide fine-grained access control.

Terminal: Configure RBAC for messaging services

# Assign Service Bus Data Sender role to a managed identity
az role assignment create \
  --role "Azure Service Bus Data Sender" \
  --assignee-object-id <managed-identity-principal-id> \
  --assignee-principal-type ServicePrincipal \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-messaging-prod/providers/Microsoft.ServiceBus/namespaces/sb-orders-prod

# Assign Event Hubs Data Receiver role
az role assignment create \
  --role "Azure Event Hubs Data Receiver" \
  --assignee-object-id <managed-identity-principal-id> \
  --assignee-principal-type ServicePrincipal \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-messaging-prod/providers/Microsoft.EventHub/namespaces/evhns-telemetry-prod/eventhubs/device-telemetry

# Disable shared access key authentication (enforce AAD-only)
az servicebus namespace update \
  --resource-group rg-messaging-prod \
  --name sb-orders-prod \
  --disable-local-auth true

# Configure private endpoint for Service Bus
az network private-endpoint create \
  --resource-group rg-messaging-prod \
  --name pe-servicebus \
  --vnet-name vnet-app-prod \
  --subnet snet-private-endpoints \
  --private-connection-resource-id /subscriptions/<sub-id>/resourceGroups/rg-messaging-prod/providers/Microsoft.ServiceBus/namespaces/sb-orders-prod \
  --group-id namespace \
  --connection-name pec-servicebus

Best Practices & Architecture Patterns

Designing robust event-driven architectures requires careful consideration of failure modes, ordering requirements, idempotency, and operational concerns. The following best practices apply across all three Azure messaging services.

Design for idempotency: Messages may be delivered more than once (at-least-once delivery). Ensure your consumers can safely process the same message multiple times without side effects. Use message IDs, database upserts, or deduplication tables to track processed messages.
Use managed identities: Replace connection strings with managed identity authentication for all messaging services. This eliminates secret rotation concerns and provides audit-trail integration with Azure AD.
Monitor queue depth and processing latency: Set up alerts on message count, DLQ depth, and consumer lag. A growing backlog indicates your consumers cannot keep up and may need scaling.
Implement circuit breakers: When downstream services fail, use circuit breaker patterns to stop processing messages temporarily rather than repeatedly failing and dead-lettering valid messages.
Test failure scenarios: Regularly test what happens when a consumer crashes mid-processing, when a downstream dependency is unavailable, and when messages arrive out of order. These tests reveal gaps in your error handling.
Use the Premium/Dedicated tiers for production: Standard tier Service Bus and Event Hubs share resources with other tenants. Premium/Dedicated tiers provide dedicated capacity, predictable performance, and additional features like private networking and larger message sizes.
Version your event schemas: Include a version field in every event schema and use the Schema Registry for validation. This enables safe schema evolution without breaking existing consumers.

Choosing the Right Service

Ask three questions to select the right service: (1) Do you need guaranteed message delivery with dead-lettering and transactions? Use Service Bus. (2) Do you need to react to Azure resource events or route lightweight notifications? UseEvent Grid. (3) Do you need to ingest high-volume streaming data for analytics or processing? Use Event Hubs. If your architecture needs multiple patterns, use multiple services. They integrate seamlessly with each other.

Azure Functions Hosting Plans Multi-Cloud Messaging Comparison

Key Takeaways

1Service Bus is an enterprise message broker for ordered, transactional messaging with AMQP support.
2Event Grid provides serverless event routing with per-event pricing and sub-second latency.
3Event Hubs is a big data streaming platform for high-throughput event ingestion (millions/sec).
4Dead-letter queues in Service Bus handle poison messages and failed deliveries.
5Event Grid supports event filtering with advanced subject and field-level filters.
6Event Hubs integrates with Apache Kafka protocol for seamless Kafka migration.

Frequently Asked Questions

When should I use Service Bus vs Event Grid vs Event Hubs?

Service Bus: enterprise messaging with ordering, transactions, and dead-lettering. Event Grid: reactive event routing (resource events, custom events) with per-event pricing. Event Hubs: high-throughput streaming (telemetry, logs, clickstreams) with time-based retention.

Can Event Hubs replace Apache Kafka?

Event Hubs offers a Kafka-compatible endpoint, allowing existing Kafka producers and consumers to connect without code changes. It supports Kafka protocol 1.0+. However, some Kafka features (compacted topics, Kafka Streams) are not supported.

What is the maximum message size across services?

Service Bus Standard: 256 KB, Premium: 100 MB. Event Grid: 1 MB per event. Event Hubs Standard: 1 MB, Premium: 1 MB, Dedicated: 1 MB (batch up to 1 MB). For larger payloads, use claim-check pattern with Blob Storage.

How do sessions work in Service Bus?

Sessions provide ordered message processing and message affinity. All messages with the same SessionId are processed in order by the same consumer. This is useful for workflows where message order matters within a logical group (e.g., per-customer order processing).

What is the cost difference between the three services?

Event Grid is cheapest at $0.60 per million operations. Service Bus Standard starts at ~$10/month plus per-message charges. Event Hubs Standard starts at ~$11/month per throughput unit. Premium tiers of all three are significantly more expensive but offer guaranteed performance.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.