AWS IoT Core for LoRaWAN Alternative: A Sovereign LoRaWAN Stack with ChirpStack

AWS IoT Core for LoRaWAN takes the burden of running your own LoRaWAN Network Server off your hands — at the cost of usage-based cloud billing and data processing inside a US provider's infrastructure. For many DACH organizations subject to GDPR, NIS2 or the new German KRITIS umbrella act, that shifts the decision away from pure convenience toward data sovereignty. ChirpStack, the open-source LoRaWAN Network Server, delivers the same feature set as a portable, self-controllable stack — and through chirphost as a managed service in German data centers, without CLOUD Act exposure and without per-device cloud costs. This article compares both approaches objectively: how they work, pricing, lock-in and compliance, current as of May 2026.

Table of Contents

• How AWS IoT Core for LoRaWAN works
• ChirpStack as the sovereign alternative
• Pricing: usage-based versus predictable
• Data sovereignty and the CLOUD Act
• NIS2 and the KRITIS umbrella act: the regulatory frame in DACH
• Lock-in and migration
• Conclusion: convenience versus control — or both
• Sources

How AWS IoT Core for LoRaWAN works

AWS IoT Core for LoRaWAN is a fully managed LoRaWAN Network Server (LNS). Per the AWS documentation, the service "replaces a private LoRaWAN network server (LNS) by connecting your LoRaWAN devices and gateways to AWS." The operator therefore does not develop, operate or maintain their own network server — AWS carries that load.

Architecturally the service fits the classic LoRaWAN topology: end devices transmit to gateways, gateways relay packets to the LNS. Gateways speak the open LoRa Basics Station protocol (version 2.0.4+) over CUPS and LNS; the connection is secured with X.509 certificates. It supports LoRaWAN devices compliant with the 1.0.x and 1.1 specifications, the OTAA and ABP activation methods, and all three device classes A, B and C. Incoming messages are processed through the AWS IoT Rules Engine and routed to other AWS services such as Lambda, IoT SiteWise or CloudWatch Logs.

The benefit is obvious: there are no servers, databases or MQTT brokers to operate, and gateways from the AWS Partner Device Catalog onboard almost plug-and-play. The trade-off is that all LoRaWAN traffic flows through the AWS cloud and the configuration — destinations, device profiles, routing rules — is tightly bound to the AWS ecosystem. These two points are exactly where the sovereignty and lock-in discussion begins. If you want to understand the fundamentals of building your own network first, see the guide Building a private LoRaWAN network.

ChirpStack as the sovereign alternative

ChirpStack is the most widely deployed open-source LoRaWAN Network Server. The project is released under the MIT license, written in Rust, and has been developed primarily by Orne Brocaar since 2015. ChirpStack v4 merges the network server and application server into a single binary and requires only three infrastructure dependencies: PostgreSQL (or SQLite), Redis and an MQTT v5 broker.

Functionally, ChirpStack lacks nothing compared to a cloud LNS. It supports LoRaWAN 1.0.x and 1.1, all device classes A, B and C, OTAA and ABP, every regional frequency plan and regional-parameter revision, Adaptive Data Rate, multi-tenancy via a tenant/organization structure, JavaScript payload codecs, FUOTA (firmware updates over the air), multicast, plus gRPC and REST APIs. Built-in integrations for MQTT (always active), HTTP webhooks, InfluxDB, ThingsBoard, AWS SNS, Azure Service Bus and GCP Pub/Sub cover the common data pipelines.

The decisive difference is portability: the same ChirpStack configuration runs identically on any infrastructure — a VPS, a private cloud, on-premise or as a managed service at chirphost. No provider is forced into the data path. For a detailed feature-by-feature breakdown, see the ChirpStack vs. The Things Stack comparison; for commercial carrier-grade platforms, ChirpStack vs. Actility ThingPark is worth a look.

Pricing: usage-based versus predictable

The cost models differ fundamentally. AWS bills on a usage basis; ChirpStack incurs no license fees — only infrastructure and operations (or a flat rate with managed hosting).

AWS IoT Core for LoRaWAN is made up of several components (as of May 2026, US East / N. Virginia region):

• Connectivity: metered in connection-minutes, $0.08 per 1,000,000 minutes. AWS estimates this at roughly $0.042 per device per year if a device stays connected 24/7.
• Messaging: $2.30 per 1,000,000 messages in the first tier, metered in 5 KB increments; the per-tier rate falls at very high volumes (volume discounts at the billion-message tiers).
• LoRaWAN Metrics: an optional premium feature at $2 per 1,000,000 records (metadata per uplink/downlink).

On top of this come the costs of downstream AWS services (Rules Engine, Lambda, storage), which the LoRaWAN tariff itself does not include. A free tier for the first 12 months covers 2,250,000 connection-minutes, 500,000 messages and 225,000 registry/device shadow operations — fine for testing, but not designed for production.

For small fleets this per-device and per-message billing is cheap and transparent. As device counts and message volume grow, however, it becomes increasingly hard to forecast — especially with frequent uplinks, confirmed messages or downlink-heavy applications. ChirpStack has no per-device or per-message charges; costs depend solely on the provisioned infrastructure. At chirphost with managed ChirpStack hosting that means a predictable flat rate instead of a cloud bill that scales with the fleet. Which option is more economical at which scale is examined in ChirpStack Hosting: Managed vs. Self-Hosted.

Data sovereignty and the CLOUD Act

This is where the real lever sits — and where a common misconception needs clearing up. AWS does offer LoRaWAN regions in Europe, specifically Europe (Frankfurt, eu-central-1) and Europe (Ireland, eu-west-1), alongside US East, US West, Tokyo, Sydney and São Paulo. So anyone who assumes AWS has "no EU data center" is wrong.

The sovereignty aspect is more subtle: the US CLOUD Act of 2018 compels US providers to hand over data in their possession, custody or control — regardless of where it physically resides. An AWS region in Frankfurt is covered too, because the parent company is subject to US law. The CLOUD Act emerged in response to the "Microsoft Ireland" case, in which a US court had initially ruled the government could not compel disclosure of data held abroad. Following the EU Court of Justice's Schrems II ruling, US surveillance laws are considered problematic for the adequate protection of EU data; contractual assurances alone cannot override a foreign authority's statutory access.

For LoRaWAN data this can matter as soon as sensor data allows inferences about people, locations, critical processes or trade secrets — for example in smart metering, asset tracking, building automation or utility infrastructure. Who controls that data and who must hand it over is, since 2025, additionally governed by the EU Data Act for LoRaWAN sensor data. With a sovereign stack such as ChirpStack on German servers, the data does not leave the controlled jurisdiction and no US provider sits in the data path. The same sovereignty logic applies at the network layer; how it translates to VPN and network security is described in the article NIS2 and network security by our sister brand birdhost.

Note: this section is a technical and organizational classification, not legal advice. For a binding assessment of your data flows, please consult your data protection and legal counsel.

NIS2 and the KRITIS umbrella act: the regulatory frame in DACH

In 2026 the sovereignty question is no longer purely theoretical. The German NIS2 Implementation Act was promulgated in the Federal Law Gazette on 5 December 2025 and has been in force since 6 December 2025. It significantly broadens cybersecurity obligations: instead of a small set of classic critical-infrastructure operators, around 30,000 entities in Germany are now affected — per OpenKRITIS roughly 8,250 "especially important" and 21,600 "important" entities across nine main sectors, including energy, transport, water, health, digital infrastructure and parts of manufacturing.

Affected entities must register with the BSI within three months of being identified (§ 33 of the implementation act). In addition, the KRITIS umbrella act governs the physical protection and resilience of critical facilities; the Bundestag adopted it on 29 January 2026, transposing EU Directive 2022/2557. Both laws require, among other things, robust risk and supply-chain management.

For LoRaWAN operators this means concretely: the question of where network data is processed and who can legally access it belongs in the risk assessment. A sovereign stack operated in Germany with a clear data processing agreement and a traceable supply chain reduces the attack surface in a compliance sense — it is not an automatic guarantee of conformity, but a cleanly documentable building block. This too is not legal advice; clarify your organization's classification with qualified counsel.

Lock-in and migration

A fully managed cloud LNS binds more than just device registration. Destinations, payload decoders, routing rules and the connection to AWS services (Rules Engine, Lambda, SiteWise) are AWS-specific and cannot be exported one-to-one. Switching providers means recreating device profiles, rebuilding codecs, rewiring integrations and re-joining OTAA devices.

The good news: migration to ChirpStack is feasible because the LoRaWAN interface is standardized. Gateways that speak LoRa Basics Station are easily reconfigured via CUPS/LNS to point at a ChirpStack endpoint — the same open software AWS uses. Devices are re-registered in ChirpStack with identical DevEUI/JoinEUI/AppKey; OTAA devices then perform a new join, and ABP sessions can be preserved if session keys are migrated. ChirpStack carries over payload codecs as JavaScript functions largely unchanged.

Because ChirpStack is open source, there is no renewed lock-in afterwards: the same instance can later be moved elsewhere. chirphost supports the migration, sets up the network server instance and handles ongoing operations. How managed hosting and self-hosting differ in effort is shown in the Managed vs. Self-Hosted comparison.

Conclusion: convenience versus control — or both

AWS IoT Core for LoRaWAN is a mature, fully managed LNS with deep AWS ecosystem integration and transparent usage-based billing. For teams already living in AWS with no special sovereignty constraints, it is a solid choice. Its limits show on two fronts: data sovereignty — the Frankfurt region falls under the CLOUD Act too — and lock-in through AWS-specific configuration, combined with a cloud bill that scales with the fleet.

ChirpStack addresses exactly these points: the same LoRaWAN feature set as an open-source, portable stack without per-device cloud costs and without a forced provider in the data path. With chirphost you get it as a managed service in ISO 27001 certified data centers in Germany — full data control, a predictable flat rate, no DevOps overhead. The pricing tiers are listed under flat-rate plans without per-device fees. For operators with GDPR, NIS2 or KRITIS exposure, that is usually the more coherent architecture. To go deeper, start with the ChirpStack vs. The Things Stack comparison or the guide Building a private LoRaWAN network.

What a rented network server covers operationally, and how the eight regions differ, is set out on the rent a LoRaWAN network server page.

AWS, AWS IoT Core and all related marks are property of Amazon Web Services, Inc. ChirpStack is a trademark of its respective project owner. This article is not affiliated with or endorsed by the providers named; trademark references serve objective comparison only.

Sources

• AWS IoT Core for LoRaWAN — Product page
• AWS IoT — What is AWS IoT Core for LoRaWAN?
• AWS IoT Core — Pricing
• AWS IoT Core — Additional metering details
• AWS IoT Wireless — Endpoints and regions
• ChirpStack — Official website
• ChirpStack GitHub repository (MIT license)
• ChirpStack — Architecture documentation
• OpenKRITIS — NIS2 Implementation Act in Germany
• German Bundestag — KRITIS umbrella act adopted (29 Jan 2026)
• Semtech — LoRa Basics Station (CUPS/LNS protocol)
• LoRa Alliance — What is LoRaWAN