A fleet of 500 devices will forgive almost any architecture. You can run a Mosquitto broker on a single VM, dump telemetry into Postgres, and push firmware over SSH when someone complains. It works. We have seen it work for years.
Then the fleet hits 10,000 units and everything that was a minor annoyance becomes an incident. Devices reconnect in a thundering herd after a network blip. A firmware rollout bricks 4% of a batch and you have no way to halt it mid-flight. Someone asks which devices are on which firmware version in which country, and the honest answer is "give us two days." That is the point where a managed device management platform stops being overhead and starts being the cheaper option.
This piece compares AWS IoT Core, Azure IoT Hub, and what is actually left of Google's IoT offering — plus the case for skipping all three. We build IoT backends and firmware update pipelines for clients in the US, UK, Europe and the Middle East, and the decision usually comes down to fewer factors than vendor comparison tables suggest.
What "device management at scale" actually has to cover
Before comparing platforms, get specific about the capability list. Most teams evaluate on telemetry ingestion because that is the visible part, then discover six months in that the hard problems were elsewhere.
- Identity and provisioning — how a device gets a unique credential during manufacturing or first boot, without a human typing anything, and how you revoke it when a unit is stolen or resold.
- Connectivity and session handling — MQTT over TLS, keepalives, backoff behaviour, and what happens when 10,000 devices all reconnect within the same 30 seconds.
- State synchronisation — a durable server-side view of each device's desired and reported configuration, so a device that was offline for a week converges on the right settings when it wakes up.
- OTA updates — signed artefacts, staged rollouts, progress reporting, automatic rollback on failure metrics, and delta updates when your cellular data budget is tight.
- Fleet operations — querying and grouping thousands of devices by attribute, running bulk commands, and scheduling maintenance windows.
- Observability and security posture — per-device connection logs, certificate expiry tracking, anomaly detection on behaviour.
- Data landing and analytics — routing telemetry into time-series storage, a warehouse, and whatever ML you plan to run on top.
Only three of those seven are about moving messages. That imbalance is the whole point.
The GCP question, answered up front
Google Cloud IoT Core was retired on 16 August 2022. If you find a comparison article that puts it in a three-way table as a live product, that article is out of date, and you should treat everything else in it with suspicion.
That does not mean Google Cloud is off the table for IoT. It means the device-facing layer is no longer Google's. There are two realistic paths:
- ClearBlade IoT Core — a partner product built to be API-compatible with the retired Google service, which is what most migrating teams moved to because it minimised firmware changes.
- Bring your own broker — run EMQX, HiveMQ, VerneMQ or a similar MQTT broker on GKE, terminate device TLS there, and publish into Pub/Sub, then Dataflow and BigQuery.
The second path is more common than people expect, and for a specific reason: if your real centre of gravity is analytics, BigQuery and Vertex AI are genuinely excellent, and a broker on Kubernetes is a solved problem. What you take on is the device management layer — provisioning, twin state, OTA orchestration, jobs — which you now own as application code. Budget for that honestly. It is not a sprint. It is a product inside your product, and it needs an owner for as long as the fleet exists.
AWS IoT Core
AWS has the broadest device management surface of the three, and it is assembled from a lot of separate services rather than one monolith. That is both the strength and the tax.
Device-side, you get MQTT over mutual TLS with X.509 certificates, MQTT over WebSockets with SigV4, and HTTPS publish. Topic structure is genuinely free-form, which matters more than it sounds — you can design a topic hierarchy that mirrors your fleet's real shape and use topic filters for routing. Fleet Provisioning handles the manufacturing problem: devices ship with a claim certificate and exchange it for a permanent one on first connect, with a Lambda hook so you can validate against your own manufacturing database before issuing.
Device Shadow gives you the desired/reported state document, including named shadows so you can separate, say, network config from application config and keep payloads small. The Rules Engine lets you write SQL-ish statements against inbound messages and fan out to DynamoDB, Kinesis, Lambda, SNS, Timestream, S3 and more, with Basic Ingest available to skip the pub/sub charge when a message only exists to feed a rule. Jobs handles OTA and remote operations with rollout rate limits and abort criteria. Fleet Indexing lets you query the fleet by shadow contents and connectivity state — that is the service that answers the "which devices are on which firmware" question in seconds.
Add Device Defender for behavioural anomaly detection and audit checks, Greengrass for edge compute, and IoT Core for LoRaWAN if you have non-IP devices. It is a lot of capability. It is also a lot of IAM policy to get right, and the billing has several independent meters — connection time, messaging, rules executions, registry and shadow operations, jobs — which makes forecasting genuinely harder than on Azure.
Azure IoT Hub
Azure's model is more opinionated, and for a lot of teams that is a feature. IoT Hub plus the Device Provisioning Service (DPS) covers identity and enrolment with symmetric keys, X.509, or TPM attestation, and DPS can allocate devices across multiple hubs by geography or by custom logic. That multi-hub allocation is one of Azure's quiet advantages for globally distributed fleets and data-residency requirements.
State lives in the device twin — desired properties, reported properties, and tags — plus module twins if you are running IoT Edge. Direct methods give you request/response commands with a timeout, which is cleaner than hand-rolling a command/ack pattern over topics. Message routing sends telemetry to Event Hubs, Service Bus, Blob Storage or Cosmos DB based on message properties or body content. Device Update for IoT Hub covers OTA with both image-based and package-based update models, including deployment groups and rollback.
The trade-off is MQTT fidelity. IoT Hub supports MQTT 3.1.1 but not as a general-purpose broker: topics are fixed to Azure's own schema, QoS 2 is not supported, and there is no device-to-device pub/sub. If your firmware already speaks arbitrary-topic MQTT, expect an adaptation layer. In exchange, the pricing model is far easier to reason about — you buy units in a tier, each unit carries a daily message allowance and a message-size metering unit, and you scale by adding units. For a finance team that wants a predictable line item, that clarity is worth real money.
Worth knowing: Azure IoT Central sits above IoT Hub as a much faster path to a working solution if your requirements are conventional, and Azure has been pushing newer Arc-based operational offerings for industrial edge scenarios. Check current product status before you commit — this part of Azure's portfolio has moved around.
Where the decision actually gets made
After running these evaluations a number of times, the deciding factors are rarely the feature matrix. They are these:
- Your existing cloud. If your data platform, identity provider and DevOps pipeline are already on one cloud, the IoT platform on that cloud wins on integration cost alone. This dominates almost everything else.
- Firmware constraints. Free-form MQTT topics and an existing broker-style firmware push you toward AWS. A greenfield SDK-based firmware makes Azure's opinionated model painless.
- Provisioning at manufacture. If units are built by a contract manufacturer you do not fully control, look hard at both AWS Fleet Provisioning and Azure DPS enrolment groups before choosing. This is the step that most often forces a firmware respin later.
- Data residency. Multi-hub allocation via DPS is a clean answer for EU and Middle East residency requirements. On AWS you achieve the same with per-region endpoints and more of your own routing logic.
- Analytics ambition. If the fleet exists mainly to feed models, the pull toward BigQuery — and therefore a bring-your-own-broker design — is legitimate. We build these hybrid stacks, and the AI and ML side of the work usually justifies the extra device-layer effort.
- Team shape. A three-person team should not own a custom device management layer. A twelve-person team with a platform engineer can.
When you should not use any of them
We will say this plainly because vendors will not. Under roughly a thousand devices, with infrequent firmware updates and no strict compliance requirement, a managed IoT platform is often more complexity than it saves. A hardened EMQX or HiveMQ cluster, TimescaleDB or InfluxDB for telemetry, and a simple signed-manifest OTA flow will serve you well and cost less. ThingsBoard is a reasonable open-source option if you want a dashboard and rule engine bundled in.
The signals that you have outgrown that setup are specific: you need staged rollouts with automatic abort; you cannot answer fleet-state questions without writing a script; provisioning has become a manual step in manufacturing; or an auditor has asked how you rotate device credentials. Any two of those together, and the managed platform pays for itself.
Patterns that keep a 10,000-device fleet stable
Platform choice matters less than these habits. They apply identically on all three stacks.
- Randomise reconnect and telemetry timing. Add jitter to backoff and to publish intervals. Without it, a single regional outage turns into a synchronised reconnect storm that looks like a DDoS against your own endpoint.
- Batch and compact telemetry. Both AWS and Azure meter messages in size blocks, so ten tiny payloads per minute cost far more than one batched payload. Design payloads to the metering unit, and use CBOR or Protobuf rather than verbose JSON on constrained links.
- Treat shadow/twin as configuration, not as a database. Keep documents small, split them by concern, and never use them as a telemetry store.
- Roll out firmware in cohorts with hard abort criteria. Start with internal units, then 1%, then a region, with automatic halt on failure-rate thresholds. Always ship a rollback path and a watchdog-protected bootloader — the platform cannot save a device that cannot boot.
- Version your topic and payload schemas from day one. Devices in the field will run old firmware for years. Your backend must handle three schema generations simultaneously.
- Track certificate expiry as a first-class operational metric. Long-lived device certificates expire quietly and then all at once.
None of this is exotic, but it has to be designed in early. Retrofitting staged rollouts onto a fleet that already has 10,000 units in the field is a much harder project than building them in at 500 units.
How we approach these builds
We usually start with a two-week discovery: fleet growth curve, firmware constraints, manufacturing process, compliance and residency needs, and the analytics you actually want in year two. That produces a platform recommendation with a cost model built from current published pricing rather than a guess, plus a reference architecture for provisioning and OTA. From there we either build it end to end or embed engineers alongside your firmware team — a dedicated team arrangement works well here, because device work has long feedback loops and continuity matters more than raw headcount.
If you are weighing these platforms for a fleet that is about to grow past the point where manual operations hold up, we are happy to look at the specifics with you. Have a look at the kind of work we do, then get in touch and tell us about your devices, your growth plan, and what is currently breaking.
