Qubitro vs AWS IoT Core
A managed device-connectivity and message-routing layer from AWS: an MQTT broker, a device registry, shadow state and a rules engine that fans messages out to other AWS services.
AWS IoT Core and Qubitro are often compared as though they were the same kind of product. They are not. IoT Core is a connectivity and routing layer — an MQTT broker, a device registry, Device Shadow, an auth layer, and a Rules Engine that fans messages out to around twenty other AWS destinations. AWS describes it that way itself: connect devices securely to the cloud. Qubitro is a finished platform: ingest, time-series storage, dashboards, alerting and white-label portals in one product.
The practical consequence is what IoT Core leaves to you. There is no built-in time-series store, no dashboards and no alerting UI. Device Shadow holds an 8 KB document by default and is a state-sync primitive rather than storage. Anything you want to look at tomorrow gets routed into another service that you choose, wire up, secure and pay for separately. That was always the design, but the menu around it has narrowed: AWS IoT Analytics and AWS IoT Events have both reached end of support, Fleet Hub was decommissioned in October 2025, and Timestream for LiveAnalytics — the one time-series sink the Rules Engine writes to directly — has been closed to new customers since June 2025. Timestream for InfluxDB is the recommended replacement and is open to new customers, but no rule action writes to it, so that hop is yours to build.
None of that makes IoT Core the wrong choice. If you already run on AWS, if your buyer needs a named SLA and an existing master agreement, or if you are shipping firmware to a few hundred thousand microcontrollers and want FreeRTOS, Greengrass and Jobs OTA from one vendor, take AWS IoT Core. The honest comparison is about scope, not savings. IoT Core is a component library for teams building a platform. Qubitro is the platform for teams who would rather ship the project.
What AWS IoT Core does well
- Broker scale very few platforms match — published quotas in the hundreds of thousands of concurrent connections per account, five-figure publishes and rule evaluations per second, most of them raisable on request
- A deep MQTT 5 implementation: shared subscriptions, reason codes on every ACK, session and message expiry, user properties, topic aliases, and cross-version routing so MQTT 3 publishers and MQTT 5 subscribers exchange messages. QoS 2 is not supported and a persistent session cannot be resumed across versions, but little in the field needs either
- Auth flexibility with no real equal: X.509 with AWS-issued certs, your own CA or JITP, IAM SigV4, Cognito, Lambda-backed custom authorizers, and a credentials provider that lets a device call other AWS services directly
- Rules Engine breadth — around twenty destinations with no glue code, in-SQL enrichment and per-rule error actions, plus Basic Ingest, which skips the pub/sub broker entirely and carries no messaging charge
- The device-side story end to end: FreeRTOS, device SDKs, Greengrass v2 for edge compute and offline buffering, fleet provisioning, Jobs and OTA, secure tunnelling, and Device Advisor for pre-production conformance testing
Side by side
| AWS IoT Core | Qubitro | |
|---|---|---|
| Scope | Connectivity and message routing; you assemble the platform on top | Ingest, storage, dashboards, alerting and portals in one product |
| Time-series storage | None built in — route messages out to another AWS service; Shadow holds roughly 8 KB of state | Included, with configurable retention and archived views |
| Dashboards and alerting | No dashboard or alerting UI — a rule can raise a CloudWatch alarm or send an SNS notification, and the console has an MQTT test client; anything user-facing is yours to build | Pre-built per device template, then customisable |
| Device templates | Managed integrations focused on Matter and smart home | 291 templates across 58 manufacturers, each with decoder and starter dashboard |
| LoRaWAN | IoT Core for LoRaWAN — a managed network server, billed separately | Bring your own — The Things Stack, Actility, Senet, LORIOT, ChirpStack, or AWS IoT Core for LoRaWAN |
| Custom logic | Rules Engine SQL, then Lambda for anything beyond it | JavaScript functions and JSONata expressions |
| White-label | Not a product feature; the end-user portal is yours to build | Custom domain, branding and per-tenant theming |
| Pricing model | Connection minutes, messages by size increment, rule triggers and actions, shadow and registry operations — then each downstream service on its own bill | Per device, from $2/device/month, free tier available |
Choose AWS IoT Core if
- You are already an AWS shop. IoT data landing natively in the S3 data lake, Redshift or SageMaker pipeline you already run, with no egress and no extra vendor, is an advantage nobody else can match
- Procurement or compliance decides it: AWS Marketplace, an existing MSA, enterprise support, a published SLA with service credits, Artifact audit reports, GovCloud, or a security review a small vendor will not clear
- You need the device and edge stack, not just the cloud side. FreeRTOS plus Greengrass v2 plus fleet provisioning plus Jobs OTA plus secure tunnelling is a coherent whole for a fleet you will maintain for eight years
- Very large fleets with hard scale ceilings, deep MQTT 5 semantics such as shared subscriptions, custom authorizers, your own CA or PrivateLink-only ingress — with a platform team already fluent in Terraform, IAM and CloudWatch to operate it
Choose Qubitro if
- You want the platform finished rather than assembled — storage, dashboards, alerting and retention working on day one, without first choosing a time-series sink and wiring rules into it
- You bill a customer per device and need a number you can quote, rather than a figure you can only forecast after modelling your topic topology and duty cycle
- You onboard the same commercial LoRaWAN and cellular hardware repeatedly and would rather the decoder and starter dashboard were already written
- White-label with a custom domain per customer is central to how you sell, and you have no platform team to build and run a portal for it
Common questions
- Can Qubitro sit on top of AWS IoT Core instead of replacing it?
- Yes, and for AWS shops that is often the sensible arrangement. An IoT Core rule with an HTTPS action can post into Qubitro over the REST API or a webhook, and AWS IoT Core for LoRaWAN is one of the network servers Qubitro integrates with. IoT Core stays the broker, the auth boundary and the device-management layer; Qubitro becomes the storage, dashboard and customer-facing layer you would otherwise assemble from other AWS services.
- Is AWS IoT Core cheaper than Qubitro?
- There is no honest blanket answer. IoT Core is metered on connection time, message count in size increments, rule triggers and actions, and shadow and registry operations — then again on every AWS service the rules write into, and again on Device Management if you use Jobs, OTA, fleet indexing or secure tunnelling. It is genuinely inexpensive for low-duty-cycle telemetry through Basic Ingest and genuinely expensive for chatty, always-connected fleets with high fan-out. Qubitro is priced per device from $2 per device per month, which is easier to quote to a customer before the first device connects.
- What happened to AWS IoT Analytics, IoT Events and Fleet Hub?
- They are gone. IoT Analytics reached end of support in December 2025, IoT Events in May 2026, and Fleet Hub was decommissioned in October 2025 with its functionality folded into the Device Management console. Timestream for LiveAnalytics has been closed to new customers since June 2025. IoT Core itself carries no lifecycle notice and is still gaining features — this is the surrounding analytics menu narrowing, not the connectivity layer going away.
The fastest way to judge this is to connect one device. The free tier needs no card, and if your hardware is in the template library you will have a dashboard in minutes.