21.06.2026
24.6.2026
24.6.2026
Welche Azure-IoT-Lösung passt zu welchem Szenario? Der Beitrag vergleicht IoT Hub, IoT Edge und Azure IoT Operations und zeigt, warum OT-nahe Datenflüsse für Physical AI und moderne Produktionsumgebungen immer wichtiger werden.
Azure bietet mit IoT Hub, IoT Edge und Azure IoT Operations verschiedene Wege, um Geräte, Maschinen und Produktionsdaten mit der Cloud zu verbinden. Doch je nach Szenario unterscheiden sich Architektur, Datenmodell, Integrationsaufwand und KI-Potenzial deutlich. In diesem Beitrag vergleichen wir die Ansätze aus Sicht von Data Management, OT-/Cloud-Integration, Security und industrieller KI. So bekommst Du eine praktische Orientierung, wann IoT Hub und IoT Edge ausreichen und wann Azure IoT Operations die bessere Grundlage für skalierbare Produktions- und KI-Szenarien bietet.
Azure IoT umfasst eine modulare Plattform aus gemanagten Cloud-Services, Edge-Lösungen und programmatischen Werkzeugen, um die physische Welt effizient mit der Cloud zu verbinden. Die Auswahl der passenden Komponenten ist dabei immer stark vom konkreten Nutzungsszenario abhängig – und genau das stellt Unternehmen häufig vor die Herausforderung, das richtige Architekturdesign zu wählen.
Grundsätzlich lassen sich zwei Designprinzipien unterscheiden: Cloud-basierte IoT-Lösungen und Edge-basierte IoT-Lösungen. Bei Cloud-basierten Ansätzen senden vernetzte Geräte ihre Daten direkt in die Cloud, wo sie verarbeitet und analysiert werden. Ein Beispiel dafür ist Azure IoT Hub.
Bei Edge-basierten Ansätzen werden Daten zunächst lokal verarbeitet, gefiltert oder angereichert und dann an die Cloud weitergegeben. Für diesen Ansatz ist Azure IoT Operations ausgelegt.
Dazwischen liegen hybride Architekturen, die Cloud- und Edge-Komponenten kombinieren. Ein etablierter Ansatz ist die Kombination aus Azure IoT Hub und Azure IoT Edge: Die Cloud bleibt Steuerungs- und Integrationszentrum, während Edge-Geräte lokal Daten vorverarbeiten.
Dieser Unterscheidung folgend bildet der IoT Hub die zentrale Komponente eines Cloud-basierten IoT-Ansatzes. Er dient als zentraler Kommunikationshub und ermöglicht eine sichere, skalierbare und bidirektionale Kommunikation zwischen Edge-Geräten und der Cloud. Über ihn lassen sich Geräte aus der Cloud heraus bereitstellen, konfigurieren und verwalten. Darüber hinaus lässt sich der IoT Hub nativ mit Azure-Diensten wie Stream Analytics oder Event Hubs verbinden, um die gesammelten Daten weiterzuverarbeiten. Als eigenständige Lösung bietet der IoT Hub allerdings keine Möglichkeit, Daten direkt auf dem Edge-Gerät selbst zu verarbeiten.
Aus Datenmanagement-Sicht verfolgt dieser Ansatz einen klar gerätezentrierten Fokus. Gerätezustände, Properties oder Firmware-Level werden über Device Twins verwaltet. Typischerweise senden Geräte Telemetriedaten an den IoT Hub, von wo aus diese in Event Hubs, Blob Storage oder nachgelagerte Analytics-Dienste weitergeleitet werden.
Mit der Integration von Azure IoT Hub in die Azure Device Registry (ADR) wird dieser gerätezentrierte Ansatz zukünftig stärker in die allgemeine Azure-Management-Ebene eingebettet. IoT-Hub-Geräte können dadurch als Azure-Ressourcen repräsentiert und über den Azure Resource Manager verwaltet werden. Das ist insbesondere für größere IoT-Flotten relevant, da Geräte nicht mehr ausschließlich innerhalb einzelner IoT Hubs betrachtet werden, sondern übergreifend in einer zentralen Registry sichtbar und verwaltbar werden.
IoT Edge fungiert häufig als Ergänzung des IoT Hubs in der Fabrik. Im Kern ist es eine Edge-Runtime, die es ermöglicht, Daten direkt dort zu verarbeiten, wo sie entstehen. Technisch besteht die Runtime aus zwei zentralen Modulen: dem Edge Agent, der die Orchestrierung und Konfiguration containerisierter Workloads steuert, und dem Edge Hub, der als lokaler Broker für die Kommunikation zwischen Modulen und der Cloud dient.
Zusätzlich lassen sich bestehender Code in Form von Docker-Images oder bereits als Module bereitgestellte Azure-Services wie Machine Learning oder Stream Analytics als standardisierte Container auf dem Edge-Gerät ausrollen. Dadurch können Daten lokal verarbeitet oder gefiltert an die Cloud weitergeleitet werden. Auch Offline-Szenarien lassen sich abbilden, indem Daten lokal zwischengespeichert werden.
Bei IoT Hub und IoT Edge steht die Cloud-Integration stark im Vordergrund. Der IoT Hub bietet standardmäßig Routing in verschiedene Azure-Dienste, darunter:
Dadurch eignet sich der IoT Hub besonders gut für Szenarien, in denen Telemetriedaten schnell und skalierbar in bestehende Azure Data- und Analytics-Stacks gebracht werden sollen.
Auf der Edge-Seite ist IoT Edge sehr schnittstellenoffen. Die native Unterstützung industrieller Protokolle ist jedoch begrenzt. Für die Anbindung industrieller Systeme werden häufig Partner-Module oder eigene Container genutzt, beispielsweise für:
Der Vorteil dieses Ansatzes:
Die Flexibilität: Im Prinzip kann jeder Docker-Container als IoT-Edge-Modul eingebunden werden. Dadurch lassen sich bestehende Anwendungen, Protokollkonnektoren oder kundenspezifische Businesslogiken frei auf dem Edge-Gerät betreiben.
Der Nachteil dieses Ansatzes:
Die Heterogenität des Ökosystems. Konfiguration, Monitoring, Updates und Betrieb einzelner Module liegen teilweise außerhalb des eigentlichen Azure-Kerns und müssen individuell gelöst werden. In OT- Landschaften mit vielen Maschinen, Protokollen und Sicherheitszonen kann das schnell anspruchsvoll werden. Zusätzlich erfordert dieser Ansatz Erfahrung im Programmieren von Container-Apps, was nicht nur den Self-Service für die Fachbereiche komplexer, sondern auch die Abhängigkeit der OT von der IT größer macht.
Im Gegensatz dazu steht Azure IoT Operations als klar Edge-zentrierte IoT-Lösung. Während beim IoT Hub vor allem einzelne Geräte und deren Anbindung an die Cloud im Vordergrund stehen, betrachtet Azure IoT Operations die gesamte Produktions- und OT-Umgebung als zusammenhängendes Edge-Cluster. Technische Grundlage sind Arc-enabled Kubernetes-Cluster, die als vollumfängliche, modulare Edge-Plattform dienen.
Statt einer monolithischen Runtime setzt Azure IoT Operations auf containerisierte, Cloud-native Services, die gemeinsam eine umfassende IoT-Architektur bilden. Zu den zentralen Komponenten gehören:
Aus Datenmanagement-Perspektive ist Azure IoT Operations deutlich stärker datenfluss- und prozessorientiert ausgerichtet als IoT-Hub-basierte Ansätze. Daten werden primär als Streams verstanden, die aus OT-Quellen wie Steuerungen, OPC-UA-Servern oder Maschinen stammen. Sie laufen über interne Verarbeitungsstufen und werden schließlich in IT- oder Cloud-Ziele wie Data Lakes, Event-Streaming-Plattformen oder Analytics-Umgebungen geschrieben.
Typischerweise werden diese Daten als Zeitreihen im Kontext von Assets betrachtet. Die Konfiguration von Datenpipelines erfolgt daher nicht nur auf der Ebene einzelner Geräte, sondern auf der Ebene von Tags und Signalen.
Ein weiterer Schwerpunkt liegt auf Edge-seitiger Datenhaltung und Resilienz. Events können lokal gepuffert und bei Wiederverbindung in Richtung Cloud erneut gesendet werden. Dadurch lassen sich Datenlücken bei temporärer Unterbrechung der Cloud-Verbindung vermeiden. Gerade in Produktionsumgebungen ist dieses Verhalten entscheidend, da Verfügbarkeit, Datenvollständigkeit und stabile Verarbeitungsketten hohe Priorität haben.
Auf der OT-Seite legt Azure IoT Operations besonderen Wert auf eine einfache Integration industrieller Systeme. Im Fokus stehen OPC UA und andere gängige Industrieprotokolle.
Der Unterschied zu IoT Edge liegt darin, dass diese Konnektoren bereits als Bestandteil des offiziellen Plattform-Stacks verfügbar sind. Es geht weniger um „Bring your own Container”, sondern vielmehr um kuratierte, robuste und produktnah integrierte OT-Konnektoren.
In Richtung IT und Cloud lassen sich Datenströme aus IoT Operations gezielt integrieren in:
Das Ziel besteht darin, OT- und IT-Welt sauber zu verbinden. OT-Daten sollen zuverlässig und strukturiert in IT-Systeme gelangen, ohne dabei OT-Sicherheitszonen, Latenzanforderungen oder Verfügbarkeitsanforderungen zu verletzen.
In vielen Industrien wird deutlich: Der größte Mehrwert entsteht dort, wo KI auf die physische Welt trifft. Während klassische IoT‑Szenarien Edge‑Geräte vor allem zum Sammeln und Weiterleiten von Daten in die Cloud nutzen, erfordern KI‑ und ML‑Anwendungen eine schnellere Verarbeitung direkt vor Ort. Gerade in Produktionsumgebungen können Millisekunden entscheidend sein. Deshalb werden KI‑Modelle zunehmend auf Edge‑Systemen ausgeführt – dort, wo die Daten entstehen. So lassen sich Latenzen reduzieren, Echtzeitentscheidungen treffen und Prozesse auch bei unterbrochener Cloud‑Verbindung weiter überwachen oder steuern.
Auch mit Azure IoT Hub und IoT Edge lassen sich solche KI‑Szenarien umsetzen. Ein typisches Muster besteht darin, ein ML‑Modell zunächst in der Cloud zu trainieren, anschließend als Docker‑Container zu paketieren und über den IoT Hub als IoT‑Edge‑Modul auf ein Edge‑Gerät auszurollen. Dort kann das Modell lokal Inferenz ausführen, etwa Anomalien in Sensordaten erkennen oder Ereignisse klassifizieren. Der Vorteil dieses Ansatzes liegt in seiner Flexibilität: Bestehende Modelle, eigener Code oder spezialisierte Analysekomponenten können als Container betrieben werden, während der IoT Hub weiterhin als zentrales Steuerungs‑ und Deployment‑System dient.
Gleichzeitig ist dieser Ansatz meist stärker auf Inferenz als auf Modell-Training ausgelegt. Die Modelle werden in der Regel in der Cloud trainiert und anschließend an die Edge verteilt. Aufgrund begrenzter Ressourcen vieler Edge‑Geräte eignen sich vor allem kleinere oder optimierte Modelle. Umfangreiches Daten‑Enrichment, komplexe Kontextualisierung oder Modelltraining direkt an der Edge sind zwar möglich, aber typischerweise nicht der Hauptanwendungsfall. Damit eignet sich IoT Hub + IoT Edge besonders für gerätezentrierte KI‑Szenarien wie Remote Monitoring oder lokale ML‑Inferenz nahe am Gerät.
Für umfassendere industrielle KI‑Szenarien bietet Azure IoT Operations jedoch eine stärkere Grundlage. Mit dem neuesten Release von Azure IoT Operations 2603 positioniert Microsoft die Plattform zunehmend als Basis für sogenannte Physical AI – also KI‑Systeme, die nicht nur digitale Daten analysieren, sondern physische Prozesse in Produktion, Anlagenbetrieb und OT‑Umgebungen verstehen und beeinflussen können.
Der entscheidende Punkt dabei ist: KI in der Produktion beginnt nicht beim Modell, sondern bei der Datenbasis. Produktionsdaten müssen zuverlässig aus Maschinen, Steuerungen und Sensoren erfasst, zeitlich korrekt verarbeitet, mit Asset‑ und Prozesskontext angereichert und anschließend in Cloud‑, Analytics‑ oder KI‑Plattformen bereitgestellt werden. Genau diese Rolle übernimmt Azure IoT Operations als Operational Data Layer zwischen OT und IT.
Durch native OT‑Konnektoren, Dataflows, MQTT‑Kommunikation, Edge‑seitige Verarbeitung und die Integration in Azure Arc macht IoT Operations industrielle Daten sowohl lokal als auch Cloud-seitig KI‑fähig. Daten können nahe an der Maschine verarbeitet und gleichzeitig in zentrale Plattformen wie Event Hubs, Azure Data Explorer, Data Lake oder Microsoft Fabric überführt werden. Damit entsteht eine durchgängige Architektur für industrielle KI‑Anwendungsfälle wie Predictive Maintenance, Condition Monitoring, Qualitätsprognosen oder industrielle Copilots.
Im Vergleich zu IoT Hub und IoT Edge verschiebt sich der Fokus damit deutlich: Während IoT Hub und IoT Edge vor allem gerätezentrierte Telemetrie‑ und Edge‑Workload‑Szenarien abbilden, adressiert Azure IoT Operations ganze Produktionsstandorte, Linien, Zellen und OT‑Datenflüsse. Für KI in der Produktion ist das ein entscheidender Vorteil, weil Modelle nicht nur Rohdaten benötigen, sondern kontextualisierte, robuste und kontinuierliche Zeitreihen aus realen Produktionsprozessen.
Auch beim Thema Security unterscheiden sich die Ansätze deutlich in ihrer Ausrichtung.
IoT Hub, IoT Edge und Azure Device Registry setzen auf bewährte Mechanismen der Gerätesicherheit. Unterstützt werden unter anderem:
Mit Azure Device Registry kommt zusätzlicher Mehrwert für größere Geräteflotten hinzu. Dazu gehören zentrales Zertifikatsmanagement für die Ausstellung und Verwaltung von X.509-Zertifikaten, automatisierte Zertifikatsrotation, Integration von Microsoft verwalteter PKI sowie bessere Nachvollziehbarkeit und Governance. Gerade für Audit-Anforderungen ist das relevant: Unternehmen können nicht nur Zertifikatsketten besser nachvollziehen, sondern auch, wer wann welches Gerät oder Zertifikat registriert, geändert oder verwaltet hat.
Die Kommunikation mit der Cloud erfolgt verschlüsselt über TLS. IoT Edge ergänzt dieses Modell durch Geräte- und Modulidentitäten, gesicherte Runtime-Kommunikation und den kontrollierten Einsatz vertrauenswürdiger Container-Images. Über Microsoft Entra ID und Azure RBAC lässt sich steuern, wer IoT-Hub-Ressourcen, Geräteidentitäten, Device Twins, Zertifikate oder Edge-Deployments verwalten darf. Zusätzlich können Azure Policy und bestehende Azure-Zertifizierungen wie ISO oder SOC zur Governance und Compliance beitragen.
Azure IoT Operations ist stärker auf sicherheitskritische OT-Umgebungen ausgerichtet. Die Architektur berücksichtigt typische Anforderungen industrieller Netzwerke, etwa:
Da Azure IoT Operations auf Arc-enabled Kubernetes basiert, nutzt es die Sicherheitsmodelle von Kubernetes und Azure Arc. Dazu gehören Namespaces, Network Policies, Secrets und RBAC. Diese Mechanismen ermöglichen es, Workloads, Konfigurationen und Zugriffe granular zu trennen und zu kontrollieren. Auch die Konnektoren selbst müssen sicher betrieben werden. Bei OPC UA betrifft das beispielsweise Zertifikate, Signierung, Verschlüsselung und die Authentifizierung.
Auf Governance-Ebene bietet Azure IoT Operations eine starke Integration in Azure-Mechanismen wie Richtlinien für Cluster-Konfigurationen, Monitoring und Audit-Logs. Das ist besonders relevant für Unternehmen mit hohen Anforderungen an Nachvollziehbarkeit und regulatorische Compliance, etwa in Energie, Pharma, Automotive oder anderen regulierten Industrien.
Anhand der in unserem Blogbeitrag diskutierten Punkte lassen sich grob zwei Denkmuster unterscheiden.
Beide Welten werden auf absehbare Zeit koexistieren. Die zentrale Frage ist daher nicht, welche Plattform grundsätzlich „besser“ ist, sondern welcher Abstraktionsgrad zum jeweiligen Szenario passt: gerätezentriert mit IoT Hub und IoT Edge oder OT-, prozess- und datenstromzentriert mit Azure IoT Operations.
Für viele Unternehmen wird eine hybride Architektur sinnvoll sein: IoT Hub für globale Produktflotten und Azure IoT Operations für Produktionsstandorte, die diese Produkte herstellen, betreiben oder warten. Damit lassen sich Cloud-, Edge- und OT-Szenarien in einer gemeinsamen Architektur zusammenführen – von sicherer Geräteidentität über lokale Datenverarbeitung bis hin zu globalen Analytics- und KI-Szenarien.
Stehst Du ebenfalls vor der Frage, welche Azure-IoT-Architektur zu Deinem Produktions- oder IoT-Szenario passt? Wir unterstützen Dich gerne dabei, die passende Zielarchitektur zu entwickeln und Deine Datenbasis für industrielle Analytics- und KI-Anwendungsfälle aufzubauen. Sprich uns einfach an.
Domain Lead Cloud Transformation & Data Infrastructure
Private Networking in Azure erhöht die Sicherheit, bringt aber auch höhere Kosten und mehr Architekturaufwand mit sich. Wir erklären, welche Risiken oft übersehen werden und wann Private Endpoints wirklich sinnvoll sind.
Die Kubernetes SIG Network und das Security Response Committee haben das Supportende für Ingress NGINX angekündigt. Bis März 2026 erhält somit einer der beliebtesten Ingress-Controller für Kubernetes nur noch Best-Effort-Unterstützung. Warum Du jetzt handeln solltest.
Kein vorheriger Beitrag
Kein nächster Beitrag
