AWS IoT Core for LoRaWAN Alternative: Souveräner LoRaWAN-Stack mit ChirpStack

AWS IoT Core for LoRaWAN nimmt Betreibern den Betrieb eines eigenen LoRaWAN Network Servers ab — zum Preis von nutzungsbasierter Cloud-Abrechnung und der Datenverarbeitung in der Infrastruktur eines US-Anbieters. Für viele DACH-Organisationen, die unter DSGVO, NIS2 oder das neue KRITIS-Dachgesetz fallen, verschiebt sich damit die Entscheidung weg von reiner Bequemlichkeit hin zur Datensouveränität. ChirpStack, der quelloffene LoRaWAN Network Server, bietet denselben Funktionsumfang als portablen, selbst kontrollierbaren Stack — und über chirphost als verwalteten Dienst in deutschen Rechenzentren, ohne CLOUD-Act-Exposition und ohne Per-Device-Cloud-Kosten. Dieser Beitrag vergleicht beide Ansätze sachlich: Funktionsweise, Pricing, Lock-in und Compliance, mit Stand Mai 2026.

Inhaltsverzeichnis

• Wie AWS IoT Core for LoRaWAN funktioniert
• ChirpStack als souveräne Alternative
• Pricing: nutzungsbasiert versus planbar
• Datensouveränität und der CLOUD Act
• NIS2 und KRITIS-Dachgesetz: der regulatorische Rahmen in DACH
• Lock-in und Migration
• Fazit: Komfort gegen Kontrolle — oder beides
• Quellen

Wie AWS IoT Core for LoRaWAN funktioniert

AWS IoT Core for LoRaWAN ist ein vollständig verwalteter LoRaWAN Network Server (LNS). Laut AWS-Dokumentation „ersetzt" der Dienst „einen privaten LoRaWAN Network Server, indem er Ihre LoRaWAN-Geräte und -Gateways mit AWS verbindet". Der Betreiber muss also keinen eigenen Network Server entwickeln, betreiben oder warten — diese Last übernimmt AWS.

Architektonisch fügt sich der Dienst in die klassische LoRaWAN-Topologie ein: Endgeräte funken an Gateways, Gateways relayen die Pakete an den LNS. Die Gateways sprechen das offene LoRa-Basics-Station-Protokoll (ab Version 2.0.4) über CUPS und LNS; die Verbindung wird per X.509-Zertifikat abgesichert. Unterstützt werden LoRaWAN-Geräte nach den Spezifikationen 1.0.x und 1.1, die Aktivierungsverfahren OTAA und ABP sowie alle drei Geräteklassen A, B und C. Eingehende Nachrichten werden über die AWS IoT Rules Engine weiterverarbeitet und an andere AWS-Services wie Lambda, IoT SiteWise oder CloudWatch Logs geroutet.

Der Vorteil ist offensichtlich: Es gibt keine Server, Datenbanken oder MQTT-Broker zu betreiben, und Gateways aus dem AWS Partner Device Catalog lassen sich nahezu plug-and-play anbinden. Geräte werden über sogenannte Destinations mit AWS-IoT-Regeln verknüpft, die die Payload formatieren und weiterleiten. Der Preis dafür ist, dass der gesamte LoRaWAN-Verkehr durch die AWS-Cloud läuft und die Konfiguration — Destinations, Geräteprofile, Routing-Regeln — eng an das AWS-Ökosystem gebunden ist. Auch der Zugriff auf Public-Network-Roaming (über Partner wie Everynet) ist ein AWS-spezifischer Baustein. Genau an diesen Punkten setzt die Diskussion um Souveränität und Lock-in an. Wer den grundsätzlichen Aufbau eines eigenen Netzes verstehen möchte, findet die Schritte im Leitfaden Privates LoRaWAN-Netzwerk aufbauen.

ChirpStack als souveräne Alternative

ChirpStack ist der am weitesten verbreitete quelloffene LoRaWAN Network Server. Das Projekt steht unter der MIT-Lizenz, ist in Rust geschrieben und wird seit 2015 maßgeblich von Orne Brocaar entwickelt. ChirpStack v4 fasst Network Server und Application Server zu einem einzelnen Binary zusammen und benötigt nur drei Infrastruktur-Abhängigkeiten: PostgreSQL (oder SQLite), Redis und einen MQTT-v5-Broker.

Funktional steht ChirpStack einem Cloud-LNS in nichts nach. Unterstützt werden LoRaWAN 1.0.x und 1.1, alle Geräteklassen A, B und C, OTAA und ABP, sämtliche regionalen Frequenzpläne und Regional-Parameter-Revisionen, Adaptive Data Rate, Multi-Tenancy über eine Mandanten-/Organisationsstruktur, JavaScript-Payload-Codecs, FUOTA (Firmware-Updates over the air), Multicast sowie gRPC- und REST-APIs. Eingebaute Integrationen für MQTT (immer aktiv), HTTP-Webhooks, InfluxDB, ThingsBoard, AWS SNS, Azure Service Bus und GCP Pub/Sub decken die gängigen Daten-Pipelines ab.

Der entscheidende Unterschied ist die Portabilität: Dieselbe ChirpStack-Konfiguration läuft auf jeder Infrastruktur identisch — auf einem VPS, in der privaten Cloud, On-Premise oder als verwalteter Dienst bei chirphost. Es gibt keinen Anbieter, der zwingend im Datenpfad sitzt, und keine proprietären Destinations, die einen Wechsel erschweren. Genauso wichtig: ChirpStack spricht dasselbe LoRa-Basics-Station-Protokoll wie AWS, sodass bestehende Gateways ohne Hardware-Wechsel umgehängt werden können. Eine ausführliche Gegenüberstellung der Funktionsumfänge bietet der Vergleich ChirpStack vs. The Things Stack; für kommerzielle Carrier-Plattformen lohnt der Blick auf ChirpStack vs. Actility ThingPark.

Pricing: nutzungsbasiert versus planbar

Die Kostenmodelle unterscheiden sich grundlegend. AWS rechnet nutzungsbasiert ab, ChirpStack verursacht keine Lizenzkosten — nur Infrastruktur und Betrieb (oder einen Festpreis bei Managed Hosting).

AWS IoT Core for LoRaWAN setzt sich aus mehreren Komponenten zusammen (Stand Mai 2026, Region US East / N. Virginia):

• Konnektivität: gemessen in Verbindungsminuten, 0,08 $ pro 1.000.000 Minuten. AWS rechnet das mit ca. 0,042 $ pro Gerät und Jahr vor, wenn ein Gerät durchgehend (24/7) verbunden ist.
• Messaging: in der ersten Stufe 2,30 $ pro 1.000.000 Nachrichten, gemessen in 5-KB-Schritten; bei sehr hohem Volumen sinkt der Stufenpreis (Mengenrabatt für die Milliarden-Stufen).
• LoRaWAN Metrics: optionales Premium-Feature für 2 $ pro 1.000.000 Records (Metadaten je Uplink/Downlink).

Hinzu kommen die Kosten der nachgelagerten AWS-Services (Rules Engine, Lambda, Speicher), die der eigentliche LoRaWAN-Tarif nicht enthält. Ein kostenloses Kontingent für die ersten 12 Monate umfasst 2.250.000 Verbindungsminuten, 500.000 Nachrichten und 225.000 Registry-/Device-Shadow-Operationen — gut für Tests, aber für Produktivbetrieb nicht ausgelegt.

Bei kleinen Flotten ist diese Per-Device- und Per-Message-Abrechnung günstig und transparent. Mit wachsender Gerätezahl und steigendem Nachrichtenvolumen wird sie jedoch zunehmend schwerer planbar — gerade bei häufigen Uplinks, bestätigten Nachrichten oder Downlink-intensiven Anwendungen. ChirpStack kennt keine Per-Device- oder Per-Message-Gebühren; die Kosten hängen allein von der bereitgestellten Infrastruktur ab. Bei chirphost mit Managed ChirpStack Hosting bedeutet das einen planbaren Festpreis statt einer mit der Flotte mitwachsenden Cloud-Rechnung. Welche Variante bei welcher Größenordnung wirtschaftlicher ist, beleuchtet der Beitrag ChirpStack-Hosting: Managed vs. Self-Hosted.

Datensouveränität und der CLOUD Act

Hier liegt der eigentliche Hebel — und der Punkt, an dem ein verbreitetes Missverständnis auszuräumen ist. AWS bietet LoRaWAN-Regionen in Europa an, konkret Europa (Frankfurt, eu-central-1) und Europa (Irland, eu-west-1), neben US East, US West, Tokio, Sydney und São Paulo. Wer also annimmt, AWS habe „kein EU-Rechenzentrum", liegt falsch.

Der Souveränitätsaspekt ist subtiler: Der US CLOUD Act von 2018 verpflichtet US-amerikanische Anbieter, Daten herauszugeben, die sich in ihrem Besitz, ihrer Obhut oder unter ihrer Kontrolle befinden — unabhängig vom physischen Speicherort. Auch eine AWS-Region in Frankfurt fällt darunter, weil der Mutterkonzern US-Recht unterliegt. Der CLOUD Act entstand als Reaktion auf den „Microsoft-Ireland"-Fall, in dem ein US-Gericht zunächst entschied, die Regierung könne keine im Ausland gespeicherten Daten erzwingen. Nach dem Schrems-II-Urteil des Europäischen Gerichtshofs gelten US-Überwachungsgesetze als problematisch für den angemessenen Schutz von EU-Daten; vertragliche Zusicherungen allein können den gesetzlichen Zugriff einer ausländischen Behörde nicht aushebeln.

Für LoRaWAN-Daten kann das relevant sein, sobald aus Sensordaten Rückschlüsse auf Personen, Standorte, kritische Prozesse oder Betriebsgeheimnisse möglich werden — etwa bei Smart Metering, Asset-Tracking, Gebäudetechnik oder Versorgungsinfrastruktur. Wer diese Daten kontrolliert und herausgeben muss, regelt seit 2025 zusätzlich der EU Data Act für LoRaWAN-Sensordaten. Bei einem souveränen Stack wie ChirpStack auf deutschen Servern verlassen die Daten den kontrollierten Rechtsraum nicht, und es ist kein US-Anbieter im Datenpfad beteiligt. Dieselbe Souveränitäts-Logik gilt auf Netzwerkebene; wie sie sich auf VPN- und Netzwerksicherheit überträgt, beschreibt der Beitrag NIS2 und Netzwerksicherheit unserer Schwestermarke birdhost.

Hinweis: Dieser Abschnitt ist eine technisch-organisatorische Einordnung und kein Rechtsrat. Für eine verbindliche Bewertung Ihrer Datenflüsse ziehen Sie bitte Ihre Datenschutz- und Rechtsberatung hinzu.

NIS2 und KRITIS-Dachgesetz: der regulatorische Rahmen in DACH

Die Souveränitätsfrage ist 2026 keine rein theoretische mehr. Das NIS2-Umsetzungsgesetz wurde am 5. Dezember 2025 im Bundesgesetzblatt verkündet und ist seit dem 6. Dezember 2025 in Kraft. Es weitet die Cybersicherheits-Pflichten erheblich aus: Statt eines kleinen Kreises klassischer KRITIS-Betreiber sind nun rund 30.000 Einrichtungen in Deutschland betroffen — laut OpenKRITIS etwa 8.250 „besonders wichtige" und 21.600 „wichtige" Einrichtungen über neun Hauptsektoren hinweg, darunter Energie, Transport, Wasser, Gesundheit, digitale Infrastruktur und Teile des verarbeitenden Gewerbes.

Betroffene Einrichtungen müssen sich innerhalb von drei Monaten nach Identifizierung beim BSI registrieren (§ 33 NIS2UmsuCG). Ergänzend regelt das KRITIS-Dachgesetz den physischen Schutz und die Resilienz kritischer Anlagen; es wurde vom Bundestag am 29. Januar 2026 beschlossen und setzt die EU-Richtlinie 2022/2557 um. Beide Gesetze verlangen unter anderem ein belastbares Risiko- und Lieferketten-Management.

Für LoRaWAN-Betreiber heißt das konkret: Die Frage, wo die Netzwerkdaten verarbeitet werden und wer rechtlich darauf zugreifen kann, gehört in die Risikobetrachtung. Ein souveräner, in Deutschland betriebener Stack mit klarer Auftragsverarbeitung und nachvollziehbarer Lieferkette reduziert hier die Angriffsfläche im Compliance-Sinne — er ist kein Selbstläufer für Konformität, aber ein sauber dokumentierbarer Baustein. Auch dies ist kein Rechtsrat; die Einstufung Ihrer Organisation klären Sie mit fachkundiger Beratung.

Lock-in und Migration

Ein vollständig verwalteter Cloud-LNS bindet mehr als nur die Geräteregistrierung. Destinations, Payload-Decoder, Routing-Regeln und die Anbindung an AWS-Services (Rules Engine, Lambda, SiteWise) sind AWS-spezifisch und lassen sich nicht 1:1 exportieren. Wer den Anbieter wechseln will, muss Geräteprofile neu anlegen, Codecs nachbauen, Integrationen neu verdrahten und OTAA-Geräte neu joinen lassen.

Die gute Nachricht: Eine Migration zu ChirpStack ist machbar, weil die LoRaWAN-Schnittstelle standardisiert ist. Gateways, die LoRa Basics Station sprechen, lassen sich über CUPS/LNS einfach auf einen ChirpStack-Endpunkt umkonfigurieren — dieselbe offene Software, die auch AWS nutzt. Geräte werden mit identischen DevEUI/JoinEUI/AppKey in ChirpStack neu registriert; OTAA-Geräte führen anschließend einen neuen Join durch, ABP-Sessions lassen sich bei migrierten Session-Keys erhalten. Payload-Codecs übernimmt ChirpStack als JavaScript-Funktionen weitgehend unverändert.

Weil ChirpStack quelloffen ist, gibt es danach keinen erneuten Lock-in: Dieselbe Instanz lässt sich später woanders weiterbetreiben. chirphost begleitet die Migration, richtet die Network-Server-Instanz ein und übernimmt den laufenden Betrieb. Wie sich Managed Hosting und Self-Hosting im Aufwand unterscheiden, zeigt der Vergleich Managed vs. Self-Hosted.

Fazit: Komfort gegen Kontrolle — oder beides

AWS IoT Core for LoRaWAN ist ein ausgereifter, vollständig verwalteter LNS mit tiefer Integration ins AWS-Ökosystem und transparenter nutzungsbasierter Abrechnung. Für Teams, die ohnehin in AWS leben und keine besonderen Souveränitätsauflagen haben, ist das eine solide Wahl. Die Grenzen zeigen sich bei zwei Punkten: der Datensouveränität — auch die Frankfurt-Region fällt unter den CLOUD Act — und dem Lock-in durch AWS-spezifische Konfiguration, kombiniert mit einer Cloud-Rechnung, die mit der Flotte mitwächst.

ChirpStack adressiert genau diese Punkte: derselbe LoRaWAN-Funktionsumfang als quelloffener, portabler Stack ohne Per-Device-Cloud-Kosten und ohne erzwungenen Anbieter im Datenpfad. Mit chirphost gibt es das als verwalteten Dienst in ISO-27001-zertifizierten Rechenzentren in Deutschland — volle Datenhoheit, planbarer Festpreis, kein DevOps-Overhead. Die Preisstufen dazu stehen bei den Flatrate-Plänen ohne Per-Device-Kosten. Für Betreiber mit DSGVO-, NIS2- oder KRITIS-Bezug ist das in der Regel die schlüssigere Architektur. Wer tiefer einsteigen will, beginnt mit dem Vergleich ChirpStack vs. The Things Stack oder dem Leitfaden Privates LoRaWAN-Netzwerk aufbauen.

Was ein gemieteter Network Server im Betrieb abdeckt und wie sich die acht Regionen unterscheiden, steht auf der Seite LoRaWAN Network Server mieten.

AWS, AWS IoT Core und alle zugehörigen Marken sind Eigentum von Amazon Web Services, Inc. ChirpStack ist eine Marke des jeweiligen Projektinhabers. Dieser Beitrag steht in keiner Verbindung zu und wird nicht unterstützt von den genannten Anbietern; Markennennungen dienen ausschließlich dem sachlichen Vergleich.

Quellen

• AWS IoT Core for LoRaWAN — Produktseite
• AWS IoT — What is AWS IoT Core for LoRaWAN?
• AWS IoT Core — Pricing
• AWS IoT Core — Additional metering details
• AWS IoT Wireless — Endpoints und Regionen
• ChirpStack — Offizielle Website
• ChirpStack GitHub Repository (MIT-Lizenz)
• ChirpStack — Architektur-Dokumentation
• OpenKRITIS — NIS2-Umsetzungsgesetz in Deutschland
• Deutscher Bundestag — Beschluss KRITIS-Dachgesetz (29.01.2026)
• Semtech — LoRa Basics Station (CUPS/LNS-Protokoll)
• LoRa Alliance — Was ist LoRaWAN