Messaging on Azure Blog articles

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.

Introducing Kafka Support in Event Hubs emulator

Sannidhya_Glodha — Tue, 19 Nov 2024 18:16:51 GMT

Azure Event Hubs is a cloud-native data streaming service that streams millions of events per second with low latency, from any source to any destination. Compatible with Apache Kafka®, it allows you to run existing Kafka workloads without code changes.

Earlier this year, we released the Event Hubs emulator for local development, which initially only supported AMQP protocol. We are now excited to announce Apache Kafka® protocol support in the Event Hubs emulator.

Why emulator?

Developers across the globe love emulators! While there are numerous compelling reasons to use emulators, here are just a few of those reasons to consider:

Optimized Development Loop: The emulator speeds up dev/testing against Azure Event Hubs.
Pre-migration Trial: Try Azure Event Hubs for Apache Kafka® using your existing Kafka applications before migrating to the cloud.
Isolated Environment: Use the emulator for dev/test setup without network latency or cloud resource constraints.
Cost-efficient: The emulator is free and can be run on your local machine for dev/testing.

Note: The emulator is intended only for development and testing. It should not be used for production workloads. Official support is not provided, and any issues or suggestions should be reported via GitHub.

Kickstart development with Event Hubs emulator

The emulator is available as a Docker image on Microsoft Artifact Registry and is platform-agnostic – it can run on Windows, macOS, and Linux. You can either use our automated scripts from the Installer repository or spin up the emulator container using the docker compose command.

The producer and consumer APIs are currently compatible with the emulator. Additional API support will be provided in future incremental versions.

To test Apache Kafka® applications locally with the Event Hubs emulator, visit aka.ms/devtestwithehemulator.

Learn more about Event Hubs:

Azure Event Hubs: Data streaming platform with Kafka support - Azure Event Hubs | Microsoft Learn

Introduction to Apache Kafka® in Event Hubs on Azure Cloud - Azure Event Hubs | Microsoft Learn

We appreciate your feedback and encourage you to share it with us. Please provide feedback or report any issues at our GitHub repository: Issues · Azure/azure-event-hubs-emulator-installer

May the Event Hubs emulator light up your test cases in green! 😊

Introducing Local emulator for Azure Service Bus

Sannidhya_Glodha — Tue, 19 Nov 2024 18:15:40 GMT

Azure Service Bus is a fully managed enterprise message broker offering queues and publish-subscribe topics. It decouples applications and services, providing benefits like load-balancing across workers, safe data and control routing, and reliable transactional coordination.

In response to your feedback, we are pleased to announce the introduction of a local emulator for Azure Service Bus. This emulator is intended to facilitate local development experience for Service Bus, allowing developers to develop and test their code against Azure Service Bus, in isolation away from cloud interference.

Why emulator?

Developers across the globe love emulators! While there are numerous compelling reasons to use emulators, here are just a few of those reasons to consider:

Optimized development loop: The emulator speeds up dev/testing against Azure Service Bus.
Pre-migration trial: Try Azure Service Bus using your existing AMQP applications before migrating to the cloud.
Isolated environment: Use the emulator for dev/test setup without network latency or cloud resource constraints.
Cost-efficient: The emulator is free and can be run on your local machine for dev/test scenarios.

Note: The emulator is intended only for development and testing. It should not be used for production workloads. Official support is not provided, and any issues or suggestions should be reported via GitHub.

Get started with Service Bus emulator

The emulator is accessible as a Docker image on Microsoft Artifact Registry, and it is platform-independent, capable of running on Windows, macOS, and Linux. You can use our automated scripts from the Installer repository or initiate the emulator container using the docker compose command.

The emulator is compatible with the latest service bus client SDKs and supports a wide variety of features within Azure Service Bus. For more details, please visit aka.ms/servicebusemulator

Announcing new features and updates in Azure Event Grid

robece — Tue, 19 Nov 2024 14:45:30 GMT

We are excited to share several new updates and features in Azure Event Grid that enhance our service's capabilities and improve your experience. In this article, you will find more information about the General Availability of Webhook Endpoints, and custom domain names in Azure Event Grid, as well as the introduction of new Public Previews like the cross-tenant delivery, and namespace topic to namespace topic forwarding support. Azure Event Grid is a highly integrated event broker designed to simplify the development of event-driven applications. It features pub-sub scenarios with a rich variety of event sources and handlers, including first-party and third-party integrations. Its flexible design supports multi-protocol interoperability, push and pull delivery, as well as MQTT, allowing for diverse message consumption patterns.

Below, we detail the latest additions and improvements now available.

We are pleased to announce General Availability of the webhook endpoints in Azure Event Grid namespace topics. This feature allows for efficient and reliable push delivery to webhooks, expanding the possibilities for event-driven architectures and integrations.

We are also excited to announce that custom domain names support is now Generally Available in Azure Event Grid’s MQTT broker. This new feature allows you to assign your own domain names to the MQTT and HTTP endpoints within your Azure Event Grid namespaces. By doing so, you can enhance security and simplify client configuration. Additionally, assigning custom domain names to namespaces can help improve availability, manage capacity, and facilitate cross-region client mobility.

We are also excited to announce the General Availability of Microsoft Graph API events that provide notifications about state changes of resources in Microsoft Outlook, Teams, SharePoint, Microsoft Entra ID, Microsoft Conversations, and security alerts.

In Public Preview, we are introducing support for cross-tenant delivery to Event Hubs, Service Bus, and Storage Queues using managed identity with federated identity credentials (FIC) in Azure Event Grid topics, domains, system topics and partner topics. This enhancement enables secure and efficient cross-tenant communication for basic resources.

Lastly, we are launching the Public Preview for namespace topic to namespace topic forwarding, enabling seamless event forwarding between topics hosted in the same or different namespaces, simplifying the event routing and management.

We are confident that these updates will provide significant benefits and improvements to your Azure Event Grid experience. We look forward to your feedback and continued partnership as we strive to deliver the best possible features and services.

Bridging Connectivity: Exploring Azure Relay Bridge (azbridge)

msft-samuel — Thu, 14 Nov 2024 21:57:53 GMT

Introduction to Secure Remote Access with Azure Relay and Azbridge

In modern IT environments, securely accessing on-premises resources from remote locations is a common challenge. Traditional methods, such as setting up VPNs, often require complex configurations and can introduce significant overhead. For organizations seeking a more streamlined solution, Azure Relay, combined with the open-source tool Azure Relay Bridge (azbridge), offers an efficient way to establish secure, direct connections without the need for VPNs.

Azbridge leverages Azure Relay to create TCP, UDP, HTTP, and Unix Socket tunnels, enabling secure traversal through NATs and firewalls using only outbound HTTPS (443) connectivity. This makes it ideal for connecting remote clients to on-premises resources, such as Remote Desktop Protocol (RDP) sessions, without exposing them to the public internet.

While Azure Relay is fully supported by Microsoft, it’s important to note that azbridge is an open-source tool and is not covered by Microsoft support. Users can seek assistance for Azure Relay, but azbridge-specific issues should be reported directly on its repository, where response times may vary.

In this guide, we’ll walk through the setup process for using azbridge with Azure Relay to create an RDP connection. You’ll learn how to configure a Hybrid Connection in Azure, customize client and server configuration files, and run azbridge as a service across different operating systems.

Example Use Case for AZBridge

Azbridge enables secure Remote Desktop Protocol (RDP) connections by allowing users to expose a network-isolated socket that can be accessed from an entirely separate network. This approach provides secure, remote access to on-premises resources—such as RDP, databases, or web servers—without the complexity of setting up a VPN, making it ideal for users needing isolated, controlled access across network boundaries. Using Azure Relay, azbridge creates direct tunnels that bypass NATs and firewalls without requiring extensive network configuration. This setup not only simplifies access but also enhances security by enabling RDP connections without exposing sessions to the public internet, thereby reducing potential risks.

In many situations, users need access to specific resource endpoints rather than an entire network. Azbridge is especially valuable in scenarios such as accessing billing databases in franchise locations, integrating with secure test systems, or making web service calls to protected applications. By leveraging Azure Relay, azbridge provides a controlled way to reach exactly the endpoint you need without exposing the entire network that it is in.

Additionally, azbridge is a cost-effective solution, avoiding traditional VPN licensing fees and charging only for active Azure Relay connections. Because it relies on outbound HTTPS (443), azbridge works seamlessly across restrictive networks, allowing connections without additional firewall adjustments. For developers and IT admins, azbridge provides quick, secure access to on-premises machines from any location, serving as a fast, flexible alternative to traditional VPNs for endpoint-specific connectivity.

The diagram above demonstrates how azbridge enables a secure Remote Desktop Protocol (RDP) connection across network boundaries using Azure Relay. In this setup, On-Premises Network A contains the client machine, where azbridge (labeled as "Relay Bridge") is installed. This client is seeking to establish an RDP connection to a remote machine located in a different network, On-Premises Network B.

Azure Relay acts as a secure intermediary between the two networks, facilitating the connection without exposing either network to the public internet. By creating a direct tunnel that bypasses NATs and firewalls, Azure Relay allows the client in Network A to communicate with the endpoint in Network B safely. On-Premises Network B contains the target machine with azbridge installed, which is also labeled as "Relay Bridge." This machine hosts the specific endpoint (such as an RDP server) that the client in Network A is trying to access.

Through this configuration, azbridge in Network A connects via Azure Relay to reach the endpoint in Network B without requiring a VPN. Only the designated RDP endpoint is exposed to the connection, while the rest of Network B remains isolated and secure. This approach provides a secure, controlled RDP connection across networks, allowing remote access to on-premises resources without exposing the entire network.

Prerequisites and Initial Setup

To get started, you will first need to set up an Azure Relay Hybrid Connection the basic instructions for doing so are provided below. Presuming you have already gained the Entra id login credentials for Azure, set up some environment variables in your environment:

export NAMESPACE=<your_namespace_name> # e.g., mynamespacename export LOCATION=<location_name> # e.g., eastus2 export RELAYNAME=<your_relay_name> # e.g., azbridge

Next, use the specified namespace and location to create a resource group:

az group create --name $NAMESPACE --location $LOCATION

In your resource group, create an azure relay namespace for this example the resource group and the azure relay namespace are identically named:

az relay namespace create -g $NAMESPACE --name $NAMESPACE

Create a new Hybrid Connection in your Azure Relay namespace:

az relay hyco create -g $NAMESPACE --namespace-name $NAMESPACE --name $RELAYNAME

Create an authorization rule with your Hybrid Connection, allow send and listen permissions on the authorization rule:

az relay hyco authorization-rule create -g $NAMESPACE --namespace-name $NAMESPACE --hybrid-connection-name $RELAYNAME -n sendlisten --rights Send Listen

Retrieve the primaryConnectionString for the authorization rule generated. This will be needed for the azbridge configuration files:

az relay hyco authorization-rule keys list -g $NAMESPACE --namespace-name $NAMESPACE -n sendlisten --hybrid-connection-name $RELAYNAME --out tsv --query "primaryConnectionString"

Setting Up RDP with Azure Relay and Azbridge

For this example, we’ll be using the Windows operating system. Install the MSI package on both your client machine and the remote RDP machine. You can download the MSI package for installation from Azure Relay Bridge Releases on GitHub

Client Machine Configuration

On the client machine, generate a client_config.yaml file with the following contents:

LocalForward : - BindAddress: 127.1.0.2 BindPort: 13389 PortName: rdp RelayName: <<RELAYNAME>> ConnectionString: <<primaryConnectionString>> LogLevel: INFO

Bind Address: Source address of outbound, forwarding connections, in this example, 127.1.0.2 is used to create a local endpoint on the client machine without affecting 127.0.0.1

BindPort: TCP port mapped to the hybrid connection 13389 is used in this case because Windows does not allow listening on port 3389 on any address.

PortName: Primarily used for internal configuration within azbridge to label and map the local and remote ports consistently. This label helps identify the specific purpose of each connection.

RelayName: Hybrid Connection on Azure Relay that will be used for this connection

ConnectionString: primaryConnectionString created for the Azure Relay Hybrid Connection with Send and Listen permissions.

To start the client connection, open up a command prompt and specify the client_config.yml file that was generated.

azbridge -f client_config.yml

Remote RDP Machine Configuration

On the rdp machine, generate a server_config.yml file with the following contents:

RemoteForward : - RelayName: <<RELAYNAME>> Host: localhost PortName: rdp HostPort: 3389 ConnectionString: <<primaryConnectionString>> LogLevel: INFO

Similar to the Client setup, only this file sets up a remote forwarder that binds the hybrid connection with logical port "rdp" to the Windows RDP endpoint on "localhost", port 3389.

To start the local RDP connection, open up a command prompt and specify the server_config.yml file that was generated.

azbridge -f server_config.yml

Connect via RDP

On your client machine, open up a Remote Desktop Connection to your Remote RDP host. For this connection, you will use the 127.1.0.2:13389 specified in your client_config.yml:

Announcing the Event Hubs Data Explorer: a handy tool for getting started and debugging

ashish-chhabria — Tue, 19 Nov 2024 14:46:24 GMT

We are excited to announce the preview launch of the new Event Hubs Data Explorer feature in the Azure portal! This user-friendly yet highly powerful tool allows developers to generate and retrieve event data from an Event Hubs topic, all within the ease of the Azure portal.

Seamless Onboarding

The Data Explorer is a vital tool for new Event Hubs developers, offering an all-encompassing view of event data for quick onboarding. It lets you test event producers and consumers easily, ensuring your systems are correctly configured. Developers have the option to either create custom workloads or utilize predefined datasets to produce mock data for streamlined testing.

Whether you're experimenting with new data flows or validating your setup, the Data Explorer makes the process straightforward.

Enhanced Debugging

If you're using Event Hubs, the Data Explorer is invaluable for debugging and improving your solutions. It allows you to inspect data at specific timestamps or offsets, helping developers quickly find and fix anomalies. This tool is great for identifying issues and optimizing event processing workflows to keep your systems running smoothly.

Your Gateway to Advanced Event Data Insights

The Event Hubs Data Explorer is designed to make your experience with Event Hubs more intuitive and productive. By providing a unified interface for producing and consuming event data, it empowers you to gain deeper insights and maintain control over your event-driven architectures. We are confident that this new feature will enhance your ability to work with Event Hubs, whether you are just getting started or optimizing existing deployments.

For a detailed guide on using the Event Hubs Data Explorer, please refer to our comprehensive how-to documentation.

We are excited to see how you leverage the Event Hubs Data Explorer to drive innovation and efficiency in your projects. As always, we welcome your feedback and look forward to continuously improving our tools to better serve your needs.

Stay tuned for more updates and happy exploring!

Service Bus Premium SKU Performance Update

EldertGrootenboer — Tue, 03 Sep 2024 16:00:00 GMT

In 2016 we announced the general availability of Service Bus Premium, which offers dedicated resources and consistent performance for mission-critical workloads. At this point we also published a blogpost that showed the results of the performance benchmarks we ran on this SKU.

Since then, we have made a variety of improvements to Service Bus Premium, providing even better performance for our customers’ workloads. In this blogpost, we will revisit the performance benchmarks from 2016 and compare them with the current performance of Service Bus Premium in 2024.

Methodology

We ran this benchmark in the same configuration as for the previous blogpost. We used a performance benchmark tool, which can be found on GitHub. The benchmark tool was run on D48 VMs located in the same region as the namespace.

The benchmarks tested three scenarios: a single queue, a single topic with a single subscription, and a single topic with five subscriptions. The tests used 1, 2, and 4 messaging units (MU), which are the units of scale and performance in the premium SKU. Furthermore, the tests used 1 KB message size, the AMQP protocol, and implemented batching.

For each test we measured the average throughput (messages per second) for our send and receive operations.

Results

Below are the results for the send and receive operations, and how these compare to those found in 2016. This indicates the number of messages that came through Service Bus per second, so higher numbers mean better performance.

Send

Below are the numbers for each of these tests, and the improvement in percentages compared to the same tests in 2016.

		# of MUs				Improvement % from 2016 to 2024
Entity Type	Year		1MU	2MU	4MU	1MU	2MU	4MU
Queue	2016		4401	9070	16782	54%	41%	49%
	2024		6790	12770	25000
1 Subscription	2016		2223	4499	8960	125%	129%	47%
	2024		5000	10300	13200
5 Subscriptions	2016		1348	1676	3844	19%	85%	14%
	2024		1600	3100	4400

Receive

Below are the numbers for each of these tests, and the improvement in percentages compared to the same tests in 2016.

		# of MUs				Improvement % from 2016 to 2024
Entity Type	Year		1MU	2MU	4MU	1MU	2MU	3MU
Queue	2016		4401	9069	16782	54%	41%	49%
	2024		6790	12770	25000
1 Subscription	2016		2220	4493	8956	125%	129%	47%
	2024		5000	10300	13200
5 Subscriptions	2016		2994	8331	19202	167%	84%	15%
	2024		8000	15300	22000

Conclusion

These results show that there has been a significant performance improvement since we first introduced Service Bus Premium, with an average increase of ~50%, and even over 150% for some scenarios. Of course, we are going to continue improving our service, where performance is always on top of mind.

Messaging on Azure Blog articles

Announcing general availability of Network Security Perimeter for Azure Service Bus

How Network Security Perimeter fits with existing network security

Concepts

Access rules

Supported scenarios

Getting started

Powering Event Driven Payments with Stripe and Azure Event Grid

Introduction

Stripe events meet Azure Event Grid

Extending Stripe events into Fabric Real-Time Intelligence

Common use cases enabled by Stripe events on Azure

Getting started

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

Your Code, Our Infrastructure

Choosing the Right Tier for Your Journey

The Hub of the Modern Data Stack

The Bottom Line

Ready to Migrate?

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

The Enterprise MQTT Brokerfor Every Connected Ecosystem

📡 Full MQTT Protocol Coverage

🔒 Enterprise Authentication Stack

⚡ Built for Massive Scale

🔀 MQTT Events, Everywhere in Azure

💡 Last Will & Testament + Retained Messages

🏭 Sparkplug B on Azure — Smart Factory, Unlocked

📊 Deep Metrics for Every Deployment

🌍 Built for Every Connected Industry

🔭 Coming Soon to Preview

Ready to Connect Everything?

Introducing Administration Client Support for the Azure Service Bus Emulator

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

Differentiation

Concepts

Replication modes

Asynchronous replication

Synchronous replication

Promotion

Pricing

JSON Structure: A JSON schema language you'll love

What Is JSON Structure?

Why Does This Matter for Messaging?

SDKs Available Now

Code and Schema Generation with Structurize

Learn More

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

Why agentic AI backends need enterprise messaging

A callback to the past

Why Azure Service Bus stands out

Patterns for the future

Scatter / Gather

Request / Proposal / Refinement

Saga-like coordination

Backpressure and load shaping

Closing thoughts

General Availability: Large Message Support in Azure Event Hubs

Upcoming Changes to Azure Relay IP Addresses and DNS Support

What’s Changing?

Recommended Actions for Customers

Automating Namespace Information Retrieval

Sample output

What’s New in Azure Event Grid

General Availability Features

Public Preview Features

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

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

Learn more

Announcing new features and updates in Azure Event Grid

Announcing the General Availability of Event Hubs Data Explorer

Customer-Centric Design

Simplified Onboarding and Debugging

Getting Started

Introducing Kafka Support in Event Hubs emulator

Why emulator?

Note: The emulator is intended only for development and testing. It should not be used for production workloads. Official support is not provided, and any issues or suggestions should be reported via GitHub.

Kickstart development with Event Hubs emulator

Introducing Local emulator for Azure Service Bus

Why emulator?

Note: The emulator is intended only for development and testing. It should not be used for production workloads. Official support is not provided, and any issues or suggestions should be reported via GitHub.

The Enterprise MQTT Broker
for Every Connected Ecosystem