TL;DR:
- Azure IoT Operations (AIO) is Microsoft’s new Arc-enabled industrial edge platform, replacing the fragmented Azure IoT Hub/Edge/Stream Analytics stack
- It runs on any Kubernetes cluster at the edge and includes an MQTT broker, OPC UA connector, and a dataflows engine that pipelines data to Microsoft Fabric
- AIO is Microsoft’s answer to unified OT/IT convergence — purpose-built for factories, utilities, and process industries running Industry 4.0 workloads
Microsoft’s industrial IoT story was complicated for years: Azure IoT Hub, Azure IoT Edge, Azure Digital Twins, Azure Stream Analytics, and Azure Data Explorer each solved parts of the problem but required significant integration work. Azure IoT Operations, generally available since late 2025, consolidates this into a single Arc-enabled deployment that runs on Kubernetes at the factory floor.
What Azure IoT Operations Is
AIO is a collection of Kubernetes operators deployed via Arc onto an edge cluster — typically running K3s on an industrial PC or ruggedised server. Once deployed, it gives you:
- MQTT Broker: A Kubernetes-native, horizontally scalable MQTT v5 broker (replaces the IoT Hub MQTT endpoint). Supports QoS 0/1/2, retained messages, shared subscriptions, and TLS with cert rotation.
- Connector for OPC UA: A managed OPC UA client that connects to PLCs, SCADA systems, and process historians that speak OPC UA. It subscribes to OPC UA nodes and publishes data to MQTT topics without requiring custom code.
- Dataflows: A pipeline engine that reads from MQTT topics, transforms data (schema mapping, enrichment, filtering), and routes it to destinations — Azure Event Hubs, Microsoft Fabric, MQTT output, or local storage.
- Asset management: A Kubernetes CRD (custom resource definition) layer for modelling industrial assets — a pump, a conveyor, a boiler — with their associated OPC UA nodes, metadata, and thresholds. Assets are defined in YAML or through the Azure portal.
- Operations Experience UI: A browser-based observability interface for monitoring MQTT broker health, dataflow pipeline status, and asset connectivity.
The Arc Architecture
AIO’s dependency on Azure Arc is its defining architectural characteristic. Arc treats your edge Kubernetes cluster as a resource in Azure Resource Manager — giving you Azure RBAC, policy, GitOps (Flux), and Azure Monitor integration regardless of where the cluster physically runs.
This means:
- Deploy and configure AIO components using standard ARM templates or Bicep
- Manage firmware updates and configuration drift using Arc’s GitOps integration
- Route telemetry directly from the edge cluster to Azure without a separate gateway VM
The trade-off is that AIO requires internet connectivity to the Arc control plane for management operations (telemetry and MQTT brokering work offline, but configuration changes and monitoring require Arc connectivity).
Setting Up a Minimal Installation
AIO requires a Kubernetes cluster with Arc enabled. On an industrial PC running Ubuntu 22.04:
# Install K3s
curl -sfL https://get.k3s.io | sh -
# Connect to Arc
az connectedk8s connect --name my-factory-edge --resource-group my-rg
# Deploy AIO
az iot ops init --cluster my-factory-edge --resource-group my-rg
az iot ops create --cluster my-factory-edge --resource-group my-rg \
--name my-aio-instance \
--sr-resource-id /subscriptions/.../schemaRegistries/my-registry
From there, you add connectors, configure OPC UA endpoints, and define dataflows through the Azure portal or YAML manifests applied via GitOps.
Connecting to OPC UA Devices
The OPC UA connector is the most immediately useful component for brownfield industrial deployments. Modern PLCs from Siemens (S7-1500), Rockwell, Beckhoff, and Mitsubishi all expose OPC UA endpoints. Rather than writing custom gateway code for each, AIO’s connector handles discovery and subscription:
apiVersion: connectivity.iotoperations.azure.com/v1
kind: OpcUaConnector
metadata:
name: line-1-plc
spec:
opcUaServerSettings:
url: opc.tcp://192.168.1.50:4840
opcUaBrowseAndPublishWorkers:
- nodeId: ns=2;s=Temperature
publishingInterval: PT1S
- nodeId: ns=2;s=Pressure
publishingInterval: PT1S
mqttOutputTopic: factory/line-1/telemetry
Data from Temperature and Pressure nodes gets published to the specified MQTT topic every second, automatically.
Dataflows to Microsoft Fabric
AIO’s native integration with Microsoft Fabric (via Event Streams and OneLake) is the path for getting edge telemetry into analytics. A dataflow can filter, normalize, and schema-map data at the edge before it reaches the cloud — reducing egress costs and cloud storage requirements:
kind: Dataflow
spec:
sources:
- mqttSource:
topic: factory/+/telemetry
operations:
- filter:
expression: temperature > 80 OR pressure > 150
- schemaMap:
schemaRef: telemetry-schema-v2
destinations:
- fabricDestination:
workspaceId: ...
eventstreamId: ...
Only events exceeding thresholds reach Fabric, with the field names mapped to the schema the analytics team expects.
When to Choose AIO vs Alternatives
AIO makes sense if:
- You’re running a Microsoft-stack environment (Azure, Teams, Fabric, Power BI for operations dashboards)
- You need OPC UA connectivity to brownfield equipment without writing gateway code
- You have IT/OT teams that want a unified Arc governance model across cloud and edge
For environments with existing AWS Greengrass deployments, or where Kafka-based streaming (Azure Event Hubs on the edge is not Kafka-native), AWS IoT Greengrass or a self-managed K3s + EMQX stack may be a better fit.
The major gap in AIO 1.0 is limited support for industrial protocols beyond OPC UA — Modbus, DNP3, and PROFINET require custom connector development or third-party adapters. Microsoft has signalled roadmap additions here, but they’re not yet available in the GA release.
For greenfield Industry 4.0 deployments where OPC UA is the standard and Microsoft Fabric is the analytics target, AIO is the most complete out-of-the-box option in the market.