Die Wahl der richtigen Backend-Infrastruktur entscheidet früh über Entwicklungsaufwand, laufende Betriebskosten und die Skalierbarkeit eines IoT-Produkts. Wer ein IoT-Gerät entwickeln lässt, steht spätestens beim Architekturentwurf vor der Frage: AWS IoT Core, Azure IoT Hub oder ein eigenes Backend? Die Antwort hängt nicht von Markenpräferenzen ab, sondern von konkreten Produktanforderungen, Teamkapazitäten und regulatorischen Rahmenbedingungen. Dieser Artikel liefert eine strukturierte Entscheidungsgrundlage für Teams, die diese Wahl unter echten Projektbedingungen treffen müssen.
Die wichtigsten Auswahlkriterien für IoT-Backends
Bevor ein Plattformvergleich sinnvoll ist, müssen vier Dimensionen geklärt sein: Gerätevolumen und Wachstumspfad, Datensouveränität und Compliance-Anforderungen, Latenzanforderungen auf der Device-Seite sowie das intern verfügbare Cloud-Know-how. Wer diese Parameter nicht vorab definiert, trifft eine Plattformentscheidung auf Basis von Marketingmaterial statt auf Basis von Systemanforderungen.
Das Gerätevolumen bestimmt die Kostenstruktur direkt. AWS und Azure rechnen pro Nachricht und Verbindungsminute ab. Bei 10.000 Geräten mit stündlichen Telemetriezyklen landen die monatlichen Plattformkosten schnell im vierstelligen Euro-Bereich. Bei 100.000 Geräten übersteigt das die Personalkosten eines Junior-DevOps-Engineers für ein eigenes Backend. Compliance ist ein separater Treiber: DSGVO, MDR (Medical Device Regulation) und branchenspezifische Datenlokalisierungspflichten schränken ein, welche Regionen genutzt werden dürfen und ob Daten überhaupt eine EU-Grenze überschreiten dürfen. Teams, die das erst nach der Architekturentscheidung prüfen, riskieren eine vollständige Backend-Migration kurz vor dem Markteintritt.
Latenz und Protokollunterstützung
MQTT-basierte Verbindungen über Mobilfunk (NB-IoT, LTE-M) reagieren empfindlich auf Keep-Alive-Intervalle und Broker-Latenz. Managed Plattformen wie AWS und Azure bieten garantierte Verfügbarkeit und globale Endpunkte, aber keine Kontrolle über interne Routing-Latenz. Für industrielle Steuerungsanwendungen mit Sub-100-ms-Anforderungen ist das ein Ausschlusskriterium. Für Health-Tracking-Wearables mit 5-Sekunden-Sendeintervall ist es irrelevant.
AWS IoT Core: Stärken, Schwächen und typische Einsatzszenarien
AWS IoT Core bietet das breiteste Ökosystem unter den Managed-IoT-Plattformen. Die Integration mit Lambda, S3, DynamoDB, SageMaker und Greengrass ist nativ und gut dokumentiert. Für Teams, die bereits AWS-Infrastruktur betreiben, reduziert das den Integrationsaufwand erheblich.
Die Stärke liegt in der Reife der Geräteverwaltung: Fleet Provisioning, Device Defender und OTA-Updates über Jobs sind produktionsreif und werden aktiv weiterentwickelt. Für IoT-Produktentwicklung mit mehreren Tausend Geräten in der ersten Rolloutphase und erwartetem Wachstum ist das ein realer Vorteil gegenüber einem selbst gebauten System.
Bekannte Schwächen und Fehlerszenarien
Das Preismodell von AWS IoT Core ist komplex. Nachrichten werden in 5-KB-Blöcken abgerechnet, Verbindungsminuten separat, Rules-Engine-Auslösungen nochmals separat. Teams, die das Preismodell nicht vorab modellieren, erleben bei der ersten Produktionsrechnung Überraschungen von 40 bis 80 Prozent über der geschätzten Baseline. Ein weiteres Problem: Der AWS IoT Device Shadow hat ein Konsistenzmodell, das bei hoher Update-Frequenz zu Race Conditions führt. Wer Shadow-Updates und direkte MQTT-Publish-Nachrichten parallel nutzt, ohne Versionierung zu implementieren, verliert Gerätezustandsinformationen ohne Fehlermeldung.
AWS IoT Core passt für Teams mit AWS-Erfahrung, Produkte mit variablem Gerätevolumen und Bedarf an tiefer Analytics-Integration. Es passt nicht für Projekte mit strikter EU-Datenlokalisierung ohne AWS-EU-Region-Freigabe oder für Produkte mit extrem preissensitivem Unit-Economics-Modell bei hohem Nachrichtenvolumen.
Azure IoT Hub: Stärken, Schwächen und typische Einsatzszenarien
Azure IoT Hub ist die stärkere Wahl für Unternehmen, die bereits in Microsoft-Infrastruktur investiert haben: Active Directory, Power BI, Azure Digital Twins und Azure Stream Analytics integrieren sich ohne zusätzliche Middleware. Für B2B-Produkte im industriellen Umfeld, wo Kunden häufig Microsoft-Ökosysteme betreiben, vereinfacht das die Systemintegration auf Kundenseite erheblich.
Die Geräteverwaltung über IoT Hub Device Provisioning Service (DPS) ist für große Flotten mit heterogener Hardware gut geeignet. X.509-Zertifikat-basiertes Provisioning skaliert auf Millionen Geräte ohne manuelle Eingriffe. Für industrielle Wearables oder Embedded-IoT-Geräte in der Fertigungsautomation ist das ein konkreter Produktionsvorteil.
Bekannte Schwächen und Fehlerszenarien
Azure IoT Hub hat ein hartes Limit bei der Anzahl täglicher Nachrichten pro Tier. Wer in den Free- oder S1-Tier startet und das Nachrichtenvolumen unterschätzt, wird gedrosselt, nicht skaliert. Die Drosselung tritt ohne Warnung ein und führt zu Nachrichtenverlusten auf Geräteseite, sofern kein lokales Buffering implementiert ist. Teams, die kein persistentes Message-Queuing auf dem Embedded-Device implementieren, verlieren Telemetriedaten unter Last. Das ist bei medizinischen Anwendungen mit lückenloser Aufzeichnungspflicht ein Zertifizierungsrisiko.
Azure IoT Hub passt für Microsoft-affine Unternehmensumgebungen, industrielle Anwendungen mit komplexer Gerätehierarchie und Produkte, die Azure-native Analytics benötigen. Bei reinen Consumer-IoT-Produkten mit einfachen Datenflüssen ist der Konfigurationsaufwand von Azure IoT Hub oft unverhältnismäßig hoch.
Eigenes Backend: Wann sich der Aufwand wirklich lohnt
Ein eigenes Backend rechtfertigt sich unter drei spezifischen Bedingungen: erstens bei strikten Datensouveränitätsanforderungen, die On-Premise-Hosting oder private Cloud-Instanzen vorschreiben; zweitens bei Geschäftsmodellen, in denen die Plattformkosten bei Skalierung die Marge strukturell gefährden; drittens bei Protokollanforderungen, die Managed-Plattformen nicht nativ unterstützen.
Die initiale Entwicklung eines eigenen MQTT-Brokers mit Geräteverwaltung, OTA-Update-Pipeline und Monitoring kostet realistisch 3 bis 6 Monate Entwicklungszeit für ein erfahrenes Backend-Team. Wer das nicht einkalkuliert, verzögert den Markteintritt. Der Betrieb eines eigenen Backends erfordert dauerhaft DevOps-Kapazität: Security-Patches, Skalierungsmanagement und Incident-Response fallen nicht weg, sie werden nur intern verlagert.
Die unterschätzte Komplexität
Eine verbreitete Annahme ist, dass ein eigenes Backend günstiger ist, sobald die Gerätezahl wächst. Das stimmt nur dann, wenn die internen Personalkosten für Betrieb und Weiterentwicklung nicht vollständig eingerechnet werden. Bei 50.000 Geräten mit moderatem Nachrichtenvolumen liegen die AWS-Kosten bei etwa 800 bis 1.500 Euro pro Monat. Ein dedizierter DevOps-Engineer für das eigene Backend kostet das Dreifache. Der Break-even liegt in den meisten Szenarien deutlich höher, als Teams initial annehmen. Für Produkte mit spezifischen Protokollanforderungen, etwa proprietäre Industrieprotokolle oder medizinische Datenformate, kann ein eigenes Backend trotzdem die einzig valide Option sein.
Wer ein IoT-Backend entwickeln lässt, sollte die Betriebskosten über einen 5-Jahres-Horizont modellieren, bevor die Architekturentscheidung fällt.
Entscheidungsmatrix: Welche Plattform passt zu welchem Produkttyp?
Die folgende Zuordnung basiert auf den Produkteigenschaften, die die Plattformwahl am stärksten determinieren. Sie ist nicht universell, sondern als Ausgangspunkt für die eigene Analyse gedacht.
- Consumer IoT, schneller Markteintritt, AWS-Know-how vorhanden: AWS IoT Core. Geringer Integrationsaufwand, breites Ökosystem, OTA-Reife. Preismodell vorab modellieren.
- Industrielles IoT, Microsoft-Unternehmensumgebung, komplexe Gerätehierarchie: Azure IoT Hub. Natürliche Integration in bestehende Unternehmensinfrastruktur. Message-Buffering auf Device-Seite implementieren.
- Medizintechnik mit EU-Datenlokalisierung und MDR-Anforderungen: Eigenes Backend oder AWS/Azure mit vertraglich fixierter EU-Region-Einschränkung. Regulatorische Anforderungen vor der Architekturentscheidung rechtlich klären.
- Wearables mit hohem Nachrichtenvolumen und preissensitivem Geschäftsmodell: Eigenes Backend ab einer Gerätezahl, bei der Plattformkosten die Marge strukturell belasten. Break-even-Analyse über 5 Jahre durchführen.
- Prototyp oder MVP mit unbekanntem Skalierungspfad: Managed-Plattform (AWS oder Azure) für die erste Phase. Migration später einfacher als ein eigenes Backend von Beginn an zu betreiben.
Eine Entscheidung, die auf Basis des Prototyps getroffen wurde, muss vor dem Serienanlauf überprüft werden. Skalierungsannahmen, Compliance-Anforderungen und Kostenstrukturen ändern sich zwischen MVP und Serienprodukt regelmäßig. Wer das nicht explizit als Checkpoint im Entwicklungsprozess verankert, trägt eine Architekturentscheidung aus der Frühphase in die Produktion, ohne sie je validiert zu haben.
Wie Oxeltech bei der IoT-Backend-Auswahl und Systemintegration unterstützt
Wir begleiten IoT-Produktteams von der ersten Architekturentscheidung bis zur Serienreife. Bei der Backend-Auswahl bedeutet das konkret:
- Analyse der Produktanforderungen hinsichtlich Gerätevolumen, Nachrichtenfrequenz, Datensouveränität und Compliance-Scope (DSGVO, MDR, CE)
- Modellierung der Betriebskosten über den Produktlebenszyklus für AWS, Azure und eigenes Backend im direkten Vergleich
- Firmware- und Embedded-Software-Entwicklung mit sauber abgetrennter Backend-Abstraktionsschicht, die eine spätere Plattformmigration ohne Hardware-Revision ermöglicht
- Integration drahtloser Protokolle (BLE, NB-IoT, LTE-M, LoRa, Wi-Fi) mit plattformspezifisch optimiertem Verbindungsmanagement und lokalem Message-Buffering
- Unterstützung bei der Hardware- und Schaltungsentwicklung mit Blick auf die gesamte Systemarchitektur, nicht isoliert auf das PCB
Wir haben über 20 Hardwareprodukte vom Konzept bis zur Serienproduktion begleitet, darunter IoT-Geräte für Medizintechnik, industrielle Automatisierung und Consumer Electronics. Wenn die Backend-Entscheidung für dein Produkt ansteht und du einen technischen Partner brauchst, der die Systemebene mitdenkt, nimm Kontakt mit uns auf.
Ähnliche Artikel
- IoT Dienstleister beauftragen: Was ein guter Vertrag regeln sollte
- IoT Entwicklung beauftragen: Die richtigen Fragen im ersten Meeting
- IoT Produktentwicklung Prozess: Schritt für Schritt erklärt
- Hardwareentwicklung outsourcen: Was du vorher wissen solltest
- Warum scheitern so viele Wearable-Startups in der Entwicklungsphase?
