Trotz AWS-Panne: MQTT-Plattform EMQX meldet stabile Systeme und erklärt Architekturprinzipien

Als am 20. Oktober 2025 die Amazon-Cloud-Region us-east-1 ausfiel, waren weltweit zahlreiche Online-Dienste und IoT-Anwendungen betroffen. Das Unternehmen EMQ Technologies (EMQ), Betreiber der IoT-Datenplattform EMQX Cloud, vermeldete aber nur geringe Auswirkungen. Seine Resilienz gegenüber dem flächendeckenden Cloud-Versagen erläuterte das Unternehmen in einem eigenen Blogbeitrag.

EMQ wurde 2017 gegründet und hat seinen Ursprung im Open-Source-Projekt EMQX. Der Anbieter entwickelt Messaging-Systeme auf Basis des MQTT-Protokolls (Message Queuing Telemetry Transport), das weltweit zu den wichtigsten Kommunikationsstandards im Internet der Dinge zählt.

Die Plattform EMQX ist als skalierbarer MQTT-Broker konzipiert und verarbeitet laut Hersteller Millionen von gleichzeitigen Verbindungen und Milliarden Nachrichten pro Tag. Neben einer Enterprise-Version bietet EMQ auch eine vollständig verwaltete Cloud-Variante an, die auf mehreren großen Cloud-Plattformen betrieben werden kann.

Laut EMQX: Stabiler Betrieb trotz AWS-Ausfall

Nach Angaben von EMQX blieb der zentrale Messaging-Dienst während der Störung in der AWS-Region us-east-1 weitgehend stabil. Nur wenige Kunden hätten kurzzeitige Verbindungsprobleme gemeldet. Betroffen gewesen seien vor allem Integrationsfunktionen, die auf andere AWS-Dienste wie DynamoDB, Kinesis oder S3 zugreifen.

Nach Wiederherstellung der AWS-Systeme hätten sich die betroffenen Integrationen automatisch erholt, so das Unternehmen. Die Kernplattform – also der MQTT-Kommunikationsdienst – sei stabil geblieben.

Begründung: Architekturprinzipien zur Ausfallsicherheit

EMQ führt die Stabilität auf mehrere technische Prinzipien zurück, die laut eigener Darstellung seit dem Start der Plattform konsequent umgesetzt werden:

1. Begrenzte Cloud-Abhängigkeiten:
EMQX Cloud setzt nach eigenen Angaben nur auf Basisdienste wie EC2 (Compute) und NLB (Load Balancer). Durch diese „reduzierte Architektur“ sinke die Abhängigkeit von komplexen Cloud-Diensten und damit das Risiko von Kaskadenausfällen.

2. Multi-AZ-Architektur (Verteilung über mehrere Verfügbarkeitszonen):
Selbst kleinere EMQX-Cluster werden auf mehrere AWS-Zonen verteilt, um lokale Störungen abzufangen. Der Ansatz erhöht zwar die Betriebskosten, soll aber Ausfälle einzelner Rechenzentren wirksam abfedern.

3. Multi-Cloud-Strategie:
EMQX ist laut Anbieter cloud-agnostisch aufgebaut. Kunden können die Plattform mit identischer Konfiguration auch auf Microsoft Azure oder Google Cloud betreiben. Das verringert die Abhängigkeit von einem einzelnen Cloud-Anbieter und erlaubt alternative Disaster-Recovery-Strategien.

„Selbst bei unseren kleinsten Dedicated-Flex-Deployments bestehen wir darauf, die EMQX-Broker-Knoten über mehrere Verfügbarkeitszonen (Availability Zones) zu verteilen. Ja, das erhöht die Kosten durch den Datenverkehr zwischen den Zonen. Ja, es macht die Automatisierung der Bereitstellung komplexer. Aber wir halten das für unverzichtbar bei produktiven IoT-Workloads.“ – Benniu Ji, VP of Product bei EMQ

Lehren für die IoT-Branche

Aus dem Ereignis zieht EMQ mehrere Schlussfolgerungen:

• Resilienz betrifft nicht nur den MQTT-Broker, sondern die gesamte Datenpipeline – inklusive Datenbanken, Storage und Integrationspunkte.
• Hohe Verfügbarkeit allein reicht nicht aus; kritische Anwendungen benötigen vollständige Disaster-Recovery-Strategien über Regionen oder Clouds hinweg.
• Cluster Linking, eine EMQX-Funktion, ermöglicht aktive Verbindungen zwischen regionalen Clustern. Damit lassen sich globale IoT-Netze mit automatischem Failover betreiben, ohne dass Ressourcen brachliegen.

Zusammenfassung (tl;dr)

• AWS-Ausfall (us-east-1) führte weltweit zu Störungen, auch im IoT-Sektor.
• EMQX berichtet über weitgehend stabile Systeme während des Vorfalls.
• Erklärungsansatz: bewusste Begrenzung von Cloud-Abhängigkeiten, Multi-AZ- und Multi-Cloud-Architektur.
• Einordnung: Der Blogbeitrag dient auch der Selbstdarstellung des Unternehmens.
• Bedeutung: Beispielhaft für die wachsende Relevanz robuster IoT-Architekturen in Abhängigkeit von Cloud-Diensten.