Messaging on Azure Blog articles

Azure Event Grid: Powering IoT and Event-Driven Applications at Scale

Connected-Seth — Wed, 03 Jun 2026 17:23:07 GMT

Modern IoT and event-driven applications demand more than reliable messaging. They require the ability to handle larger payloads, efficiently route data at scale, and automatically adapt to changing workloads. Today, we're excited to introduce a new set of capabilities in Azure Event Grid Namespace (MQTT Broker & Event Broker) that help organizations build more scalable, resilient, and cost-efficient connected solutions. With support for MQTT v5 Subscription Identifiers, larger messages(1MB), and Auto scale-up and scale-down, customers can simplify architecture, reduce operational overhead, and accelerate deployments across manufacturing, automotive, retail, energy, and other connected industries.

Event Grid Standard: MQTT v5 Subscription Identifier (GA)

What it solves

In many MQTT applications, one client subscribes to several topics at the same time. When a message arrives, the application needs a quick way to tell which subscription triggered it and what should happen next.

Which subscription triggered this message?
Which business rule should process it?

What’s new

MQTT v5 Subscription Identifier is now generally available in Event Grid MQTT broker. Each subscription can have an ID, and that ID is included when the message is delivered.

Each subscription can have an ID, and when a message is delivered, that ID comes with it.

Why it matters

Faster message routing
Cleaner application logic
No need to parse topic strings

Simple example

Example subscriptions:

Subscription ID 101 = factory/line1/temperature

Subscription ID 202 = factory/line1/vibration

When a message arrives

If the message comes in with Subscription ID 101, the app immediately knows it is temperature data and can send it to the correct processing path without inspecting the topic string.

Instant message context with MQTT v5 Subscription Identifiers

Common use cases

Manufacturing lines with hundreds of sensors
Automotive telemetry platforms
Multi‑tenant IoT solutions
Rule engines and stream processors

Event Grid Standard: 1MB Message Support (GA) - Coming Soon

Applies to both MQTT and non-MQTT workloads.

What it solves

As devices and applications become more capable, the events they send are becoming richer too.

In many real-world scenarios, a single message may need to include things like:

Sensor batches
Telemetry snapshots
Diagnostics data
Configuration payloads

Before this, customers often had to split large messages into smaller pieces or store the payload somewhere else and send only a reference.

What’s new

Event Grid Standard Namespace now supports larger event payloads upto 1MB for both MQTT and non-MQTT scenarios. That means customers can send more complete information in one message and reduce complex workarounds in design.

Why it matters

Fewer architectural components
Simpler producers and consumers
Lower latency for real‑time decisions

Example

Before: A factory device sent the main payload to storage and then published a small event that pointed to that file.

Now: The same device can publish the full event payload directly through Event Grid, making the flow easier to build and easier to operate.

Example: A smart machine can send a larger diagnostic package in one event, including the machine ID, a batch of readings, and a timestamp, instead of splitting the information across multiple services.

Unlock larger event-driven workloads with Azure Event Grid

Common use cases

Smart manufacturing telemetry
Vehicle diagnostics and firmware data
Batch sensor readings from edge devices
Rich business events for analytics

Event Grid Standard: Autoscale Up and Down (Preview) - Coming Soon

Applies to both MQTT and non-MQTT workloads.

What it solves

Event-driven systems rarely operate at a constant rate. Traffic patterns fluctuate throughout the day, with predictable peaks, seasonal surges, and unexpected bursts that can quickly overwhelm static infrastructure.

Think about:

Morning factory startup
Fleet check‑ins at the top of the hour
Flash sales or system bursts

Manually sizing infrastructure leads to:

Over‑provisioning (higher cost)
Under‑provisioning (missed events)

What’s new

Azure Event Grid Standard Namespace now supports Autoscale Up and Down, automatically adjusting capacity based on real-time workload demand. Whether you're running MQTT-based IoT workloads or event-driven applications using HTTP, AMQP, or CloudEvents, Event Grid dynamically scales resources to match traffic patterns without manual intervention.

As demand grows, Event Grid automatically adds capacity to absorb increased traffic and maintain performance. When activity subsides, resources scale back down to optimize efficiency and reduce costs.

Why it matters

With Autoscale, customers can focus on building applications instead of managing infrastructure and reap benefits like:

Scale seamlessly during traffic spikes without pre-provisioning for peak demand.
Reduce costs during quieter periods by automatically scaling capacity down.
Maintain consistent performance and reliability across changing workloads.
Eliminate manual tuning and capacity planning, reducing operational overhead.
Optimize resource utilization while supporting millions of devices and high-volume event streams.

Use case: A Modern Event-Driven Manufacturing Platform

A smart manufacturing company uses Microsoft to connect factory machines, sensors, edge gateways, and enterprise applications through a single scalable eventing platform. Devices publish rich telemetry and diagnostic payloads using MQTT, while cloud applications send operational and business events using HTTP. The company has steady traffic during the day, a large spike during shift changes, and much lower usage overnight. With autoscale, Event Grid adjusts capacity automatically, so performance stays strong when traffic is high and costs stay more efficient when traffic is low.

Autoscale intelligently to match changing workload demands

Common use cases

Shift‑based manufacturing systems
Connected vehicle platforms
Event‑driven commerce backends
Analytics pipelines with bursty data

Building IoT platforms, manufacturing and automotive solutions, or high-scale event-driven applications?

Azure Event Grid MQTT Broker now delivers larger messages, subscription Identifiers, and autoscale up/down, helping you simplify operations, improve performance, and optimize costs all on a single eventing platform.

Event Grid Basic: Powering Event Driven Payments with Stripe (GA)

Developers can seamlessly route Stripe events into Azure Event Grid to build scalable, event driven architectures without managing webhooks or custom brokers. Event Grid acts as a fully managed event broker between Stripe and Azure services.

Azure Event Grid now delivers Stripe events directly to Azure subscribers, including:

Azure Functions
Logic Apps
Event Hubs
Service Bus
And more

With Event Grid’s native integration with Microsoft Fabric, Stripe events can also be ingested as continuous streams, enabling real time transformation, enrichment, and analytics within Fabric. Learn more.

Build Smarter, Simpler IoT Messaging with Azure Event Grid MQTT Broker

Connected-Seth — Tue, 12 May 2026 21:39:49 GMT

Why this matters for modern IoT solutions

As IoT solutions grow, teams need messaging that is reliable, scalable, and simple enough to operate across devices, apps, and cloud services. Azure Event Grid MQTT broker helps organizations connect devices and applications using standard MQTT patterns while also integrating with Azure services for downstream processing and automation. The result is a managed, cloud-native approach to messaging that supports both technical flexibility and business agility.

With support for MQTT v3.1.1 and MQTT v5, Azure Event Grid MQTT broker enables device-to-device, device-to-cloud, and server-to-device communication patterns. It is especially useful in scenarios where customers want to ingest telemetry, send commands, broadcast alerts, and route data into analytics or workflow systems without building and maintaining broker infrastructure themselves.

In this post, we focus on four capabilities that make the experience even more powerful and easier to adopt: MQTT Retain support, Shared Subscriptions, HTTP Publish of MQTT messages, and Subscription Identifiers. These features help new subscribers get context immediately, allow multiple consumers to scale out work, let HTTP-native back-end services participate in MQTT workflows, and make message handling more efficient for clients.

Azure Event Grid MQTT Broker powering real-time event flow from devices and applications to analytics, automation, AI, and storage services.

Four features that make MQTT messaging easier to use

These capabilities are designed to solve everyday problems that customers face when building real-world IoT systems.

MQTT Retain support helps newly connected clients get the latest known value right away.
Shared Subscriptions help distribute message processing across multiple consumers for better scale and resilience.
HTTP Publish of MQTT messages enables back-end services to send MQTT messages without keeping long-lived MQTT sessions open.
Subscription Identifiers help clients understand which subscription matched a received message, making routing and processing simpler.

Together, these features reduce application complexity, improve responsiveness, and make it easier for teams to build user-friendly, production-ready IoT experiences.

MQTT Retain support: Give new subscribers the latest known value instantly

One of the most helpful MQTT patterns is the ability to retain the latest message on a topic. With MQTT Retain support in Azure Event Grid, the broker stores the last known good value for a topic and delivers it immediately to a new subscriber. That means a client does not have to wait for the next live publish to understand the current state.

This is especially valuable for scenarios such as device state, configuration settings, last reported sensor readings, and control values. When a new application, dashboard, or device comes online, it can immediately understand the current state of the system and take action faster.

Example

Imagine a smart factory dashboard subscribing to the topic factory/line1/status. If the latest retained message says Running, a newly opened dashboard can display that status immediately instead of waiting for the next update.

Retained messages ensure new subscribers instantly receive the latest device state without waiting for the next publish

Why customers like it

Faster onboarding for newly connected devices and apps
Better user experience in dashboards and operator tools
Less waiting for current state information
Simpler application logic for recovering context

Common use cases

Device online or offline state
Latest environmental reading such as temperature or humidity
Machine mode, recipe, or configuration profile
Current command state for field equipment

Shared Subscriptions: Scale message processing without extra complexity

As message volume grows, a single subscriber may not be enough to process all incoming data efficiently. Shared Subscriptions solve this by allowing multiple consumers to share the work for a subscription. Instead of every consumer receiving every message, the broker distributes messages across members of the shared group.

This is a powerful pattern for scaling out telemetry processing, command handling, or event enrichment pipelines. It also helps improve resilience because work can continue even if one consumer instance goes offline.

Example

Suppose you have a fleet of connected vehicles publishing telemetry to vehicles/+/telemetry. A back-end processing service might run three worker instances subscribed through a shared subscription. Rather than each worker processing all messages, the workload is divided across the three instances, which improves throughput and reduces duplicate effort.

Shared subscriptions distribute telemetry messages across multiple worker nodes for scalable, load-balanced, and resilient stream processing.

Why customers like it

Easier horizontal scaling for high-volume topics
Improved throughput for back-end processing
Better fault tolerance for worker-based applications
Cleaner architecture for stream processing pipelines

Common use cases

Telemetry ingestion at scale
Alarm processing pipelines
Order or command handling across multiple workers
Message transformation before routing to analytics platforms

Shared Subscriptions help teams grow from pilot projects to production-scale deployments without redesigning their application model. They make it easier to add processing capacity as business needs expand.

HTTP Publish of MQTT messages: Bring HTTP-native back-end systems into MQTT workflows

Not every application wants to maintain a persistent MQTT connection. Many back-end systems are built around stateless HTTP APIs and prefer simple request-based interactions. Azure Event Grid supports publishing MQTT messages over HTTP, which makes it easier for server-side applications to send messages into MQTT-based solutions.

This capability is a strong fit for server-to-device command and control, updates from enterprise systems, and retained message management. It also helps protect broker stability by reducing the need for a large number of long-lived sessions from services that do not truly need them.

Example

Imagine a support application that needs to send a message to a field device asking it to refresh its configuration. Instead of opening an MQTT session, the application can make an HTTP POST request that maps to an MQTT publish operation and sends the command to the desired topic.

Azure Event Grid MQTT Broker enables business applications to publish MQTT messages over HTTP and securely deliver them to connected MQTT devices with full MQTT publish capabilities.

Why customers like it

Simple integration for HTTP-native applications
No need for persistent broker sessions in back-end services
Consistent messaging flow across HTTP and MQTT publishers
Easier integration with business systems and automation workflows

Common use cases

Server-to-device commands
Application-driven updates and prompts
Retained message management
Integration with business processes, portals, and line-of-business apps

Subscription Identifiers: Make client-side message handling smarter

As applications grow, a single client may subscribe to many topic filters at the same time. Subscription Identifiers help the client understand which subscription matched a delivered message. This makes application logic cleaner because the client does not have to guess why a message arrived or manually compare it against every subscribed filter.

In practical terms, this is useful when one client is listening for different kinds of data such as telemetry, alerts, and control acknowledgments. Instead of writing extra parsing logic, the client can use the identifier to route the message to the right processing path immediately.

Example

A monitoring application subscribes to one filter for devices/+/telemetry and another for devices/+/alerts. When a message arrives, the subscription identifier helps the application know whether the message should be shown on a live dashboard, routed to alert handling, or stored for analysis.

Subscription identifiers to help applications intelligently route telemetry and alert messages for dashboards, alerting workflows, and analytics processing.

Why customers like it

Simpler client code
Cleaner separation of processing paths
Easier troubleshooting and observability
Better support for sophisticated MQTT v5 client applications

Common use cases

Applications subscribing to multiple topic categories
Edge gateways handling mixed streams
Dashboards that separate operational data from alerts
Services that apply different business logic based on subscription intent

Putting it all together: A simple customer scenario

Consider a smart manufacturing plant. Machines, PLCs, and industrial sensors continuously publish telemetry such as production counts, machine health, vibration, and temperature. Operations dashboards subscribe to real-time machine status and line performance. Maintenance systems send commands to equipment when anomalies or thresholds are detected. Meanwhile, analytics workers process high-volume telemetry streams in parallel for quality monitoring, predictive maintenance, and throughput optimization.

Azure Event Grid MQTT Broker enables scalable smart manufacturing with retained state visibility, shared telemetry processing, HTTP-based command control, and intelligent subscription routing.

In this scenario, MQTT Retain support ensures that a newly opened operations dashboard immediately sees the latest machine state without waiting for the next update. Shared Subscriptions enable multiple analytics workers to process telemetry streams in parallel, improving scalability and avoiding duplicate processing. HTTP Publish of MQTT messages allows MES or maintenance applications to send commands to machines through simple HTTP requests, without needing a persistent MQTT connection. Subscription Identifiers help downstream systems distinguish between telemetry, alerts, and control signals, enabling clean routing to the right processing pipelines.

The result is a unified, event-driven architecture that is scalable, efficient, and easier to operate—supporting real-time visibility, faster decision-making, and continuous optimization across the manufacturing floor.

Azure Event Grid MQTT broker continues to make cloud-scale MQTT messaging more approachable for customers building modern IoT and event-driven solutions. Features such as MQTT Retain support, Shared Subscriptions, HTTP Publish of MQTT messages, and Subscription Identifiers help simplify application design while improving responsiveness, scale, and operational efficiency.

For teams looking to build customer-ready solutions faster, these capabilities can reduce custom code, accelerate onboarding, and create a smoother path from proof of concept to production. Whether you are building connected products, industrial monitoring systems, smart spaces, or data-driven operations, Azure Event Grid MQTT broker provides a flexible foundation for reliable communication across devices, services, and applications.

Now is a great time to explore how these features can help simplify your architecture and unlock new patterns for device connectivity and cloud integration.

Announcing general availability of confidential computing for Azure Service Bus Premium

EldertGrootenboer — Mon, 11 May 2026 18:00:00 GMT

Today we are excited to announce the general availability of confidential computing for Azure Service Bus Premium. With this capability, your Service Bus namespace processes messages inside hardware-based trusted execution environments (TEEs), preventing unauthorized access to data while it is being processed. This rounds out our protection story alongside existing encryption at rest and in transit, giving customers with regulatory or sensitive workloads a way to protect their messaging data through every stage of its lifecycle.

How confidential computing fits with existing Service Bus security

Service Bus already provides strong protection for messaging data. TLS encryption protects data in transit, and encryption at rest with optional support for customer-managed keys (CMK) protects data at rest. Network controls such as private endpoints, IP firewall rules, and managed identities restrict who can reach the namespace and how it authenticates to dependent services.

Confidential computing fills the remaining gap by adding hardware-level isolation to data in use. When a Service Bus Premium namespace runs on confidential compute hardware, message processing happens inside a TEE, an isolated portion of the processor and memory that even privileged operators cannot access. This is the same model that backs Azure confidential computing for VMs and containers, now applied to managed messaging.

Concepts

Confidential computing is a namespace-level setting. You enable it when you create a Service Bus Premium namespace, and the setting is immutable for the lifetime of the namespace. After it is enabled, all queues, topics, and subscriptions in that namespace benefit from hardware-isolated processing automatically. No application changes are required, so existing clients and messaging patterns continue to work without modification.

Because the setting is immutable, customers who want to move an existing workload to confidential computing need to create a new namespace with the setting enabled and migrate their queues and topics across.

Regional availability

At general availability, confidential computing for Service Bus Premium is available in Korea Central and UAE North.

Getting started

You can enable confidential computing on a new Service Bus Premium namespace from the Azure portal:

In the Azure portal, open the Create namespace page.
Select Premium for the pricing tier.
Select a supported region.
For Confidential compute, select Enabled.
Fill in the remaining fields and select Review + create.

You can also enable confidential computing programmatically through Bicep, ARM templates, or any other deployment tooling that supports the platformCapabilities property on the namespace resource.

Combine with customer-managed keys for maximum protection

For workloads with the strictest requirements, we recommend pairing confidential computing with customer-managed keys backed by Azure Key Vault Managed HSM. This combination protects data in use through the TEE, protects data at rest through validated hardware security modules, and keeps full control of the encryption keys with the customer. Together with private endpoints and managed identities, this gives customers a defense-in-depth posture that meets the most stringent regulatory and compliance requirements.

More information on this feature can be found in the documentation.

Azure Service Bus Premium now offers 99.99% SLA in all Availability Zone regions

EldertGrootenboer — Mon, 11 May 2026 17:00:00 GMT

Today we are excited to announce an update to the Azure Service Bus Service Level Agreement. Starting May 1, 2026, all Premium namespaces deployed in regions with Availability Zone support will receive a 99.99% uptime SLA. This applies regardless of whether partitioning is enabled on the namespace.

Service Bus Premium is the tier customers choose for their most important workloads, where dedicated resources, predictable performance, and strong isolation matter. With this update, the SLA matches the resilience those deployments already have when they run across Availability Zones.

What is an Availability Zone

Availability Zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking. A Premium namespace deployed in an Availability Zone region is automatically replicated across multiple zones, so the messaging service stays available even if a full datacenter goes offline. The new 99.99% SLA reflects this zone-redundant deployment model, with no additional configuration required.

What changed

Previously, the 99.99% SLA was available only for Premium namespaces that had partitioned namespaces enabled and were deployed in a region with Availability Zone support. With this update, we are removing the partitioning requirement. Any Premium namespace in an Availability Zone region now qualifies for the 99.99% SLA - no configuration changes needed.

Scenario	SLA before May 1	SLA from May 1
Premium, AZ region, partitioned	99.99%	99.99%
Premium, AZ region, non-partitioned	99.9%	99.99%
All tiers, non-AZ region	99.9%	99.9%

For customers already running Premium namespaces in Availability Zone regions without partitioning, this is an automatic improvement - there is nothing to change or reconfigure.

Why this matters

When we announced general availability of partitioned namespaces in November 2023, we introduced the 99.99% SLA as a benefit tied to both partitioning and Availability Zones. Partitioning helps workloads that need higher throughput, but not every workload requires it. Customers who chose Premium for its dedicated resources, network isolation, and predictable performance - but did not need the throughput scaling of partitioned namespaces - were left at the 99.9% tier despite being deployed with zone redundancy.

This update recognizes that the core reliability benefit comes from the Availability Zone deployment itself. Premium namespaces in AZ regions already run on zone-redundant infrastructure, and the SLA now reflects that.

What about partitioned namespaces

Partitioned namespaces remain fully supported and continue to provide throughput benefits by distributing messaging across multiple brokers. The change here is purely about the SLA eligibility - partitioning is no longer a prerequisite for the higher SLA. If your workload benefits from partitioned namespaces for throughput reasons, we still recommend using them.

Getting started

If you are already running a Premium namespace in an Availability Zone region, you automatically benefit from the 99.99% SLA starting May 1, 2026. No action is required.

If you are running a Standard namespace and your workload demands the higher availability that comes with Premium, consider upgrading to the Premium tier. Premium is built for the workloads where messaging cannot fail, providing dedicated resources, predictable performance, network isolation features like VNet integration and private endpoints, and now a 99.99% SLA in any Availability Zone region.

More information can be found in the SLA for Azure Service Bus and the Service Bus Premium tier documentation.

Stripe Events + Azure Event Grid: Now Generally Available

robece — Mon, 11 May 2026 15:38:22 GMT

Stripe events give developers real-time visibility into everything happening in their Stripe accounts — payments, subscriptions, refunds, disputes, and more. With Azure Event Grid as a destination for Stripe events, now Generally Available, teams can route those signals directly into Azure and build scalable, event-driven architectures without managing webhook infrastructure.

Stripe events meet Azure Event Grid

Stripe produces events for changes across payments, customers, subscriptions, accounts, meters, and more — covering hundreds of distinct event types. Azure Event Grid acts as a fully managed event broker, routing those events directly into Azure so teams can build reactive, real-time workflows without managing custom webhook infrastructure. Here are some of the scenarios this enables:

Automate business logic on every payment: Use Azure Functions to react instantly to payment completions, refunds, or disputes — triggering fulfillment, updating inventory, or sending confirmation emails in real time.

Orchestrate cross-system workflows: Use Logic Apps to connect Stripe events to CRM systems, ERP platforms, or ticketing tools — automatically syncing data and triggering multi-step processes without writing code.

Stream events for real-time analytics: Route Stripe events to Azure Event Hubs and connect them to Microsoft Fabric Eventstream to power live dashboards, revenue trend analysis, and churn detection as events happen.

Decouple and scale payment processing: Send events to Service Bus or Storage Queues to buffer and distribute high-volume payment workloads across independent consumers, ensuring reliability and scalability under load.

Integrate with external systems and partners: Use Webhooks or Hybrid Connections to forward Stripe events to third-party platforms, on-premises systems, or partner services — without exposing internal infrastructure.

Fan out events across multiple consumers: Publish to Azure Event Grid Namespace Topics to broadcast a single Stripe event to multiple subscribers simultaneously, enabling parallel processing across different teams or services.

This creates a clean separation between event ingestion, routing, and processing, following modern event-driven design principles.

Deep Dive: Processing Core Payment Events with Azure Event Grid

To build a production-ready integration that reacts to business-critical signals like successful payments or disputes, follow these steps to route Stripe events through Azure Event Grid.

Set up Partner Authorization in Azure: Register the Event Grid resource provider in the Azure portal and create a Partner Authorization to grant Stripe permission to create Partner Topics.
Configure the Event Destination in Stripe: In the Stripe Dashboard, configure the event destination by providing your Azure subscription ID, resource group, and region to connect the accounts.
Activate the Partner Topic: Once Stripe creates the Partner Topic in your Azure resource group, you must activate it in the Azure portal within seven days to begin receiving events.
Create an Event Subscription and Handler: Set up an Event Subscription to route events from the Partner Topic to an Azure service, such as an Azure Function or Logic App, which acts as your event handler.
Process the Payment Event Object: Your handler will receive event objects formatted using the CloudEvents schema. Parse these objects and implement your application logic to react to specific event types like payment_intent.succeeded or charge.dispute.created.
Retrieve Full Resource Data (Hydration): For full context, use "thin event hydration" to fetch the complete resource object (e.g., the full Charge or PaymentIntent) via a call to the Stripe API using the object ID provided in the event data.

Production and Reliability Notes

Switch your integration to use live mode API keys and data sources for production readiness.
Stripe automatically retries failed deliveries for up to three days in live mode.
Event ordering is not guaranteed through Event Grid.
Note: Events are delivered using the CloudEvents schema, and Stripe provides automatic retries for failed deliveries for up to three days.

Extending Stripe events into Fabric Real-Time Intelligence

Every payment, subscription change, and customer action in Stripe carries a signal. The question is how fast your business can act on it.

Azure Event Grid namespaces connect natively with Microsoft Fabric Real-Time Intelligence through Eventstream, turning Stripe events into continuous data streams — no custom ingestion pipelines required. As events flow in, they can be transformed, enriched, and joined with other business signals in real time.

This opens a new layer of intelligence on top of your commerce data: revenue anomalies surfaced as they happen, churn patterns detected before they compound, and live dashboards that reflect the actual state of your business — not yesterday’s batch.

For teams already invested in Fabric, this means Stripe becomes a first-class real-time data source alongside the rest of your operational data.

Getting started

The Stripe destination for Azure Event Grid is now Generally Available. To get started, configure Azure Event Grid as an event destination in your Stripe dashboard.

Stripe provides clear guidance for setting up the Azure Event Grid destination and sending events into your Azure environment: Stripe documentation for Azure Event Grid.

Once configured, events can be routed to Azure services or streamed into Fabric Eventstream for real-time analytics and insights.

Building on Public Preview

This release marks the General Availability of the Stripe destination for Azure Event Grid, which was first introduced in Public Preview. If you missed the initial announcement, you can read the original blog post: Powering Event-Driven Payments with Stripe and Azure Event Grid.

Protect Your Streaming Data in Use: Confidential Computing for Azure Event Hubs Dedicated

ashish-chhabria — Fri, 01 May 2026 16:11:46 GMT

For organizations in regulated industries — financial services, healthcare, government, defense — the security conversation around data has always revolved around two states: data at rest and data in transit. Encrypt your storage. Encrypt your network traffic. Check, check.

But there's a third state that's been much harder to address: data in use. What happens to your events while they're being actively processed by the streaming infrastructure? While they're in memory on the broker, being indexed, being replicated? That's the gap that confidential computing closes.

Today, we're announcing confidential computing support for Azure Event Hubs Dedicated clusters, available now in Korea Central and UAE North.

Event Hubs already provides a comprehensive security model: Entra ID authentication, RBAC, TLS 1.2+ in transit, encryption at rest with Microsoft-managed or customer-managed keys, private endpoints, and network isolation.

Confidential computing completes the picture. It uses hardware-based Trusted Execution Environments (TEEs) — an industry standard defined by the Confidential Computing Consortium, of which Microsoft is a founding member — to protect your event data while it's being actively processed. The TEE creates an encrypted boundary at the silicon level, preventing unauthorized access even from privileged software or compromised infrastructure operators.

Your data is now protected across all three states: at rest, in transit, and in use.

Why This Is a Natural Fit for Dedicated

Event Hubs Dedicated already provides single-tenant, hardware-isolated clusters. Your resources aren't shared with any other customer. Confidential computing extends that isolation model to the compute layer itself — the dedicated hardware your events run on now operates inside a Trusted Execution Environment.

And the best part for your engineering teams: confidential computing requires zero changes to your applications. Your producers and consumers continue to use the same Event Hubs SDK or Apache Kafka® APIs. Connection strings, authentication, partition strategies — nothing changes. You create a new Dedicated cluster with confidential computing enabled, provision your namespaces on it, and the protection is transparent from that point forward.

Defense in Depth

Confidential computing is most powerful when combined with other Event Hubs security capabilities. For maximum data protection, pair it with customer-managed keys backed by Azure Key Vault Managed HSM:

Layer	Protection
Data in use	Confidential computing (TEE) — New
Data in transit	TLS 1.2+, always-on
Data at rest	Customer-managed keys in Managed HSM
Identity	Microsoft Entra ID + RBAC + managed identities
Network	Private endpoints, VNet rules, IP firewall
Infrastructure	Single-tenant dedicated clusters
Governance	Azure Policy enforcement

With this combination, your encryption keys are stored in FIPS 140-2 Level 3 validated hardware security modules, your data is encrypted with keys only you control, and your compute is isolated at the hardware level. No single party — including the cloud provider — can access unencrypted data.

You can also use Azure Policy to enforce that all Dedicated clusters in your organization have confidential computing enabled, ensuring consistent security posture across your environment.

What You Need to Know

Tier: Dedicated only.
Regions: Korea Central and UAE North.
New clusters required: Confidential computing must be enabled at cluster creation time. You cannot enable it on existing clusters. If you're running a Dedicated cluster today and want this capability, you'll need to create a new cluster with confidential computing enabled and provision your namespaces on it.
Impact to applications: None. Zero code changes required. Your producers and consumers connect to the new namespace the same way they always have.

Get Started

If you're already running an Event Hubs Dedicated cluster and need confidential computing, the path is straightforward: create a new Dedicated cluster with confidential computing enabled in a supported region, then create your namespaces on that new cluster. Since your applications require zero code changes, this is an infrastructure migration — not an application migration. We recommend validating with a non-production workload first to confirm your applications behave identically.

If you're evaluating Event Hubs Dedicated for a new workload with strict security requirements, confidential computing gives you one more reason to choose the Dedicated tier: hardware-level protection you can point to when your compliance team asks "how is the data protected while it's being processed?"

For step-by-step instructions — including portal walkthrough, Bicep templates, ARM templates, and Azure Policy definitions — see the full documentation:

➡️ Confidential computing for Azure Event Hubs

Announcing general availability of Network Security Perimeter for Azure Service Bus

EldertGrootenboer — Fri, 03 Apr 2026 16:31:50 GMT

Today we are excited to announce the general availability of Network Security Perimeter (NSP) support for Azure Service Bus. Network Security Perimeter allows you to define a logical network boundary around your Service Bus namespaces and other Azure PaaS resources, restricting public network access and enabling secure communication between services within the perimeter. This builds on the existing network security options for Service Bus - IP firewall rules, VNet service endpoints, and private endpoints - by providing centralized, perimeter-level control over which resources can communicate with each other.

How Network Security Perimeter fits with existing network security

Service Bus already provides several options for controlling network access to your namespaces. IP firewall rules let you restrict access to specific IPv4 addresses. VNet service endpoints and private endpoints bring your Service Bus traffic onto the Microsoft backbone network, avoiding the public internet entirely. These features give you fine-grained control at the individual namespace level.

Network Security Perimeter takes a different approach. Instead of configuring network rules on each resource individually, you create a perimeter and associate your PaaS resources with it. By default, resources inside the perimeter can communicate with each other, while all public access from outside the perimeter is denied. You then define explicit inbound and outbound access rules for any traffic that needs to cross the perimeter boundary. This means a Service Bus namespace, the Azure Key Vault it uses for customer-managed keys, and any other associated resources can all be managed under one consistent set of network rules.

This is complementary to private endpoints. Private endpoints secure traffic between your virtual network and Service Bus; Network Security Perimeter secures the public endpoint of Service Bus itself. Used together, they provide defense-in-depth for your messaging infrastructure.

Concepts

Network Security Perimeter works with profiles and access rules. A profile is a collection of access rules that applies to the resources associated with it. You can use different profiles within the same perimeter to apply different rule sets to different groups of resources.

There are two access modes:

- Transition mode - the default mode when you first associate a resource. In this mode, Network Security Perimeter logs access attempts without enforcing restrictions, allowing you to understand your existing traffic patterns before locking things down.

- Enforced mode - once you are confident in your access rules, switch to enforced mode. All traffic from outside the perimeter is denied by default unless an explicit access rule permits it.

Access rules

Access rules control traffic crossing the perimeter boundary:

- Inbound rules allow traffic from specific IP address ranges or Azure subscriptions to reach your Service Bus namespace.

- Outbound rules allow your Service Bus namespace to communicate with external resources identified by fully qualified domain names (FQDNs).

Within the perimeter, PaaS-to-PaaS communication is allowed by default without additional rules.

Supported scenarios

Network Security Perimeter for Service Bus supports the following scenarios:

- Customer-managed keys (CMK) - Service Bus namespaces that use customer-managed keys need to communicate with Azure Key Vault. By placing both the Service Bus namespace and the Key Vault within the same perimeter, this communication is secured without requiring additional network configuration.

- Diagnostic logging - Network Security Perimeter provides access logs that record every allowed or denied connection attempt. These logs support audit and compliance requirements by giving you visibility into exactly what is accessing your Service Bus namespace and from where.

Getting started

You can associate your Service Bus namespace with a Network Security Perimeter directly from the namespace in the Azure portal:

On your Service Bus namespace page, select Networking under Settings.
Select the Public access tab.
In the Network security perimeter section, select Associate.
In the Select network security perimeter dialog, search for and select the perimeter you want to associate with the namespace.
Select a profile to associate with the namespace.
Select Associate to complete the association.

We recommend starting in transition mode to understand your existing traffic patterns, then moving to enforced mode once you have configured the appropriate access rules.

More information on this feature can be found in the documentation.

Powering Event Driven Payments with Stripe and Azure Event Grid

robece — Tue, 31 Mar 2026 17:41:07 GMT

Introduction

Modern commerce systems are increasingly event-driven. Payments, subscriptions, refunds, disputes, and customer updates all generate signals that downstream systems must react quickly and reliably.

Stripe events give developers real-time visibility into what is happening inside their Stripe accounts. With the new Azure Event Grid destination for events from Stripe — now available in Public Preview — developers can now route those events directly into Azure and build scalable, event-driven architectures without managing webhook infrastructure or custom brokers.

Stripe events meet Azure Event Grid

Stripe produces events for changes across a wide range of objects, including payments, customers, subscriptions, accounts, meters, and more, covering hundreds of distinct event types. These events allow developers to react in near real time to business-critical changes.

Azure Event Grid acts as a fully managed event broker between Stripe and Azure services. By configuring Azure Event Grid as an event destination in Stripe, events are automatically delivered to Azure subscribers such as:

Azure Functions
Logic Apps
Event Hubs
Service Bus
Storage queues
Hybrid Connections
Azure Event Grid Namespace Topics
Webhooks

This creates a clean separation between event ingestion, routing, and processing, following modern event-driven design principles.

Extending Stripe events into Fabric Real-Time Intelligence

Beyond operational workflows, Stripe events can also power real-time analytics scenarios using Microsoft Fabric Real-Time Intelligence.

Azure Event Grid namespaces integrate with Fabric through a native connector that allows events to flow directly into Eventstream. This makes it possible to ingest Stripe events into Fabric as continuous streams, where they can be transformed, enriched, and analyzed in real time.

With this integration, teams can:

Stream Stripe events into Fabric without building custom ingestion pipelines
Correlate payment and subscription events with other business signals
Build real-time dashboards and analytics over live commerce data
Enable downstream consumers such as KQL databases, dashboards, and analytics workloads

This unlocks an end-to-end flow where Stripe events move seamlessly from operational systems into real-time analytics, helping organizations gain immediate insight into payment behavior, revenue trends, and customer activity as events happen.

Common use cases enabled by Stripe events on Azure

Developers can unlock a wide range of scenarios by combining Stripe events with Azure services:

Payment and transaction fulfillment: React to payment completions, refunds, disputes, and payment method updates to trigger downstream business logic.

Subscription and billing lifecycle management: Track subscription creation, renewals, cancellations, and plan changes to automate billing workflows.

Customer notifications and communications: Trigger emails, push notifications, or in-app messages in response to payment or account events.

Financial operations and reconciliation: Stream transaction events into accounting systems or data stores to keep financial records in sync.

Monitoring and real-time analytics: Build real-time dashboards and insights on customer behavior, revenue trends, or churn indicators.

Customer lifecycle management: Synchronize customer updates with CRM systems and other business platforms.

Getting started

The Stripe destination for Azure Event Grid is currently available in Public Preview. To get started, configure Azure Event Grid as an event destination in your Stripe dashboard.

Stripe provides clear guidance for setting up the Azure Event Grid destination and sending events into your Azure environment: Stripe documentation for Azure Event Grid.

Once configured, events can be routed to Azure services or streamed into Fabric Eventstream for real-time analytics and insights.

"No-Ops" Kafka Experience: Why Event Hubs is Your Default Destination for Streaming on Azure

ashish-chhabria — Wed, 25 Mar 2026 22:28:51 GMT

For many engineering teams, the promise of real-time data streaming is often overshadowed by the "operational tax" of maintaining the infrastructure. Managing an Apache Kafka® cluster traditionally means wrestling with broker patches, Zookeeper (or KRaft) orchestration, disk rebalancing, and the constant anxiety of manual scaling during peak loads.

As a Product Manager for Azure Event Hubs, my conversations with customers usually start with a simple question: "How can I get the power of the Apache Kafka® ecosystem without the headache of managing it?"

The answer is Azure Event Hubs. It isn’t just a service that talks to Kafka; it is the de facto way to run Kafka on Azure. If you are building on the Azure cloud, there is no longer a need to look at self-hosted, semi-managed, or complex virtual machine-based solutions. Event Hubs is the native, cloud-scale engine designed to be your default streaming destination.

Your Code, Our Infrastructure

The most compelling reason to choose Azure Event Hubs is its protocol compatibility. We provide a Kafka-compliant endpoint that allows your existing applications, frameworks, and tools to interact with Event Hubs seamlessly.

Because the service is built on a multi-protocol engine, you keep the rich ecosystem of Apache Kafka®—including Kafka Connect and existing client libraries—while offloading the entire operational burden to Azure. Whether you are migrating an existing workload or starting fresh, you can leverage the industry-standard Kafka APIs while benefiting from a platform designed for the cloud.

Choosing the Right Tier for Your Journey

We believe that high-scale streaming should be accessible to everyone, from three-person startups to global enterprises. Our tiers are structured to support your growth at every stage:

Standard Tier: The Cost-Effective Entry Point For many common use cases—like basic log aggregation, website clickstream analysis, or simple pub-sub messaging—the Standard Tier is the perfect fit. It supports core Apache Kafka® protocol features and provides a reliable, managed experience that allows teams to prove out concepts without heavy financial or operational commitments.
Premium & Dedicated Tiers: Enterprise-Grade Power When your workloads become mission-critical, our Premium and Dedicated tiers unlock the full potential of the platform. These tiers are built for high-throughput, low-latency scenarios and include advanced Kafka-specific features such as:
- Kafka Transactions: Essential for exactly-once processing requirements.
- Kafka Streams: Support for stateful stream processing.
- Advanced Compression & Dynamic Partitioning: For optimized scaling and cost management.
- Geo-replication: Turnkey replication of metadata and data across regions with customer managed RPO (including RPO=0).

The Hub of the Modern Data Stack

Event Hubs is the "nervous system" of the Azure ecosystem. It doesn't just ingest data; it bridges the gap between raw events and actionable insights through deep, native integrations:

Serverless Scaling: Features like Auto-Inflate allow your throughput to scale automatically as traffic spikes, ensuring you never drop a message during a surprise surge.
Microsoft Fabric & Real-Time Intelligence: With the emergence of Microsoft Fabric, Event Hubs serves as the primary feeder for real-time analytics. You can stream Kafka data directly into a Fabric Lakehouse with zero-code integrations, making "real-time" a reality for your entire data team.
One-Click Archival: Use Event Hubs Capture to automatically batch and move streaming data into Azure Data Lake Storage for long-term cold storage or batch processing.

The Bottom Line

If you are building on Azure, running your own Kafka infrastructure is technical debt you don't need to carry. Azure Event Hubs provides the reliability of a battle-tested cloud-native engine with the familiarity of the Apache Kafka® ecosystem. It is the most robust, scalable, and integrated way to bring streaming to your organization.

Ready to Migrate?

If you are currently running a Kafka cluster and are ready to offload the operational burden, our documentation provides a comprehensive roadmap. Migrate to Azure Event Hubs for Apache Kafka Ecosystems

Azure Event Grid MQTT Broker: Enterprise-Grade Messaging for the Connected World

Connected-Seth — Mon, 23 Mar 2026 17:48:18 GMT

Azure Messaging · What's New · March 2026

The Enterprise MQTT Broker
for Every Connected Ecosystem

Scale to millions of devices, enforce zero-trust security, and route real-time events across every service, system, and application — all on Azure's hyperscaler-grade messaging backbone.

1,000

msg/sec/session

5M+

concurrent connections

1 MB

large message support

TLS 1.2+

enforced encryption

The Modern Broker for Every Connected Ecosystem

Whether you're connecting vehicles, factory floors, edge devices, retail infrastructure, financial systems, or cloud-native services — Azure Event Grid MQTT Broker is the enterprise messaging backbone that scales from prototype to planet. With deep Azure integration, full MQTT compliance, and hyperscaler-grade security, it's the broker you ship on when it truly matters.

Core Protocol

📡 Full MQTT Protocol Coverage

End-to-end MQTT compliance across all versions, transports, and messaging patterns — so any client, any device, any stack just connects.

MQTT v3.1.1

Full compliance

MQTT v5.0

Rich features + user props

TCP Transport

Low-latency, always-on

WebSocket

Browser + web-native

HTTP Publish

REST-based ingestion

💬

MQTT v5 Enhancements

Richer error signaling, user properties, message expiry, and request–response patterns built in.

🌐

HTTP Publish (REST Bridge)

Non-MQTT services publish via HTTPS. Ideal for REST backends, legacy systems, and webhooks joining real-time workflows.

🔀

Shared Subscriptions

Load-balance messages across consumer groups. Scale processing horizontally without duplication.

Preview

Zero-Trust Security

🔒 Enterprise Authentication Stack

Multi-layered security for every fleet size — from embedded devices to enterprise IAM platforms. Every connection authenticated, every access authorized.

🏛️

Microsoft Entra ID / OAuth 2.0 JWT

Authenticate via any OIDC-compliant identity provider — Entra ID, Auth0, custom IAM platforms.

📜

X.509 Certificate Authentication

Hardware-rooted identity for devices. Mutual TLS, cert fingerprint validation, and PKI integration.

🪝

Custom Webhook Authentication

Dynamically validate clients via Azure Functions or external services. SAS keys, API keys, cert fingerprints — full programmatic control.

🌐

TLS 1.2+ Enforced

Transport-layer encryption enforced by default. No downgrade paths. Compliant with regulated industries.

Assigned Client Identifiers — Deterministic Identity

Pre-assign approved MQTT client IDs for session continuity, enhanced diagnostics, and audit trails. Critical for regulated industries, long-lived device connections, and operational compliance across large fleets.

Hyperscaler Performance

⚡ Built for Massive Scale

From startup-scale prototypes to workloads with up to 5M+ concurrent device connections — Event Grid MQTT Broker grows with your ambitions.

1,000

messages/sec/session (ingress)

View Quotas & Limits →

High-frequency industrial and automotive signal processing at full speed, per session.

15

topic segments (GA)

View Quotas & Limits →

Deep hierarchical topic modeling for structured fleets, factories, and telemetry pipelines.

🔢 1 MB Large Message Support Send high-res images, video frames, and large telemetry batches. No pre-chunking needed. Preview	📈 Auto Scale Up & Down Elastic namespace scaling that responds to demand in real time — pay for what you use, never throttle a workload. Coming Soon in Preview	🌐 IPv6 Support Native dual-stack networking for modern infrastructure, next-gen telecom, and global device deployments. Coming Soon in Preview
🚀 Up to 5M+ Connections Running large-scale workloads? Talk to us — we'll onboard your production workload with dedicated hands-on support. Contact Us →	📦 Bulk Client Onboarding API Register thousands of devices in a single API call — credentials, certificates, and auth rules in batch. CI/CD-native. Preview	📤 High Egress Throughput Up to 500 msg/sec/instance egress for high fan-out scenarios. Perfect for dashboards, monitoring, and analytics consumers. Preview

Azure Native Integration

🔀 MQTT Events, Everywhere in Azure

Route MQTT streams directly into Azure's full analytics, automation, and real-time intelligence stack — seamlessly connected to every Azure service you already use.

🌊

Fabric Eventstreams

📊

Azure Data Explorer

📨

Event Hubs

⚙️

Azure Functions

🔗

Logic Apps

🌟 First-Class Microsoft Fabric Integration

Route MQTT messages and CloudEvents directly from Event Grid Namespaces to Fabric Eventstreams — enabling real-time analytics, storage, and visualization of IoT data without an Event Hub intermediary. Reference architectures for every industrial vertical are available on Microsoft Learn and via the RTI Reference Architectures.

State & Presence

💡 Last Will & Testament + Retained Messages

Know the last known state of every device, and be instantly notified when something goes offline — essential for mission-critical connected systems.

📣

Last Will & Testament (LWT)

Immediately notify downstream subscribers when a device disconnects unexpectedly. Critical for industrial automation, fleet monitoring, and health-critical telemetry.

📌

Retained Messages

Subscribers receive the latest device value immediately on connect. Configurable expiry, on-demand clearing, Get/List API, and portal experience coming soon.

Industry 4.0

🏭 Sparkplug B on Azure — Smart Factory, Unlocked

The industrial MQTT standard runs natively on Event Grid MQTT Broker — bringing real-time factory floor intelligence to Azure analytics pipelines. Learn more about Sparkplug B support →

🔴

Device Lifecycle (BIRTH/DEATH)

Track when machines come online and offline. LWT handles unexpected disconnects with zero configuration.

🔧

SCADA Integration

Auto-discover tags in Ignition SCADA with Cirrus Link Chariot. Seamless edge-to-cloud tag sync and live machine vitals.

📊

Azure Data Explorer / Fabric

Industrial binary Sparkplug payloads ingested into ADE or Fabric for real-time dashboards and automated alerting.

Edge to Cloud: How It Flows

1	Sensors on the factory floor Machines publish temperature, RPM, and status as Sparkplug B messages via edge gateways.
2	Azure Event Grid MQTT Broker ingests QoS 1 delivery, TLS secured, with LWT for device state awareness and retained messages for new subscribers.
3	SCADA auto-discovers tags Ignition SCADA with Chariot Cirrus Link sees all published tags in real time — zero manual configuration.
4	Azure Data Explorer / Fabric analytics Same stream bifurcated — live operational view and cloud-scale analytics for predictive maintenance and automated alerting.

Operational Visibility

📊 Deep Metrics for Every Deployment

Full operational telemetry across all broker functions — detect issues, optimize throughput, and ensure SLA compliance at any scale.

⏱️

CONNACK / PUBACK Latency

Measure end-to-end connection and publish acknowledgment times. Baseline and alert on latency degradation.

✅

Publish / Subscribe Success Rates

Track success, failure, and throttling events per topic and per session to quickly isolate problems.

🔌

Active Connections

Real-time view of live connections, throughput, and session health across your entire device fleet.

Customer Impact

🌍 Built for Every Connected Industry

From connected vehicles to financial trading infrastructure to smart retail — Event Grid MQTT Broker powers the most demanding workloads across every sector.

🚗 Connected Automotive → Real-time vehicle telemetry at fleet scale → Over-the-air event routing and signaling → Edge-to-cloud V2X messaging pipelines → TLS/mTLS for per-vehicle identity → High-frequency CAN bus signal ingestion	🏭 Smart Manufacturing → Sparkplug B + SCADA tag auto-discovery → Predictive maintenance event pipelines → Factory floor machine state monitoring → Bulk device onboarding for plant rollouts → QoS 1 delivery for critical control signals	🖥️ DCIM / Data Centre → Real-time rack power and thermal monitoring → High-frequency sensor event ingestion → Automated alerting and threshold triggers → Secure multi-tenant device namespaces → Fabric Eventstreams for real-time dashboards
🏦 Finance & Payments → Low-latency event streaming for trading signals → Real-time payment status notifications → Fraud detection event pipelines → OAuth 2.0 / Entra ID for regulated access → Audit-ready assigned client identifiers	🛒 Retail & Commerce → Real-time inventory and shelf sensor updates → Point-of-sale event routing at scale → Connected checkout and payment device streams → In-store IoT device fleet management → Live promotions and pricing event broadcast	🏢 Smart Buildings → HVAC, lighting, and energy sensor telemetry → Access control and occupancy event streams → Elevator and facility equipment monitoring → Multi-tenant building namespace isolation → Retained messages for last-known device state

What's Next

🔭 Coming Soon to Preview

These capabilities are entering preview soon — start evaluating for your workloads today.

Preview Large Message Packets (1 MB) Send images, video frames, and large telemetry batches without chunking. Streamlines edge-to-cloud ingestion.	Preview Shared Subscriptions Load-balance across consumer groups for parallel message processing at scale — no duplication, built-in fault tolerance.
Preview Subscription Identifier MQTT v5 compliance — tag subscriptions for routing, multiplexing, and fine-grained handler dispatch.	Preview Bulk Client Onboarding API Provision entire device fleets in a single API call. Automate with CI/CD pipelines for factory and field deployments.
Coming Soon Auto Scale Up & Down Elastic namespace scaling that automatically expands and contracts broker capacity in response to real-time load.	Coming Soon IPv6 Support Dual-stack connectivity for next-gen networks, modern telecom infrastructure, and global IoT deployments.

Want early access to any of these previews?

We're actively onboarding early customers for all upcoming preview capabilities. Whether you're running a connected fleet, industrial workload, or large-scale IoT deployment — get in touch and we'll get you started.

Ready to Connect Everything?

Azure Event Grid MQTT Broker is generally available. Start building enterprise-grade connected ecosystems today — or talk to us about your production workload.

Get Started on Azure Talk to an Expert → Explore Reference Architectures

Azure MQTT IoT Event Grid

Introducing Administration Client Support for the Azure Service Bus Emulator

Sannidhya_Glodha — Fri, 16 Jan 2026 17:36:47 GMT

We’re excited to announce administration client support for the Azure Service Bus emulator, extending the emulator beyond messaging operations to include management capabilities such as creating, updating, and deleting entities locally.

Azure Service Bus is a fully managed enterprise message broker that supports reliable messaging through queues and publish‑subscribe topics. Since the introduction of the local emulator, developers have been able to develop and test message flows locally. With this update, the emulator now supports a broader set of workflows that depend on management operations as part of application startup or deployment.

Why Administration Client support?

Until now, the Service Bus emulator supported declarative entity configuration through a configuration file, allowing developers to define entities before starting the emulator. While this worked well for static setups, it limited workflows that require dynamic, runtime entity creation or management.

Administration Client support unlocks on‑the‑fly entity creation and management, enabling developers to create, update, or delete entities while the emulator is running. This removes the need to restart the emulator for common management operations and brings the local development experience closer to real‑world Azure Service Bus usage.

How it works

By default, the emulator uses port 5300 for management operations. When performing management tasks with the Service Bus Administration Client, be sure to add the port number to the emulator connection string.

Declarative configuration using the emulator’s configuration file remains supported and continues to serve as the source of truth during emulator initialization. Any configuration defined in the file is reapplied when the emulator is initialized and overrides entities created through the Administration Client, making it easy to reset or standardize local environments.

For the Service Bus emulator, management operations using the Service Bus Administration Client are natively supported in .NET. Language‑specific reference samples are available to help you get started.

Getting started

The Azure Service Bus emulator is available as a Docker image and runs on Windows, macOS, and Linux. You can interact with the emulator using the latest Service Bus client SDKs for messaging operations, and use the Service Bus Administration Client to manage entities locally during development and testing.

To explore administration scenarios, including creating and deleting queues or topics, refer to the Service Bus emulator reference samples.

For more details about the emulator and supported features, visit aka.ms/servicebusemulator

Share your feedback

We appreciate your feedback as we continue to improve the Service Bus emulator. Please share issues, suggestions, or feature requests through the GitHub repository to help us refine the local development experience.

Happy building—and may all your local tests pass! 😊

Announcing General Availability of Geo-Replication for Azure Service Bus Premium

EldertGrootenboer — Wed, 17 Dec 2025 17:00:00 GMT

Today we are excited to announce general availability of the Geo-Replication feature for Azure Service Bus in the premium tier. This feature ensures that the metadata and data of a namespace are continuously replicated from a primary region to a secondary region. Moreover, this feature allows promoting a secondary region at any time. The Geo-Replication feature is the latest option to insulate Azure Service Bus applications against outages and disasters. Other options are Geo-Disaster Recovery and Availability Zones.

Differentiation

There are currently two features that provide Geo-Disaster Recovery in Azure Service Bus for the Premium tier. First, there is Geo-Disaster Recovery (Metadata DR) that just provides replication of metadata. Second, Geo-Replication, which is now GA, provides replication of both metadata and data. Neither Geo-Disaster Recovery feature should be confused with Availability Zones. Regardless of if it is Metadata DR or Geo replication, both geographic recovery features provide resilience between Azure regions such as East US and West US.

Availability Zones are available on all Service Bus tiers, and support provides resilience within a specific geographic region, such as East US. For a detailed discussion of disaster recovery in Microsoft Azure, see this article.

Concepts

The Geo-Replication feature implements metadata and data replication in a primary-secondary replication model. It works with a single namespace, and at a given time there’s only one primary region, which is serving both producers and consumers. There is a single hostname used to connect to the namespace, which always points to the current primary region. After promoting a secondary region, the hostname points to the new primary region, and the old primary region is demoted to secondary region. After the new secondary has been re-initialized, it is possible to promote this region again to primary at any moment.

Replication modes

There are two replication modes, synchronous and asynchronous. It's important to know the differences between the two modes.

Asynchronous replication

Using asynchronous replication, all requests are committed on the primary, after which an acknowledgment is sent to the client. Replication to the secondary regions happens asynchronously. Users can configure the maximum acceptable amount of lag time, the offset between the latest action on the primary and the secondary regions. If the lag for an active secondary grows beyond user configuration, the primary will throttle incoming requests.

Synchronous replication

Using synchronous replication, all requests are replicated to the secondary, which must commit and confirm the operation before committing on the primary. As such, your application publishes at the rate it takes to publish, replicate, acknowledge, and commit. Moreover, it also means that your application is tied to the availability of both regions. If the secondary region goes down, messages aren't acknowledged and committed, and the primary will throttle incoming requests.

Promotion

The customer is in control of promoting a secondary region, providing full ownership and visibility for outage resolution. When choosing Planned promotion, the service waits to catch up the replication lag before initiating the promotion. On the other hand, when choosing Forced promotion, the service immediately initiates the promotion.

Pricing

The Premium tier for Service Bus is priced per Messaging Unit. With the Geo-Replication feature, secondary regions run on the same number of MUs as the primary region, and the pricing is calculated over the total number of MUs. Additionally, there is a charge for based on the published bandwidth times the number of secondary regions.

More information on this feature can be found in the documentation.

JSON Structure: A JSON schema language you'll love

clemensv — Wed, 17 Dec 2025 08:03:09 GMT

We talk to many customers moving structured data through queues and event streams and topics, and we see a strong desire to create more efficient and less brittle communication paths governed by rich data definitions well understood by all parties. The way those definitions are often shared are schema documents. While there is great need, the available schema options and related tool chains are often not great.

JSON Schema is popular for its relative simplicity in trivial cases, but quickly becomes unmanageable as users employ more complex constructs. The industry has largely settled on "Draft 7," with subsequent releases seeing weak adoption. There's substantial frustration among developers who try to use JSON Schema for code generation or database mapping—scenarios it was never designed for. JSON Schema is a powerful document validation tool, but it is not a data definition language. We believe it's effectively un-toolable for anything beyond pure validation; practically all available code-generation tools agree by failing at various degrees of complexity.

Avro and Protobuf schemas are better for code generation, but tightly coupled to their respective serialization frameworks. For our own work in Microsoft Fabric, we're initially leaning on an Avro-compatible schema with a small set of modifications, but we ultimately need a richer type definition language that ideally builds on people's familiarity with JSON Schema.

This isn't just a Microsoft problem. It's an industry-wide gap. That's why we've submitted JSON Structure as a set of Internet Drafts to the IETF, aiming for formal standardization as an RFC. We want a vendor-neutral, standards-track schema language that the entire industry can adopt.

What Is JSON Structure?

JSON Structure is a modern, strictly typed data definition language that describes JSON-encoded data such that mapping to and from programming languages and databases becomes straightforward. It looks familiar—if you've written "type": "object", "properties": {...} before, you'll feel right at home. But there's a key difference: JSON Structure is designed for code generation and data interchange first, with validation as an optional layer rather than the core concern.

This means you get:

Precise numeric types: int32, int64, decimal with precision and scale, float, double
Rich date/time support: date, time, datetime, duration—all with clear semantics
Extended compound types: Beyond objects and arrays, you get set, map, tuple, and choice (discriminated unions)
Namespaces and modular imports: Organize your schemas like code
Currency and unit annotations: Mark a decimal as USD or a double as kilograms

Here's a compact example that showcases these features. We start with the schema header and the object definition:

{ "$schema": "https://json-structure.org/meta/extended/v0/#", "$id": "https://example.com/schemas/OrderEvent.json", "name": "OrderEvent", "type": "object", "properties": {

Objects require a name for clean code generation. The $schema points to the JSON Structure meta-schema, and the $id provides a unique identifier for the schema itself.

Now let's define the first few properties—identifiers and a timestamp:

"orderId": { "type": "uuid" }, "customerId": { "type": "uuid" }, "timestamp": { "type": "datetime" },

The native uuid type maps directly to Guid in .NET, UUID in Java, and uuid in Python. The datetime type uses RFC3339 encoding and becomes DateTimeOffset in .NET, datetime in Python, or Date in JavaScript. No format strings, no guessing.

Next comes the order status, modeled as a discriminated union:

"status": { "type": "choice", "choices": { "pending": { "type": "null" }, "shipped": { "type": "object", "name": "ShippedInfo", "properties": { "carrier": { "type": "string" }, "trackingId": { "type": "string" } } }, "delivered": { "type": "object", "name": "DeliveredInfo", "properties": { "signedBy": { "type": "string" } } } } },

The choice type is a discriminated union with typed payloads per case. Each variant can carry its own structured data—shipped includes carrier and tracking information, delivered captures who signed for the package, and pending carries no payload at all. This maps to enums with associated values in Swift, sealed classes in Kotlin, or tagged unions in Rust.

For monetary values, we use precise decimals:

"total": { "type": "decimal", "precision": 12, "scale": 2 }, "currency": { "type": "string", "maxLength": 3 },

The decimal type with explicit precision and scale ensures exact monetary math—no floating-point surprises. A precision of 12 with scale 2 gives you up to 10 digits before the decimal point and exactly 2 after.

Line items use an array of tuples for compact, positional data:

"items": { "type": "array", "items": { "type": "tuple", "properties": { "sku": { "type": "string" }, "quantity": { "type": "int32" }, "unitPrice": { "type": "decimal", "precision": 10, "scale": 2 } }, "tuple": ["sku", "quantity", "unitPrice"], "required": ["sku", "quantity", "unitPrice"] } },

Tuples are fixed-length typed sequences—ideal for time-series data or line items where position matters. The tuple array specifies the exact order: SKU at position 0, quantity at 1, unit price at 2. The int32 type maps to int in all mainstream languages.

Finally, we add extensible metadata using set and map types:

"tags": { "type": "set", "items": { "type": "string" } }, "metadata": { "type": "map", "values": { "type": "string" } } }, "required": ["orderId", "customerId", "timestamp", "status", "total", "currency", "items"] }

The set type represents unordered, unique elements—perfect for tags. The map type provides string keys with typed values, ideal for extensible key-value metadata without polluting the main schema.

Here's what a valid instance of this schema looks like:

{ "orderId": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "customerId": "7c9e6679-7425-40de-944b-e07fc1f90ae7", "timestamp": "2025-01-15T14:30:00Z", "status": { "shipped": { "carrier": "Litware", "trackingId": "794644790323" } }, "total": "129.97", "currency": "USD", "items": [ ["SKU-1234", 2, "49.99"], ["SKU-5678", 1, "29.99"] ], "tags": ["priority", "gift-wrap"], "metadata": { "source": "web", "campaign": "summer-sale" } }

Notice how the choice is encoded as an object with a single key indicating the active case—{"shipped": {...}}—making it easy to parse and route. Tuples serialize as JSON arrays in the declared order. Decimals are encoded as strings to preserve precision across all platforms.

Why Does This Matter for Messaging?

When you're pushing events through Service Bus, Event Hubs, or Event Grid, schema clarity is everything. Your producers and consumers often live in different codebases, different languages, different teams. A schema that generates clean C# classes, clean Python dataclasses, and clean TypeScript interfaces—from the same source—is not a luxury. It's a requirement.

JSON Structure's type system was designed with this polyglot reality in mind. The extended primitive types map directly to what languages actually have. A datetime is a DateTimeOffset in .NET, a datetime in Python, a Date in JavaScript. No more guessing whether that "string with format date-time" will parse correctly on the other side.

SDKs Available Now

We've built SDKs for the languages you're using today: TypeScript, Python, .NET, Java, Go, Rust, Ruby, Perl, PHP, Swift, and C. All SDKs validate both schemas and instances against schemas. A VS Code extension provides IntelliSense and inline diagnostics.

Code and Schema Generation with Structurize

Beyond validation, you often need to generate code or database schemas from your type definitions. The Structurize tool converts JSON Structure schemas into SQL DDL for various database dialects, as well as self-serializing classes for multiple programming languages. It can also convert between JSON Structure and other schema formats like Avro, Protobuf, and JSON Schema.

Here's a simple example: a postal address schema on the left, and the SQL Server table definition generated by running structurize struct2sql postaladdress.json --dialect sqlserver on the right:

JSON Structure Schema	Generated SQL Server DDL
{ "$schema": "https://json-structure.org/meta/extended/v0/#", "$id": "https://example.com/schemas/PostalAddress.json", "name": "PostalAddress", "description": "A postal address for shipping or billing", "type": "object", "properties": { "id": { "type": "uuid", "description": "Unique identifier for the address" }, "street": { "type": "string", "description": "Street address with house number" }, "city": { "type": "string", "description": "City or municipality" }, "state": { "type": "string", "description": "State, province, or region" }, "postalCode": { "type": "string", "description": "ZIP or postal code" }, "country": { "type": "string", "description": "ISO 3166-1 alpha-2 country code" }, "createdAt": { "type": "datetime", "description": "When the address was created" } }, "required": ["id", "street", "city", "postalCode", "country"] }	CREATE TABLE [PostalAddress] ( [id] UNIQUEIDENTIFIER, [street] NVARCHAR(200), [city] NVARCHAR(100), [state] NVARCHAR(50), [postalCode] NVARCHAR(20), [country] NVARCHAR(2), [createdAt] DATETIME2, PRIMARY KEY ([id], [street], [city], [postalCode], [country]) ); EXEC sp_addextendedproperty 'MS_Description', 'A postal address for shipping or billing', 'SCHEMA', 'dbo', 'TABLE', 'PostalAddress'; EXEC sp_addextendedproperty 'MS_Description', 'Unique identifier for the address', 'SCHEMA', 'dbo', 'TABLE', 'PostalAddress', 'COLUMN', 'id'; EXEC sp_addextendedproperty 'MS_Description', 'Street address with house number', 'SCHEMA', 'dbo', 'TABLE', 'PostalAddress', 'COLUMN', 'street'; -- ... additional column descriptions

JSON Structure Schema

Generated SQL Server DDL

{ "$schema": "https://json-structure.org/meta/extended/v0/#", "$id": "https://example.com/schemas/PostalAddress.json", "name": "PostalAddress", "description": "A postal address for shipping or billing", "type": "object", "properties": { "id": { "type": "uuid", "description": "Unique identifier for the address" }, "street": { "type": "string", "description": "Street address with house number" }, "city": { "type": "string", "description": "City or municipality" }, "state": { "type": "string", "description": "State, province, or region" }, "postalCode": { "type": "string", "description": "ZIP or postal code" }, "country": { "type": "string", "description": "ISO 3166-1 alpha-2 country code" }, "createdAt": { "type": "datetime", "description": "When the address was created" } }, "required": ["id", "street", "city", "postalCode", "country"] }

CREATE TABLE [PostalAddress] ( [id] UNIQUEIDENTIFIER, [street] NVARCHAR(200), [city] NVARCHAR(100), [state] NVARCHAR(50), [postalCode] NVARCHAR(20), [country] NVARCHAR(2), [createdAt] DATETIME2, PRIMARY KEY ([id], [street], [city], [postalCode], [country]) ); EXEC sp_addextendedproperty 'MS_Description', 'A postal address for shipping or billing', 'SCHEMA', 'dbo', 'TABLE', 'PostalAddress'; EXEC sp_addextendedproperty 'MS_Description', 'Unique identifier for the address', 'SCHEMA', 'dbo', 'TABLE', 'PostalAddress', 'COLUMN', 'id'; EXEC sp_addextendedproperty 'MS_Description', 'Street address with house number', 'SCHEMA', 'dbo', 'TABLE', 'PostalAddress', 'COLUMN', 'street'; -- ... additional column descriptions

The uuid type maps to UNIQUEIDENTIFIER, datetime becomes DATETIME2, and the schema's description fields are preserved as SQL Server extended properties. The tool supports PostgreSQL, MySQL, SQLite, and other dialects as well.

Mind that all this code is provided "as-is" and is in a "draft" state just like the specification set. Feel encouraged to provide feedback and ideas in the GitHub repos for the specifications and SDKs at https://github.com/json-structure/

Learn More

We've submitted JSON Structure as a set of Internet Drafts to the IETF, aiming for formal standardization as an RFC. This is an industry-wide issue, and we believe the solution needs to be a vendor-neutral standard. You can track the drafts at the IETF Datatracker.

Main site: json-structure.org
Primer: JSON Structure Primer
Core specification: JSON Structure Core
Extensions: Import | Validation | Alternate Names | Units | Composition
IETF Drafts: IETF Datatracker
GitHub: github.com/json-structure

Message brokers as the cornerstone of the next generation of agentic AI backends

EldertGrootenboer — Mon, 15 Dec 2025 19:00:00 GMT

We are seeing changes in the way Agentic AI behaves. Instead of one-off model calls, we are starting to see networks of agents and MCP services working together. These are going to bring powerful integrations, with a variety of distributed components. Work is going to arrive in unpredictable bursts. Some services end up overloaded while others sit idle. Every call burns tokens and compute, so wasted effort translates directly into real money.

Direct calls are no longer enough. We are going to need orchestration. A broker in the middle that absorbs spikes, queues up work until capacity becomes available, and handles retries. This approach helps keep costs predictable by pacing work to match budgets and downstream capacity.

Message brokers, such as Azure Service Bus, are ideal for the capabilities needed in this future. Queues and topics ensure that messages stay available. Sessions maintain order across related work. Dead letter queues isolate failures without impacting the rest of the workload. Scheduled delivery and deferral allow retries and resequencing without custom logic. Message TTL ensures stale work is removed in time. Duplicate detection enforces idempotency. These capabilities are not optional. They are essential for building systems at the scale we are going to need.

Why agentic AI backends need enterprise messaging

Agentic systems are evolving into ecosystems of cooperating components. Agents fanning hundreds or thousands of tasks out, aggregating results that arrive at different times, and going through multiple refinements before reaching their final answers. Backends are not all available at once. Some become unresponsive. Others throttle. Yet the system still needs to make progress.

For example, imagine a travel booking agent. A user would inform the agent where they want to go, how they want to travel, and at what type of properties they want to stay. The agent would then send out a variety of tasks to various backend services to get this information. Some services might provide information about different flight options, others about hotels or other options for stays, etc.

The agent would gather all the information, follow up with more tasks as needed, for example to confirm availability, or to gather more specific requirements from the customer’s input. Services may respond out of order, as some may be slower than others, or may respond with substandard quality responses.

Enterprise messaging provides the backbone that makes this possible. Queues and topics absorb bursts, preserve intent when services are offline, and regulate how fast work reaches downstream components. Routing decisions are based on workflow state, not on connectivity. Workers process at the rate they can sustain.

Scale matters, but so does cost. Unnecessary retries and unneeded calls quickly start adding up. Messaging reduces this waste by enabling scheduled retries, deferred steps, batching, and prioritization. The result is predictable systems and fewer wasted tokens.

A callback to the past

We have seen this pattern before. When applications needed to integrate multiple systems, enterprise messaging and service-oriented architecture helped manage complexity and orchestrate processes. The principle remains the same: decoupling and reliable communication are how we keep complex systems from breaking under their own weight. The difference now is that agentic AI workloads are more dynamic, more granular, and more expensive when they go wrong.

Why Azure Service Bus stands out

Not every messaging option meets these demands. Streaming brokers excel at event ingestion and analytics. Basic queues handle simple point-to-point flows. However, neither delivers the enterprise messaging features that agentic systems require; ordered delivery, correlation, controlled retries, and clear failure isolation.

After all, agentic systems are unpredictable by design. Steps complete out of order. Latency varies. Results arrive when they can. Azure Service Bus provides capabilities that that are quite uniquely suited for turning this type of disorder into a manageable workflow.

Sessions for correlation and ordered processing.
Dead-letter queues for isolating failures.
Scheduled delivery and deferral for controlled retries.
TTL for time-sensitive operations.
Duplicate detection for idempotency.

These are the foundational building blocks needed for reliable agentic backends at massive scale.

Patterns for the future

As these systems grow, a few patterns are going to become critical.

Scatter / Gather

Agents will distribute work across many backend workers and then combine the results. Topics fan out these tasks. Sessions make sure that related messages are kept together. Additionally, dead letter queues can isolate failures without blocking progress for the rest of the workload.

Request / Proposal / Refinement

Agentic AI does their work through iteration. An agent proposes an action, receives partial responses, and refines until the result meets a threshold. Deferral and scheduled delivery control timing for the corresponding messages. TTL makes sure messages for stale proposals are removed when they are no longer needed. Finally, duplicate detection keeps retries safe by ensuring that duplication is detected before they are sent out to the backend systems.

Saga-like coordination

Multi-step workflows require ordered execution and detailed progress tracking. Sessions enforce sequential processing. Session state can be used to record what is done and what remains. Furthermore, dead letter queues capture failures for targeted repair while other workflows continue.

Backpressure and load shaping

Loads can spike, especially with agentic AI. Components can fall behind. This is where queues come in, to buffer the work. Scheduled delivery and concurrency control smooth arrival to the backend workers. Lock renewal protects long-running tasks. The goal is to ensure steady latency and prevent cascading failures.

Closing thoughts

Agentic AI does not behave uniformly. Workloads spike. Steps finish at different times. Availability depends on demand. Designing for this reality is essential if we want systems that scale and deliver consistent results.

Messaging provides the stability these architectures need. Azure Service Bus brings the capabilities that make orchestration practical and repeatable at the scale that is going to be needed. With the right patterns in place, irregular and asynchronous interactions become workflows that can be managed and controlled.

Messaging is not just a transport decision; it is a design principle for the next generation of agentic AI backends!

General Availability: Large Message Support in Azure Event Hubs

Sannidhya_Glodha — Tue, 18 Nov 2025 19:05:31 GMT

Azure Event Hubs is a cloud-native service that streams millions of events per second with minimal latency, fully compatible with Apache Kafka and requiring no code changes for existing Kafka workloads.

Today, we are excited to announce the general availability of Large Message Support in Azure Event Hubs, enabling you to send and receive messages up to 20 MB in self-serve scalable Dedicated clusters, with enhanced reliability for seamless handling of large messages and greater flexibility for your data streaming solutions.

This feature enables fast and reliable processing of larger, indivisible events. Large Message Support works with both AMQP and Apache Kafka protocols, allowing you to send bigger payloads as usual without changing your client code. It is advisable to check your client settings to ensure that timeouts and maximum message size limits are not set too low on the client side.

To enable Large Message Support, simply configure your eligible event hubs dedicated clusters using the Azure Portal. For further details and eligibility, please visit aka.ms/largemessagesupportforeh.

Your feedback is invaluable to us, and we look forward to hearing about your experiences.

Azure Event Hubs for Apache Kafka - Azure Event Hubs | Microsoft Learn

Quickstart: Send and Receive Large Messages with Azure Event Hubs (Preview) - Azure Event Hubs | Microsoft Learn

Upcoming Changes to Azure Relay IP Addresses and DNS Support

ashish-chhabria — Wed, 22 Oct 2025 20:06:09 GMT

Azure Relay is an integral part of modern hybrid cloud architectures, enabling seamless connectivity between on-premises and cloud resources. To ensure continued reliability and security, Microsoft is implementing important updates to the IP addresses and DNS naming conventions used by Azure Relay services.

What’s Changing?

As detailed in the changes to IP-addresses for Azure Relay and Azure Relay WCF and Hybrid Connections DNS Support reference blogs, customers should be aware of two primary changes:

IP and Name Transitions:
- The IP addresses and corresponding DNS names for Azure Relay endpoints will change during the transition period.
- For example, g0-prod-bn-vaz0001-sb.servicebus.windows.net can change to gv0-prod-bn-vaz0001-sb.servicebus.windows.net
DNS Support Enhancements:
- Improved DNS support will enhance reliability and future-proof connectivity for both WCF Relay and Hybrid Connections users.

Recommended Actions for Customers

To minimize disruption, it is crucial for users to update their network configurations and firewall rules to accommodate these new IP addresses and DNS names as soon as possible. These will be made available using the below PS1 script -

Update Allow Lists: Ensure that your firewalls and network security groups permit traffic to the new IP ranges and DNS endpoints as specified in the official documentation.
Monitor Transition Phases: Be prepared for two rounds of changes. Apply updates promptly during both the initial and final transitions.

Automating Namespace Information Retrieval

To assist with this transition, Microsoft has updated the PowerShell script for retrieving namespace information, which now reflects the planned changes. You can access the latest script here:

GetNamespaceInfo.ps1 (azure-relay-dotnet/tools) (Instructions on how to use the ps1 script is available in the README)

This script allows you to efficiently check the current configuration of your Azure Relay namespaces and validate connectivity against the updated endpoints.

Sample output

PS D:\AzureVMSSEssentials\Tools\GetNamespaceInfoWithIpRanges> .\GetNamespaceInfo.ps1 <your-relay-namespace>.servicebus.windows.net Namespace : <your-relay-namespace>.servicebus.windows.net Deployment : PROD-BN-VAZ0001 ClusterDNS : ns-prod-bn-vaz0001.eastus2.cloudapp.azure.com ClusterRegion : eastus2 ClusterVIP : 40.84.75.3 GatewayDnsFormat : g{0}-bn-vaz0001-sb.servicebus.windows.net or gv{0}-bn-vaz0001-sb.servicebus.windows.net Notes : Entries with 'FUTURE' IPAddress may be added at a later time as needed Current IP Ranges Name IPAddress ---- --------- g0-bn-vaz0001-sb.servicebus.windows.net 20.36.144.8 g1-bn-vaz0001-sb.servicebus.windows.net 20.36.144.1 g2-bn-vaz0001-sb.servicebus.windows.net 20.36.144.2 g3-bn-vaz0001-sb.servicebus.windows.net 20.36.144.11 g4-bn-vaz0001-sb.servicebus.windows.net 20.36.144.3 g5-bn-vaz0001-sb.servicebus.windows.net FUTURE g6-bn-vaz0001-sb.servicebus.windows.net FUTURE ... g98-bn-vaz0001-sb.servicebus.windows.net FUTURE g99-bn-vaz0001-sb.servicebus.windows.net FUTURE Future IP Ranges for Region:eastus2 addressPrefixes --------------- 135.18.130.0/23 135.18.132.0/26 135.18.132.64/27

What’s New in Azure Event Grid

Connected-Seth — Wed, 01 Oct 2025 23:22:50 GMT

Azure Event Grid continues to evolve with new capabilities in General Availability and Public Preview – intended to help you enhance performance, security, and interoperability in modern event-driven systems. These enhancements strengthen Azure Event Grid’s foundational messaging layer for distributed systems—supporting real-time telemetry, automation, and hybrid workloads.

With support for advanced MQTT features and flexible authentication models, Event Grid now offers:

Stronger security posture through OAuth 2.0 and Custom Webhook authentication
Operational efficiency with static client identifiers and message retention
Broader integration across devices, applications, and cloud services

General Availability Features

MQTT OAuth 2.0 Authentication

Authenticate MQTT clients using JSON Web Tokens (JWTs) issued by any OpenID Connect (OIDC)-compliant identity provider. This enables seamless integration with Microsoft Entra ID (formerly Azure AD), custom identity platforms, or third-party IAM solutions.

MQTT Custom Webhook Authentication

Use external webhooks or Azure Functions to dynamically validate client connections. Authorize using shared access signatures (SAS), API keys, custom credentials, or X.509 certificate fingerprints. This is a powerful feature for scenarios requiring granular control across large, dynamic fleets of devices or multitenant environments.

MQTT Assigned Client Identifiers

Assign deterministic, pre-approved client identifiers to MQTT clients. This enables enhanced session continuity, better device tracking, simplified diagnostics, and improved auditability—critical for managing long-lived connections and operational visibility in regulated industries. Assign deterministic, pre-approved client identifiers to MQTT clients. This enables enhanced session continuity, better device tracking, simplified diagnostics, and improved auditability—critical for managing long-lived connections and operational visibility in regulated industries.

First Class integration with Fabric

Route MQTT messages and Cloud Events from Event Grid Namespace to Fabric Event Streams for real-time analytics, storage, visualization of IoT data without having to hop thru Event Hub.

Public Preview Features

HTTP Publish

Bridge traditional HTTP-based applications into event-driven ecosystems by allowing HTTP clients to publish messages directly to Event Grid topics. This enables RESTful services, legacy systems, and webhooks to participate in real-time event workflows, complementing MQTT and cloud-native integrations.

MQTT Retain Support

Support for retained MQTT messages allows clients to receive the latest value on a topic immediately upon subscription—without waiting for the next publish. This is particularly useful in IoT telemetry scenarios, stateful dashboards, and device shadow synchronization. Retained messages are stored per topic with configurable expiry and can be cleared on demand.

Unlocking Smart Factory Insights with Sparkplug B on Azure Event Grid MQTT Broker

In the age of Industry 4.0, factories are becoming smarter, more connected, and increasingly data driven. A key enabler of this transformation is Sparkplug B, an MQTT-based protocol purpose-built for industrial IoT (IIoT). And now, with Azure Event Grid MQTT Broker, Sparkplug B comes to life in the cloud—securely, reliably, and at scale.

What is Sparkplug B?

Think of Sparkplug B as the common language for industrial devices. It defines how sensors, gateways, and SCADA systems talk to each other—sharing not just telemetry data (like temperature or RPM) but also device lifecycle information such as when a machine comes online (BIRTH) or goes offline (DEATH).

Why it Matters for Manufacturers

Real-time factory monitoring – View live machine vitals across distributed plants.
Predictive maintenance – Anticipate failures by analyzing trends.
Seamless SCADA integration – Auto-discover tags in systems like Ignition SCADA with Cirrus Link.
Edge-to-cloud bridge – Bring legacy factory systems into Azure for analytics, AI, and automation.

Azure Event Grid MQTT Broker + Sparkplug B

With Azure Event Grid MQTT Broker, manufacturers can run Sparkplug B workloads with enterprise-grade reliability. A connected factory floor where insights flow seamlessly from edge devices to cloud-unlocking efficiency, uptime, and innovation using the following capabilities:

QoS 1 for reliability (at-least-once delivery).
Last Will & Testament (LWT) for real-time device state awareness.
Retained messages to ensure new subscribers always see the last known good value.
Native support for binary Sparkplug payloads over secure TLS.

From Factory Floor to Cloud Insights

Sensors measure machine temperature and RPM.
Edge gateways publish Sparkplug B messages to Azure Event Grid MQTT Broker.
Ignition SCADA with Chariot Cirrus Link auto-discovers and displays these tags.
Azure Data Explorer or Fabric ingests the same data for real-time dashboards, predictive analytics, or automated alerts.

Ready to Get Started?

Geo-Replication is Here! Now generally available for Event Hubs Premium & Dedicated

ashish-chhabria — Thu, 17 Jul 2025 18:48:55 GMT

Today, we are thrilled to announce the General Availability of the Geo-replication feature for Azure Event Hubs, now available in both Premium and Dedicated tiers. This milestone marks a significant enhancement in our service, providing our customers with robust business continuity and disaster recovery capabilities – ensuring high availability for their mission-critical applications.

The Geo-replication feature allows you to replicate your Event Hubs data across multiple regions either synchronously or asynchronously, ensuring that your data remains accessible in the event of maintenance activities, regional degradation, or a regional outage. With Geo-replication, you can seamlessly promote a secondary region to a primary, minimizing downtime and ensuring business continuity.

Before failover (promotion of secondary to primary)

After failover (promotion of secondary to primary)

With general availability, we are excited to announce that the Geo-replication feature now supports all the features that are generally available in the service today. This includes private networking, customer-managed key encryption, Event Hubs Capture, and many more. These enhancements ensure that you can leverage the full capabilities of Event Hubs while benefiting from the added reliability of Geo-replication.

We have also increased visibility into the health and metrics of your replicas. This means you can now monitor the status of your replicas more effectively and know exactly when it is appropriate to promote your secondary to primary. This added visibility ensures that you can make informed decisions and maintain the high availability of your applications.

Since the announcement of public preview, we’ve had several customers try out the Geo-replication feature and appreciate the enhanced reliability and peace of mind that comes with having a robust disaster recovery solution in place.

Learn more

Learn more about geo-replication concepts and the pricing model and try out this quickstart to learn how to setup geo-replication for your premium and dedicated tier namespaces.

We encourage our customers to try out the Geo-replication feature and experience the benefits of turnkey business continuity and disaster recovery features firsthand.

Your feedback is invaluable to us, and we look forward to hearing about your experiences.

Announcing new features and updates in Azure Event Grid

robece — Mon, 19 May 2025 17:17:50 GMT

Discover powerful new features in Azure Event Grid, enhancing its functionality and user experience. This fully managed event broker now supports multi-protocol interoperability, including MQTT, for scalable messaging. It seamlessly connects Microsoft-native and third-party services, enabling robust event-driven applications. Streamline event management with flexible push-pull communication patterns.

We are thrilled to announce General Availability of the Cross-tenant delivery to Event Hubs, Service Bus, Storage Queues, and dead letter storage using managed identity with federated identity credentials (FIC) from Azure Event Grid topics, domains, system topics, and partner topics. New cross-tenant scenarios, currently in Public Preview enable delivery to Event Hubs, webhooks, and dead letter storage in Azure Event Grid namespaces. This includes system topics, partner topics, and domains, offering seamless integration. The update enhances flexibility for event-driven applications across tenants.

Azure Event Grid now also offers managed identity support for webhook delivery for all their resources. Public Preview features for new cross-tenant scenarios and managed identity support for webhook delivery are currently available in West Central, West Europe, UK South, Central US, and more regions will be supported soon.

We are also introducing the Public Preview for the support of Network Security Perimeter (NSP) in Azure Event Grid topics and domains, for inbound and outbound communication. This perimeter defines a boundary with implicit trust access between each resource, where you can have sets of inbound and outbound access rules. By incorporating these advanced security measures, Azure Event Grid enhances the defense against a wide range of cyber threats, helping organizations to safeguard their event-driven workloads.

In addition to this, Azure Event Grid has introduced message ordering support within single MQTT client sessions, ensuring reliable sequential event delivery, and a connection rate limit of one attempt per second per session, which maintains system stability. Furthermore, the expansion to support up to 15 MQTT topic segments per topic or filter offers greater flexibility in topic hierarchies. High throughput messaging, supporting up to 1,000 messages per second per session, is now in Public Preview, making it ideal for demanding scenarios such as IoT telemetry and real-time analytics.

Azure Event Grid now also offers OAuth 2.0 JWT authentication for MQTT clients in Public Preview. This feature enables secure client authentication via JSON Web Tokens (JWT) issued by OpenID Connect (OIDC) compliant providers, providing a lightweight, secure, and flexible authentication option for clients not provisioned in Azure.

Additionally, Custom Webhook Authentication has been introduced, allowing dynamic client authentication through webhooks or Azure Functions, with Entra ID JWT validation for centralized and customizable strategies.

Finally, Assigned Client Identifiers in Public Preview provide consistent client IDs, improving session management and operational control, further enhancing the scalability and flexibility of client authentication workflows.

We believe these updates will greatly enhance your Azure Event Grid experience. We welcome your feedback and appreciate your ongoing partnership as we work to deliver top features and services.

Announcing the General Availability of Event Hubs Data Explorer

ashish-chhabria — Wed, 04 Dec 2024 19:14:54 GMT

We are excited to announce the general availability of the Event Hubs Data Explorer in the Azure portal!

Ever since our preview announcement in September, we've heard customers rave about how the Event Hubs Data Explorer has already made its way into their daily workflows to onboard, debug and review the data in their Event Hubs with very little effort.

Customer-Centric Design

We listened to your feedback and designed the Event Hubs Data Explorer to address your needs. We've had a lot of customers try this tool and share feedback on how its saving them significant time and effort when it comes to viewing their Event Hubs in action and performing basic debugging tasks.

Simplified Onboarding and Debugging

The Event Hubs Data Explorer is perfect for both new and experienced users. It provides a comprehensive view of event data, making it easy to test event producers and consumers. You can quickly validate your setup with custom workloads or predefined datasets, ensuring everything is configured correctly.

Debugging is now more straightforward than ever. With the ability to inspect data at specific timestamps or offsets, you can quickly identify and resolve issues, optimizing your event processing workflows.

Getting Started

To start using the Event Hubs Data Explorer, navigate to your Event Hubs namespace in the Azure portal. From there, you can access the Data Explorer and begin sending and viewing events with just a few clicks. You can also check out the documentation here.

We are excited to see how you leverage the Event Hubs Data Explorer to drive innovation and efficiency in your projects. Your feedback has been instrumental in shaping this tool, and we look forward to continuing to improve our offerings based on your insights.