AWS (Amazon Web Services) has detailed a reference architecture combining NB-IoT and LoRaWAN ingestion with dual-path IoT telemetry processing.
In a blog post, AWS lays out a pattern for handling telemetry from device fleets that could number in the millions, splitting incoming data into two lanes: one built for instant anomaly detection, the other for historical batch analysis.
Two sample dashboards illustrate the pattern in the documentation, a solar farm monitor and a smart building query tool. Both are labelled as samples, not case studies from named customers, and that distinction matters for any engineering team deciding whether the design is ready to lift into production or whether it’s a diagram waiting for a first real deployment.
AWS frames the business case around McKinsey research cited in the post, which finds that digital maintenance and reliability transformations can raise asset availability by 5–15 percent and cut maintenance costs by 18–25 percent.
Those figures come from industry-wide maintenance research, and not a study of this specific architecture, but they support AWS’ argument that treating real-time monitoring and long-term analysis as competing budget priorities costs organisations money they don’t need to lose.
Cellular and radio ingestion carry different operational costs
The ingestion layer handles two device populations with different constraints. NB-IoT devices connect through a cellular carrier or connectivity partner that bridges the radio network to AWS IoT Core, typically using lightweight protocols like UDP or CoAP with a data broker handling protocol translation. That path suits devices in tough radio environments: underground installations, dense urban cores, locations where cellular penetration outperforms other options.
LoRaWAN covers the other end of the spectrum, using gateways running LoRa Basics Station packet forwarders to reach AWS IoT Core for LoRaWAN, AWS’s managed network server. Payloads arrive as base64-encoded binary and route through an IoT Rule, where a Lambda function invokes a decoder that converts the binary into JSON.
However, the catch AWS’ post doesn’t dwell on is that every device model encodes its payload differently—so a fleet with several sensor types needs a matching set of decoder functions, each one built and maintained separately. That’s engineering overhead that scales with device diversity, not just device count.
One rule engine, two destinations
The AWS IoT Core rules engine sits at the centre of the design, splitting incoming data toward Amazon Data Firehose for batch delivery on one side and Amazon Kinesis Data Streams for real-time processing on the other.
AWS’s example contrasts the two well: a temperature reading that crosses a threshold can trigger a cooling system through the real-time lane, while the same sensor’s readings analysed over months inform maintenance scheduling through the batch lane. Same source data, two different jobs.
On the streaming side, data flows from Kinesis into Amazon Managed Service for Apache Flink for stateful processing and anomaly detection, then into Amazon Timestream for InfluxDB 3, which AWS states delivers single-digit millisecond query response times for time-series workloads.
There’s a detail buried in the post worth flagging on its own. Flink doesn’t currently ship a native sink connector for InfluxDB, according to the blog, so anyone building this pipeline today has to write and maintain a custom sink against the InfluxDB v3 write API.
The batch path routes through a three-tier Amazon S3 structure. Firehose delivers raw data into the first bucket unmodified, AWS Glue workflows then clean and standardise it into a second tier, and Glue Crawlers catalogue the result in AWS Glue Data Catalog so downstream tools can find it. A final round of Glue ETL jobs produces business-level aggregations in a third bucket.
The layering gives organisations lineage tracking and query performance gains, and the serverless nature of Glue means the processing scales without a team provisioning capacity ahead of demand.
Natural language queries depend on catalog quality
The conversational layer runs on Amazon Bedrock AgentCore, hosting Strands agents that translate plain-English questions into SQL against Amazon Athena. AWS’ example shows a question like “Show me all devices with temperature above 80 degrees in the last hour” converting into a working SQL statement automatically.
Amazon Titan Text Embeddings interpret Glue Data Catalog metadata semantically, Retrieval-Augmented Generation through Bedrock Knowledge Bases helps agents produce accurate queries, and a Lambda-based feedback loop – accessed through Bedrock AgentCore Gateway – refines queries that fail on the first pass and asks users for clarification when needed.
AWS doesn’t publish accuracy figures for the query translation, and Data Catalog metadata in a live IoT deployment tends to lag behind new device types getting added to a fleet, meaning the semantic interpretation the agent relies on could be working against a partial or stale picture of what’s actually in the data.
AWS points teams toward its Well-Architected Framework and the IoT Lens for guidance on connectivity, processing, and scaling decisions, and recommends adopting the architecture in pieces rather than all at once.
See also: Anthropic and Nozomi bring AI vulnerability research to OT security
Want to learn more about the IoT from industry leaders? Check out IoT Tech Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including AI & Big Data Expo and the Cyber Security Expo. Click here for more information.
IoT News is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.