Today, Microsoft Fabric Eventstream supports destinations such as Activator, Custom Endpoint (HTTP), Eventhouse, Lakehouse and Stream. There is no native option to send Eventstream output directly to Azure Event Hubs (or other AMQP / Kafka‐compatible event systems). Adding Azure Event Hubs as a built‐in destination would enable: Real-time high-throughput output from Eventstream into existing event pipelines. Native integration with external consumers, microservices or other event hubs without custom workarounds. Reduced latency and operational complexity by eliminating intermediate lakes/sinks or custom forwarding functions. Better alignment with enterprise event-driven architectures already using Azure Event Hubs. Use cases: IoT event ingestion in Fabric → publish to Event Hubs and downstream microservices. Fabric as streaming ingest & routing layer, then external analytics/stream-processing via Event Hubs. Multi-tenant or cross-subscription event forwarding where downstream systems expect Event Hubs. Benefits: Streamlines architecture; fewer moving parts. Reduces cost and latency of custom forwarding. Enables broader adoption of Eventstream in enterprise environments with existing Azure event infrastructure. Suggested implementation details: Provide “Azure Event Hubs” as a destination option in Eventstream UI. Support authentication via managed identity, service principal (Azure AD), or SAS-token. Allow specifying namespace, Event Hub name, partition key / properties. Surface throughput/capacity guidance in UI to help users size appropriately. Provide monitoring/metrics for Event Hub output (e.g., successful sends, failed sends, retry counts). Priority for our organization: High. As a Platform Solution Architect working with Microsoft Fabric, I see many scenarios where we need to send events to external systems via Azure Event Hubs—but without native support we have to build custom complexity. ... View more