Skip to content
Published on

IoT Cloud Platforms in 2026 — AWS IoT Core / Azure IoT Hub / Particle / Arduino Cloud / ThingsBoard / Balena / Magistrala (Mainflux) Deep-Dive Comparison

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Prologue — Why We Need to Re-Examine IoT Cloud in 2026

If someone made an IoT cloud platform chart around 2018, half of it is empty today. Google sunsetting Cloud IoT Core in August 2023 was the first major signal. IBM Watson IoT Platform followed in August 2024. The phrase "the big three clouds" no longer holds in IoT. Only AWS and Azure remain, and both are aggressively expanding their managed IoT stacks.

That does not mean managed IoT is dead — far from it. Particle has solidified its hold on cellular IoT, Arduino Cloud added an IoT Cloud Editor to lower the entry barrier for makers and education, and Adafruit IO and Blynk became the de-facto defaults for users of five-dollar boards. In the open source camp, ThingsBoard bundled a full stack (broker, rule engine, dashboards) into a self-hostable option, and Balena enabled near-production fleet operations on Raspberry Pi with Docker. Mainflux rebranded as Magistrala in 2024 and continues with the same architecture as an LF Edge friendly successor. The enterprise industrial space belongs to Bosch IoT Suite and Schneider Electric EcoStruxure. Edge runtimes narrowed to four — Azure IoT Edge, AWS Greengrass, Open Horizon (LF), and KubeEdge (CNCF).

"Where Google left, the managed segment fragmented further and open source got tougher." That is the one-line summary of the 2026 IoT cloud map.

The goal of this article is to break 18 platforms down on the same axes and compare them honestly. After the comparison, we walk through decision trees for four scenarios — DIY maker, startup, enterprise, and cellular operator. All prices and feature numbers are as of May 2026, and we focus on structural differences.

Prices change quickly. Six months from now numbers will move, but the decision framework should still hold.

1. The 2026 IoT Cloud Map — Four Categories

There are too many platforms at first glance, but they fall into four categories. The categorization itself is the first step of decision-making.

(A) Hyperscaler IoT — AWS / Azure Hyperscalers offering managed IoT inside their own clouds. AWS IoT Core, Greengrass, Device Defender, SiteWise; Azure IoT Hub, IoT Edge, Azure Sphere. Strength: deep integration with other cloud services (Lambda, Kinesis, Event Hubs, Stream Analytics, S3, Cosmos DB). Weakness: lock-in and per-device costs. Google IoT Core is gone, and IBM Watson IoT is also gone.

(B) Specialist Managed IoT — Particle / Arduino / Adafruit / Blynk / Losant SaaS companies whose only business is IoT. Particle bundles cellular modems all the way through. Arduino Cloud and Adafruit IO are strong in maker / education, Blynk excels in mobile app building, and Losant targets industrial and mid-market. Strength: domain focus and simplicity. Weakness: not as deep on data analytics and AI integration as the hyperscalers.

(C) Open Source Self-Hosted — ThingsBoard / Balena / Magistrala (Mainflux) You operate the server yourself or run it on your own cloud. ThingsBoard is a Java full stack (MQTT, rule engine, dashboards), Balena is Docker-based fleet management (strong on Raspberry Pi and NVIDIA Jetson), Magistrala is a Go microservices architecture (successor to Mainflux). Strength: data sovereignty, no lock-in, deep customization. Weakness: operational burden.

(D) Enterprise Industrial IoT — Bosch / Schneider EcoStruxure Specialized in industrial, building, and energy domains. Bosch IoT Suite covers automotive and Industry 4.0. Schneider EcoStruxure covers power, HVAC, and building automation. Strength: domain models and OT (operational technology) integration. Weakness: pricing and closed nature.

On top of this four-way split sits a separate edge runtime layer. Azure IoT Edge, AWS Greengrass, Open Horizon (under LF Edge), and KubeEdge (CNCF) hold the market. The core idea is running containers or functions on the device itself.

Then there is the protocol layer. MQTT 5.0 is rapidly replacing 3.1.1 from 2018, while CoAP, AMQP, OPC UA, LoRaWAN, and Sigfox survive in their own niches. Matter is smart-home only, so we cover it in a separate article.

Keep the four categories in mind, and now we go through them one by one. Each chapter follows the same template — Surface and Strengths, Device SDK, Messaging and Routing, Edge and Device Management, Pricing, Weaknesses, One-line Summary.

2. AWS IoT Core + Greengrass + Device Defender + SiteWise

Surface and Strengths AWS's IoT stack is not a single service but a collection of puzzle pieces. Core messaging is AWS IoT Core. The edge runtime is AWS IoT Greengrass v2. Security and anomaly detection is AWS IoT Device Defender. Industrial asset modeling is AWS IoT SiteWise. Device management is AWS IoT Device Management. Device simulation and testing is AWS IoT Device Tester. This mosaic is both the strength and the learning curve.

Device SDK Official SDKs: C, C++, Python, JavaScript / Node.js, Java, Embedded C (with FreeRTOS integration). Amazon's acquisition of FreeRTOS in 2017 paid off — by 2026, the FreeRTOS + AWS IoT Device SDK combination is the de-facto reference on ESP32, STM32, Nordic, and NXP MCUs.

Messaging and Routing MQTT 3.1.1 and MQTT 5.0 are both supported. The key MQTT 5.0 features — User Properties, Reason Codes, Shared Subscriptions, Message Expiry — went GA in 2024. Messages pass through the IoT Rules Engine and are routed to Lambda, Kinesis, S3, DynamoDB, SQS, SNS, Step Functions, Timestream, and more. The rule engine uses SQL-like syntax.

-- When temperature exceeds 80, call Lambda; persist all messages to Timestream
SELECT *, topic(2) AS device_id
FROM 'sensors/+/temperature'
WHERE temperature > 80

Edge — Greengrass v2 Greengrass is an edge runtime that runs Lambda functions, Docker containers, and ML models on the device. v2 uses a component-based architecture — built-in components like aws.greengrass.Cli, aws.greengrass.StreamManager, and aws.greengrass.Nucleus combine with custom components. Deployments go through the greengrass-cli or the cloud console.

Device Defender — Security Detect (anomaly detection), Audit (security audit), and automatic ACL validation per MQTT topic. By 2026, ML-based anomaly detection is default. Threat intelligence integration is GA.

SiteWise — Industrial Asset Modeling Pulls data from OPC UA servers on factory lines and models asset hierarchies. SiteWise Edge collects and aggregates data on-premises. A core tool of industrial IoT.

Pricing

  • Messages: about 1 USD per million (US East baseline)
  • Device connectivity: 0.08 USD per million connect minutes
  • Rules engine: 0.15 USD per million rule executions
  • Greengrass: 0.16 USD per device-month (first 1000 free)
  • SiteWise: proportional to assets and properties

In real bills, the largest line items are usually Rules Engine and Timestream / Kinesis charges.

Weaknesses

  • Steep learning curve. You need to learn six or seven services to make the full stack work.
  • Sending data to another cloud adds work (ingest is easy, egress is costly and complex).
  • Per-device cost becomes a burden at scale beyond a million devices (especially Greengrass).

One-Line Summary

The most complete stack. If you accept the learning curve and the lock-in, it is the endgame of IoT. The default for industrial IoT or organizations that already run on AWS core infrastructure.

3. Azure IoT Hub + IoT Edge + Azure Sphere

Surface and Strengths Microsoft's IoT stack consists of Azure IoT Hub (core messaging), Azure IoT Edge (edge runtime), Azure IoT Central (SaaS-form IoT app platform), Azure Digital Twins (asset and relationship modeling), and Azure Sphere (MCU-class secure OS and hardware). In 2025, Azure IoT Operations was added, extending the stack to Arc-based Kubernetes edge.

Device SDK Official SDKs: C, .NET, Python, Java, Node.js, Embedded C. Azure RTOS (formerly ThreadX) is free and runs nicely on ESP32 and STM32. In 2025, Azure RTOS moved to the Eclipse Foundation and was re-open-sourced as Eclipse ThreadX, with Microsoft remaining a major contributor.

Messaging and Routing MQTT 5.0 support went GA in 2024. Device-to-cloud is D2C, cloud-to-device is C2D. Messages route to Event Hubs, Service Bus, Blob Storage, and Cosmos DB. Device Twins — JSON documents that mirror device state — are the core abstraction. This is the most distinctive part of Azure.

{
  "deviceId": "thermostat-001",
  "desired": { "targetTemp": 22, "fanSpeed": "auto" },
  "reported": { "targetTemp": 22, "fanSpeed": "auto", "currentTemp": 23.4 }
}

desired is the state the cloud wants. reported is the actual state the device reports. The device tries to converge until they match. The canonical pattern for declarative device control.

Edge — IoT Edge A Docker-based (technically Moby) container runtime. Each module is deployed as a container image. Microsoft provides modules for Stream Analytics (SQL at the edge), Function App, and Custom Vision. Inter-module communication goes through a message router called edgeHub.

Azure Sphere — The OS We Thought Was Dead A sunset announcement came in 2024, but it survived through 2025. MediaTek MT3620 MCU + Pluton security subsystem + a Linux-based secure OS. The model: Microsoft provides seven years of security patches per MCU-class device. The price is a one-time 8.95 USD per device (2026).

Azure IoT Operations — New in 2025 A new stack that bundles a Kubernetes edge via Arc. A Kafka-based MQTT broker, OPC UA connector, and data processing pipeline are the core. An attempt to reframe industrial IoT around Arc + K8s.

Pricing

  • IoT Hub free tier: 8,000 messages per day (test use)
  • B1: starts around 10 USD per device-month, varies by device count and message rate
  • IoT Edge: included in IoT Hub pricing; no extra per-device cost (the core is open source)
  • Sphere: 8.95 USD one-time per device

Weaknesses

  • The Device Twin model is powerful but has a learning curve.
  • Azure IoT Central is nicely built but its pricing is hard to predict.
  • Azure Sphere's future is still uncertain — trust took a hit after the 2024 sunset scare.

One-Line Summary

Device Twins and Eclipse ThreadX are the weapons. For orgs already on Azure, it is on par with AWS. Integration with the Microsoft ecosystem is the deciding factor.

4. Google Cloud IoT Core Sunset (August 2023) — Significance

On August 16, 2022, Google announced it would retire Cloud IoT Core on August 16, 2023. One year of migration time. The industry shook.

Why It Was Sunset Google's official line was "the partner ecosystem is mature enough that we no longer need to run this directly." The real reasons were more complex. (a) AWS and Azure dominated IoT and catching up was hard. (b) IoT Core revenue was small relative to other GCP areas. (c) Per-device cost did not fit the rest of GCP's pricing model.

Migration Outcome Google recommended partners like ClearBlade, Akenza, and SoftServe. In practice, many customers migrated to AWS IoT Core or Azure IoT Hub. Some went to open-source options like ThingsBoard or EMQX.

What Remained

  • Pub/Sub survived — you can still use it as a backend for IoT data ingestion on GCP.
  • BigQuery and Dataflow remain strong for IoT data analytics — ingest elsewhere, then push into BigQuery.
  • Google Distributed Cloud Edge survived for edge computing but is not a direct successor to IoT Core.

Significance When big tech leaves IoT, the market splits two ways. (a) AWS and Azure absorb share. (b) Open-source projects (ThingsBoard, EMQX, Magistrala) get a tailwind. This event is the largest single driver of the open-source IoT renaissance.

Where Google left, organizations that fear lock-in headed to open source like ThingsBoard and Magistrala. "What if they leave again?" became a decision criterion.

5. IBM Watson IoT Sunset (August 2024) — Another Departed Big Player

A year after Google left, IBM walked the same road.

Watson IoT Platform Sunset In December 2023, IBM announced it would retire the Watson IoT Platform in December 2024. The actual sunset went ahead on schedule. Some functions moved to the Maximo Application Suite, but the seat that Watson IoT held — providing "device → cloud → analytics" as an integrated managed service — is now vacant.

Why Similar to Google. (a) Got pushed out by AWS and Azure. (b) IBM's IoT sales were absorbed into industrial solutions (Maximo), making a separate device-priced IoT service hard to sustain. (c) After the Red Hat acquisition, IBM's IoT strategy shifted toward OpenShift and MQTT (HiveMQ partnership).

Absorption into Maximo IBM Maximo Application Suite is an asset management SaaS that includes IoT monitoring and predictive maintenance. Watson IoT users either (a) moved to Maximo or (b) went to AWS or Azure.

Remaining IBM IoT Assets

  • HiveMQ partnership — one of the standard MQTT brokers.
  • Red Hat AMQ Streams (Kafka-based) — used for IoT data ingestion.
  • OpenShift on Edge — an edge computing platform.

Big tech took the "we will not run IoT ourselves" stance twice in a row. The seats Google and IBM vacated were either consolidated into AWS / Azure or scattered into open source.

6. Particle — Cellular IoT Done Managed

Surface and Strengths Particle may be the only company that fully manages cellular IoT end-to-end. Hardware (Photon 2 = Wi-Fi, Boron 404X = LTE-M, Tracker SoM = LTE-M+GPS), cellular SIM (own or partner carriers), cloud (Particle Cloud), device OS, and SDKs — all bundled into one sale.

Device SDK and Device OS Official SDK is their own Device OS (C++ based, ARM Cortex-M series) with a Wiring-compatible API. If you know Arduino, you are productive in five minutes. Webhooks call external APIs. Variables and Functions call device functions directly from the cloud.

// Particle Device OS — the pattern you learn in five minutes
void setup() {
  Particle.variable("temp", currentTemp);
  Particle.function("setLed", setLed);
}

void loop() {
  currentTemp = readTemp();
  Particle.publish("temperature", String(currentTemp), PRIVATE);
  delay(60000);
}

The Cellular Differentiator Particle issues its own SIM cards, provides global LTE-M roaming, and rolls the data cost into device subscription. Pricing is by megabyte, and within the device's monthly data allowance, you use it freely. This is the decisive value AWS and Azure do not offer.

Edge — Mesh Originally Particle pushed a Mesh network (802.15.4 based), but discontinued it in 2020. Today they focus on per-device cellular and Wi-Fi. The Particle Edge SoM line targets industrial.

Pricing

  • Device activation: about 3 USD one-time per device
  • Cellular data: about 2 USD per device-month up to 3 MB; about 5 USD up to 50 MB
  • Cloud messages: a free baseline, then by message count
  • Photon 2 (Wi-Fi device): around 25 USD
  • Boron 404X (LTE-M): around 50 USD

Weaknesses

  • Devices are locked into Particle hardware. Plain ESP32 or STM32 boards are hard to use directly.
  • Global cellular roaming has limits in some countries (China especially).
  • Analytics and AI integration are not as deep as AWS or Azure.

One-Line Summary

If you want a simple start with cellular IoT, Particle. Getting devices, SIMs, and cloud from one vendor is an overwhelming value. The lock-in is something you accept.

7. Arduino Cloud + IoT Cloud Editor

Surface and Strengths Arduino's IoT cloud, launched as Arduino IoT Cloud in 2019. In 2024 it added an IoT Cloud Editor that lets you write and flash code straight from the browser. It supports Arduino boards (MKR series, Nano IoT, Portenta, Nicla, etc.) and some generic ESP32 / ESP8266 boards.

Device SDK The Arduino standard library, ArduinoIoTCloud. Board declaration, variable mapping, and callbacks take only a few lines.

// Arduino IoT Cloud — the shortest possible pattern
#include "thingProperties.h"

void setup() {
  Serial.begin(9600);
  initProperties();  // auto-generated from the cloud
  ArduinoCloud.begin(ArduinoIoTPreferredConnection);
}

void loop() {
  ArduinoCloud.update();
  // Just change a variable and the cloud syncs automatically
}

thingProperties.h is auto-generated when you define variables in the Arduino Cloud console. The design philosophy is "write almost no code, just change variables."

Dashboards Drag-and-drop widgets (charts, gauges, switches, sliders, alerts). Anyone can build an IoT dashboard in fifteen minutes. This is the core reason Arduino became the maker / education default.

Pricing

  • Free: 1 device, limited data
  • Maker: 5 USD per month, 25 devices
  • Maker Plus: 10 USD per month, 100 devices
  • School: separate classroom plan
  • Pro: per-device pricing, industrial features

Weaknesses

  • Device caps are tight (1 free, 25 maker). Industrial scale is out of reach.
  • Data analytics is basic visualization. To analyze, you must export.
  • Code freedom is limited — you fit your code to the variable model.

One-Line Summary

The default for makers, students, and classrooms. To scale industrially you move elsewhere, but the first thirty minutes of learning is shortest on Arduino Cloud.

8. Adafruit IO and Blynk — Two Giants of the Maker Market

Adafruit IO The IoT cloud run by hardware company Adafruit. Any board — ESP32, Raspberry Pi, Circuit Playground — can connect via MQTT or HTTP. The design is simple: Feeds (data streams), Dashboards (visualization), Triggers (condition to action), and Actions (webhooks). That is the whole thing.

# Adafruit IO — the one-line Python client
from Adafruit_IO import Client

aio = Client("your_user", "AIO_KEY")
aio.send_data("temperature", 23.5)

Pricing

  • Free: 30-day data retention, 30 points per minute, 10 Feeds, 5 Dashboards
  • IO+: 10 USD per month, 60-day retention, 60 points per minute, unlimited Feeds and Dashboards

Blynk The mobile app builder is the signature. You drag widgets to build a device-control app. The free 1.0 era around 2018 gave way to Blynk IoT (2.0) cloud-based relaunch in 2021. Today it is a SaaS model.

Pricing

  • Free: 2 devices, 100 messages per day
  • Plus: 8.99 USD per month, 10 devices, 500 messages per day
  • Pro: 19.99 USD per month, 50 devices, 5,000 messages per day
  • Business: per-device pricing, white-label app support

Adafruit vs Blynk Decision Tree

  • Mobile app first → Blynk (drag-and-drop app builder)
  • Web dashboard is enough → Adafruit IO or Arduino Cloud
  • You want to buy hardware from Adafruit too → Adafruit IO
  • White-label mobile app → Blynk Business

Weaknesses (Common)

  • Scale ceiling is clear. Beyond about 100 devices, look elsewhere.
  • Almost no data analytics or AI integration.

One-Line Summary

Adafruit IO is the simplest IoT; Blynk is the fastest mobile app builder. Both are defaults for makers, hobbyists, and education; neither is for industrial scale.

9. ThingsBoard — The Open-Source Full-Stack Standard

Surface and Strengths A Java / Spring open-source IoT platform that started in 2017. Full-stack is the decisive trait — MQTT / CoAP / HTTP broker, device management, rule engine, dashboards, user and tenant management, and alarms, all bundled. An Apache 2.0 Community Edition coexists with a commercial Professional Edition.

Architecture

  • Core: Java Spring Boot, PostgreSQL or Cassandra (time-series)
  • Message queue: Kafka or built-in (for dev)
  • Rule engine: visual node-based editor (similar to Node-RED)
  • Dashboards: widget library + custom widgets

Device SDK Official SDKs: Python, Java, C (MQTT), JavaScript, Node.js. If you know MQTT, anything can connect. Device profiles abstract telemetry keys, attributes, and transport per device type.

Rule Engine — The Signature ThingsBoard's rule engine looks different from other platforms. Incoming messages flow through a node graph. Logic like "if temp greater than 80 then Slack alert + DB save + alarm" is drawn in a GUI, not coded.

[Device Telemetry Upload]
    ↓
[Filter: temperature > 80]
    ↓
[Save Timeseries] → [Create Alarm] → [Slack Webhook]

Thanks to the visual rule engine, non-developers can build operational policies.

Dashboards More than 50 built-in widgets. Custom widgets are written in JavaScript. White-labeling per tenant is supported.

Edge — ThingsBoard Edge Run part of the ThingsBoard core on an on-prem gateway or edge server, with two-way sync to the cloud. Fits gateways at industrial sites.

Professional Edition — Commercial Differentiator Community Edition is free, but advanced features (clustering, fine-grained RBAC, white-label, advanced alarms, OAuth2) are in Pro. Pro pricing is negotiated by instance, tenant count, and features.

Weaknesses

  • You have to operate Java, PostgreSQL, Kafka, and Cassandra. Operational burden is significant.
  • At very large scale (hundreds of thousands of devices), Cassandra tuning is required.
  • License split — know ahead of time which features are Community vs Pro.

One-Line Summary

The de-facto standard for open-source full-stack IoT. The default when you want to avoid cloud lock-in but still need a complete feature set. A strong choice if you have ops talent.

10. Balena (Formerly resin.io) — Docker-Based Fleet Management

Surface and Strengths Started as resin.io in 2013, rebranded as Balena in 2018. A fleet management platform that runs Docker containers on devices. Strong on Linux devices like Raspberry Pi, NVIDIA Jetson, BeagleBone, and Intel NUC. If you want to deploy, update, and monitor a hundred Raspberry Pis at once, Balena is almost the default.

The Balena Stack

  • balenaOS: Yocto-based minimal Linux OS that automates boot, update, and recovery
  • balenaEngine: Moby-based lightweight container runtime (Docker compatible)
  • balenaCloud: SaaS-form fleet management console
  • openBalena: open-source self-hostable version

Device SDK and Container Model There is no separate device SDK — the container itself is the SDK. Developers build their app as a Docker image and git push to Balena, which deploys it to devices.

# Balena's shortest workflow
balena push my-fleet
# The balenaCloud builder produces multi-arch images and rolls them out OTA

This simplicity is decisive. CI / CD ends at git push.

OTA and A / B Updates balenaOS has A / B partitions that automatically roll back on a failed update. Container-level updates are faster and safer.

Pricing — balenaCloud

  • Free: up to 10 devices, some features limited
  • Production: starts around 3 USD per device-month (annual commit)
  • Enterprise: negotiated

openBalena A fully open-source version. You can self-host an API-compatible backend to balenaCloud. Free, but with operational cost.

Weaknesses

  • Devices must be Linux SBC class (Raspberry Pi, Jetson). MCUs are not the target.
  • Container image size can strain bandwidth (especially over cellular).
  • balenaCloud is SaaS — to self-host, you use openBalena.

One-Line Summary

If you have to operate a hundred Raspberry Pis, Balena is the default. The most mature implementation of the philosophy that Docker containers replace IoT firmware.

11. Mainflux to Magistrala — Open Source Rebrand

The Mainflux Story A Go-based open-source IoT platform that started in 2016. Microservices architecture (MQTT broker, HTTP gateway, NATS message bus, PostgreSQL, Redis, InfluxDB, and so on) under Apache 2.0. Lightness and scalability were the strengths.

Why It Became Magistrala In 2024, Mainflux rebranded as Magistrala. Built by the same team (Abstract Machines), carrying the same architecture forward. The reasons: (a) trademark and legal cleanup, (b) positioning as an LF Edge friendly project, (c) new features (auth, policies) needing a fresh name.

Architecture

  • Core: Go microservices — each capability in its own container
  • Message bus: NATS (high-performance pub/sub)
  • Protocols: MQTT, HTTP, CoAP, WebSocket, OPC UA
  • Storage: PostgreSQL (metadata), InfluxDB or TimescaleDB (time-series)
  • Auth and policies: Magistrala's new policy engine (OPA-based)

What's New in Magistrala vs Mainflux

  • Integrated policy engine — fine-grained authorization on OPA (Open Policy Agent).
  • Cleaner domain model — Things, Channels, Domains, and Groups clarified.
  • LF Edge compatibility — integration story with Open Horizon and EdgeX.

Device SDK Standard MQTT / HTTP / CoAP get you connected. The philosophy is not to force a specific SDK.

Pricing Open source — free. Commercial support is negotiated with Abstract Machines.

Weaknesses

  • Weaker dashboards and rule engine than ThingsBoard. Visualization usually means bolting on Grafana.
  • Community is smaller than ThingsBoard's.
  • Some migration friction remains right after the rebrand.

One-Line Summary

A lightweight Go microservices IoT core. A strong choice if you weight backend over dashboards and are willing to bring your own visualization. The natural rallying point for LF Edge alignment.

12. Losant / Bosch IoT Suite / Schneider EcoStruxure — Enterprise

Losant A US-based enterprise IoT platform. Sells a bundle of device management, a visual workflow engine, dashboards, user management, and white-label options. Targets industrial IoT and mid-market. The workflow engine is the signature — you draw data processing, alerts, and integrations in a node-based GUI.

Pricing is based on devices and workflow executions. Quote on request.

Bosch IoT Suite The IoT platform run by Germany's Bosch. Specialized in automotive, Industry 4.0, HVAC, and building automation. A major contributor to Eclipse IoT projects (Ditto, Hono, Vorto, Kanto), Bosch builds its commercial stack on top of Eclipse.

  • Bosch IoT Things (Eclipse Ditto based) — digital twin.
  • Bosch IoT Hub (Eclipse Hono based) — device connectivity.
  • Bosch IoT Insights — analytics.
  • Bosch IoT Manager — device management.

Standing on Eclipse means less closed. Pricing is enterprise negotiation.

Schneider Electric EcoStruxure France's Schneider Electric's IoT and OT integration platform. Domains: power, HVAC, building automation, industrial automation. Domain depth is the differentiator.

  • EcoStruxure Building Advisor — building operation optimization.
  • EcoStruxure Power Monitoring Expert — power monitoring.
  • EcoStruxure Asset Advisor — predictive maintenance.
  • EcoStruxure Augmented Operator Advisor — AR-assisted operations.

Pricing usually negotiated through system integrators (SIs).

Enterprise Decision Tree

  • General industrial IoT, large internal domain → Losant or Bosch IoT Suite
  • Automotive, Industry 4.0 → Bosch IoT Suite
  • Power, HVAC, buildings → Schneider EcoStruxure
  • Already on AWS or Azure → AWS IoT + SiteWise or Azure IoT Hub + Digital Twins

Common Weaknesses

  • Opaque pricing. Per-device cost is hard to know.
  • Heavy SI dependence — building it out with internal teams alone is often hard.
  • Some are awkward outside of their core domain.

One-Line Summary

Where you go when industrial domain models and OT integration matter. For deep domains like automotive, power, and buildings, they create value faster than AWS or Azure. Pricing is a negotiation game.

13. Edge Runtimes — Azure IoT Edge / AWS Greengrass / Open Horizon / KubeEdge

Why Edge Runtimes Are Their Own Category Devices need to run code, containers, and ML models. The "send all data to the cloud" model has clear limits in (a) bandwidth, (b) latency, and (c) offline operation. That is why edge runtimes are a separate category.

Azure IoT Edge Docker (Moby) container runtime. Module-based deployment. edgeAgent and edgeHub are the two system modules. Stream Analytics, Function App, and Custom Vision are offered as modules. The strength is a device twin and routing model consistent with the cloud.

AWS Greengrass v2 Component-based. Your components combine with built-in ones (StreamManager, Lambda, Docker, ML, CLI). Running Lambda functions directly on the device is the signature. The ML inference component deploys SageMaker Neo models.

Open Horizon (LF Edge) An open-source edge orchestrator that IBM donated to LF Edge. Autonomous and policy-driven — assign a policy to a device and matching workloads deploy automatically. The differentiator is no cloud dependency. Designed to target a million devices.

KubeEdge (CNCF) A CNCF graduated project that extends Kubernetes to the edge. It treats devices like K8s nodes, and you deploy workloads with kubectl. Cloud-side (CloudCore) and edge-side (EdgeCore) components coordinate. Natural for teams already running K8s.

Comparison Table

ItemAzure IoT EdgeAWS Greengrass v2Open HorizonKubeEdge
LicenseMIT (core)Apache 2.0Apache 2.0Apache 2.0
Cloud DependencyAzureAWSNone (autonomous)None (your K8s)
Device ModelDocker containersComponents + LambdaContainers + policiesK8s nodes
Target Devicestens of thousands to hundreds of thousandstens to hundreds of thousandsa million plushundreds of thousands
SignatureDevice TwinLambda on EdgePolicy-based autonomous deploykubectl for devices

Selection Guide

  • Already on Azure → Azure IoT Edge
  • Already on AWS, comfortable with Lambda → AWS Greengrass
  • Avoid cloud lock-in, target massive autonomous deployment → Open Horizon
  • Already run K8s, want devices as K8s nodes → KubeEdge

Edge runtime choice can be partially decoupled from IoT platform choice. Running AWS IoT Core while operating the edge on KubeEdge is a legitimate combination.

14. Protocols — MQTT 5.0 / CoAP / AMQP / OPC UA / LoRaWAN / Sigfox

MQTT 5.0 — De-Facto Standard MQTT is the default IoT protocol. The move from 3.1.1 to 5.0 added (a) User Properties (metadata), (b) Reason Codes (clearer errors), (c) Shared Subscriptions (load balancing), (d) Message Expiry, and (e) Flow Control. After GA in 2024, every major platform supports 5.0 as of 2026.

CoAP — REST's IoT Cousin UDP-based, HTTP-like methods (GET / POST / PUT / DELETE), and the Observe pattern. So lightweight it fits (a) battery- and memory-constrained devices and (b) 6LoWPAN / Thread networks. AWS IoT Core, Magistrala, and ThingsBoard all support it.

AMQP — Enterprise Message Queue RabbitMQ and Azure Service Bus represent the category. More an enterprise message queue standard than an IoT-first one. Azure IoT Hub offers AMQP as one option. Heavier than MQTT but with richer message semantics.

OPC UA — Industrial Automation Standard The standard for pulling data from PLCs and SCADA on factory and plant floors. AWS IoT SiteWise, Azure IoT Operations, and middleware like KEPServerEX convert it to MQTT / AMQP for the cloud. The default for industrial IoT.

LoRaWAN — Low-Power Wide-Area Send once a day, run on a battery for years. Strong in agriculture, asset tracking, and city infrastructure. LoRaWAN network servers like The Things Network and ChirpStack ship data to AWS and Azure. AWS offers IoT Core for LoRaWAN directly.

Sigfox — Ultra-Low-Power Wide-Area, Business Shakeup Sigfox SA went bankrupt in 2022 and was acquired by UnaBiz. As of 2026, the network is up, but the future is uncertain. New projects should consider LoRaWAN or NB-IoT as safer choices.

Protocol Decision Tree

  • General IoT devices → MQTT 5.0
  • Very constrained devices, IPv6 / Thread → CoAP
  • Enterprise message-queue integration → AMQP
  • Factories and plants → OPC UA
  • Agriculture, asset tracking, low power → LoRaWAN
  • Cellular wide-area low-power → NB-IoT or LTE-M (avoid new Sigfox projects)

15. Korea and Japan — Home-Market IoT Clouds

Samsung SmartThings Cloud Samsung's consumer / home IoT platform. Evolving with the Matter standard. Strength is appliances and home devices. From 2024, SmartThings Pro extends into commercial buildings. Third-party integration goes through the SmartThings API.

LG ThinQ Cloud LG's consumer IoT platform. Strong on appliances (refrigerators, washers, air conditioners). ThinQ AI — voice and image models — is integrated with appliances. The LG Open Platform is partially open to third-party developers but limited.

KT IoT KT's LTE-M / NB-IoT cellular IoT platform. The center of LPWA networks in Korea. Linked to AWS and Azure via partnerships. Strong in industrial and infrastructure (gas, power, water).

SK Telecom and LG U+ Each runs its own IoT platform, but their IoT-dedicated brand presence is weaker than KT's. SKT is shifting toward ifland, metaverse, and AI; LG U+ focuses on home and media.

Sony Edge AI Sony Semiconductor Solutions' edge AI platform. Runs AI inference inside camera sensors like IMX500 and IMX501. The camera is the IoT device. On the cloud side, AITRIOS is a SaaS for fleet management.

NEC IoT NEC's industrial IoT and smart city platform. Strong in Japanese government and municipal projects. Bundling facial recognition and biometrics with IoT is the signature.

Hitachi Lumada Hitachi's industrial IoT and digital platform. Specialized in automotive, rail, power, and water. Deep OT assets are the differentiator. AWS and Azure partnerships also exist.

NTT Communications and NTT Data Japan and Asia telecom operator. Bundles cellular IoT circuits (NTT Docomo LTE-M / NB-IoT) with the cloud (NTT Com Enterprise Cloud). A rival to Particle in global cellular IoT.

Patterns in Korea and Japan

  • Consumer IoT belongs to home-grown appliance brands (Samsung, LG, Sony, Panasonic).
  • Cellular IoT belongs to carriers (KT, NTT) in their home markets.
  • Industrial IoT is taken by integrated electric and heavy industry players (LG CNS, Hitachi, NEC) as SI engagements.
  • AWS and Azure are still the default for multinationals and startups in Korea and Japan, but in home telecom and industrial layers, local platforms dominate.

Look only at global platforms and you miss half of the local market. Anyone running an IoT project in Korea or Japan must also evaluate domestic carrier, appliance, and SI IoT assets.

16. Who Should Pick What — Decision Tree by Scenario

Scenario A — DIY Maker / Student / 1 to 10 Devices

  • Minimum budget, minimum learning curve → Adafruit IO or Arduino Cloud
  • Mobile app first → Blynk
  • Want your own infra and willing to learn → ThingsBoard Community Edition + Raspberry Pi
  • Almost no code, just variables → Arduino Cloud + IoT Cloud Editor

Scenario B — Startup / 100 to 10,000 Devices

  • Wi-Fi devices, AWS infra → AWS IoT Core
  • Cellular devices, global → Particle
  • Avoid lock-in, have ops team → ThingsBoard PE or Magistrala + your own cloud
  • Raspberry Pi fleet → Balena
  • Low message volume, simplicity first → Adafruit IO+ (though 10K is the ceiling)

Scenario C — Enterprise / 10,000 to 1,000,000 Devices

  • Industrial IoT, on AWS → AWS IoT Core + Greengrass + SiteWise
  • Industrial IoT, on Azure → Azure IoT Hub + Edge + Digital Twins
  • Automotive, Industry 4.0 → Bosch IoT Suite
  • Buildings, power, HVAC → Schneider EcoStruxure
  • Avoid cloud lock-in, target 1M+ → Open Horizon or KubeEdge + open-source core
  • Already on K8s → KubeEdge + EMQX / HiveMQ + InfluxDB / TimescaleDB

Scenario D — Cellular IoT Operator

  • Global cellular fleet → Particle
  • Korean LPWA → KT IoT
  • Japanese cellular → NTT Communications
  • Cellular + AWS → AWS IoT Core for LoRaWAN + your own SIM
  • Cellular + Azure → Azure IoT Hub + Azure SIM

Scenario E — Consumer Appliance / Smart Home

  • Korean appliance integration → Samsung SmartThings or LG ThinQ
  • Japanese appliance integration → Sony AITRIOS or local brand APIs
  • Global smart home → Matter standard + managed of your choice (separate article)

Five Wrong Signals When Choosing

  1. Only looking at benchmark messages per second. In real operations, device management, rule engine, and dashboards matter more.
  2. Only looking at free tiers. Many platforms see costs explode as device counts grow. Estimate the bill at 10K devices.
  3. Only considering hyperscalers. If you are not ready for lock-in, redo the math on operating open source.
  4. Ignoring local platforms. In Korea and Japan, domestic carrier, appliance, and SI providers hold decisive assets.
  5. Picking only one platform. Combinations are common — AWS IoT Core + ThingsBoard dashboards, or Particle + an Azure backend.

17. Anti-Patterns — Common Mistakes

  1. Picking the hyperscaler by default. "We use AWS, so AWS IoT" sometimes fits, but depending on device count, message rate, and analytics depth, a different choice is often cheaper and simpler.
  2. Forgetting that Google left. Big tech has retired IoT services before. That is reason to fear lock-in. Keep ingestion on standard protocols (MQTT 5.0) and storage in standard formats (JSON / Parquet) so migration stays easy.
  3. Not estimating cellular cost. Device-month data fees are often five to ten times the IoT platform fee. Looking only at the cloud bill misses real cost.
  4. Adding edge runtime late. Bolting on edge processing after devices scale forces an architecture redesign. Decide up front whether you need edge processing.
  5. Bolting on device security after the fact. Turn on AWS IoT Device Defender, Azure Defender for IoT, ThingsBoard OAuth2, and equivalents from day one. A breach at a million devices costs 1000x more.
  6. Underestimating open-source operational cost. Running ThingsBoard, Magistrala, or EMQX yourself needs SRE, DBA, and security headcount. Calculate the true cost vs managed.
  7. Forgetting protocol lock-in. Depending on AWS's non-standard MQTT extensions (such as HTTP-MQTT bridging) makes migration painful. Enforce standard MQTT 5.0.

18. What's Next — and Conclusion

In the next article we look at Matter and Smart Home IoT 2026 — the Matter compatibility status of Samsung SmartThings, Apple Home, Google Home, and Amazon Alexa, and the picture of consumer IoT consolidating around five big-tech players. After that, OPC UA + Industrial IoT Deep Dive — the actual architecture for pulling data from PLCs and SCADA on factory and plant floors into AWS IoT SiteWise and Azure IoT Operations.

Key Takeaways

  • Only AWS and Azure remain as hyperscaler IoT. Google IoT Core (Aug 2023) and IBM Watson IoT (Aug 2024) are gone.
  • Managed IoT fragmented into Particle (cellular), Arduino Cloud (makers), and Adafruit IO and Blynk (hobby).
  • Open source consolidated around ThingsBoard (full stack), Balena (Docker fleet), and Magistrala (Mainflux successor).
  • Enterprise belongs to Bosch IoT Suite, Schneider EcoStruxure, and Losant by domain.
  • Edge runtimes are four: Azure IoT Edge, AWS Greengrass, Open Horizon, and KubeEdge.
  • MQTT 5.0 is the protocol standard. OPC UA owns industrial. LoRaWAN owns LPWA.
  • Korea and Japan: domestic telecom, appliance, and SI players (KT, NTT, Samsung, LG, Sony, Hitachi) hold half their home market.

The essence of IoT in 2026 is not "which hyperscaler do you pick" but "where do you stand on device count, data sovereignty, lock-in aversion, and ops headcount." The 18 platforms each sit at a specific point in this four-axis space. Know your own coordinates accurately and the answer narrows to three.

References

Discuss on Twitter • View on GitHub