AWSIoTCorevsAzureIoTHub:DoestheChoiceMatter?

Introduction

The pilot works. Forty devices, a Mosquitto broker on a virtual machine somebody set up in an afternoon, a Grafana dashboard that looks good enough for the board deck. Then manufacturing says the first real production run is ten thousand units, and someone senior asks which platform you are standardising on.

That question commits the company for years, and every page you open to answer it is a table of checkmarks.

We have read the same comparisons you have. Review aggregators rating both platforms out of five, vendor documentation answering only for its own product, agency posts that arrive at "it depends on your requirements" without ever saying what it depends on. None of them tell you the thing you actually need, which is whether this decision deserves the three weeks you are about to give it.

It mostly does not. Here is what does.

> The broker is the part of an IoT stack that everybody benchmarks and almost nobody has trouble with. We have never once been called in because the broker could not cope.

For the wider architecture around this decision, our IoT platform development guide covers ingestion, edge and tenancy patterns in more depth. This page is about one choice.

What Is AWS IoT Core, and Is It Actually an MQTT Broker?

It contains one. Calling it a broker and stopping there undersells what you are signing up for, and that gap is where the surprises live.

AWS IoT Core is four things wearing one name. A managed message broker speaking MQTT 3.1.1 and MQTT 5, plus HTTPS and WebSocket. An identity system where every device gets an X.509 certificate and a policy. A rules engine that reads messages with a SQL-like syntax and routes them into other AWS services. And a device shadow, which is a JSON document holding each device's reported and desired state so your application can read a device that is currently offline.

Only the first of those is standard. The other three are AWS shaped, and that matters more than the feature list suggests.

On the serverless question, yes, in the way that counts. There is no broker cluster to size or patch, and billing is metered by activity rather than by a running instance, broadly across messages, connection time, registry and shadow operations, and rules triggered. That has a consequence people meet the hard way. A firmware bug that publishes every second instead of every minute produces a cost curve that follows the bug, and no part of the architecture stops it. Put alarms on message volume while the fleet is small.

Basic Ingest, which turns up in searches often enough to be worth a line, is simply a way to send messages straight into the rules engine without paying the messaging step. Useful, and not a different product.

What Is Azure IoT Hub, and How Is It Different?

Same job, different philosophy. Azure IoT Hub is the connectivity and identity layer of a stack that Microsoft designed as a set, rather than a box of primitives you assemble yourself.

The named pieces around it are the tell. Device Provisioning Service handles getting identity onto a device at manufacture without hardcoding a hub endpoint. IoT Edge runs modules on gateway hardware. IoT Central is a finished application platform sitting on top for teams who want dashboards and rules without building them. Digital Twins models relationships between devices and the physical spaces they sit in.

The device twin is the direct counterpart to the AWS device shadow, and the two solve the same problem with the same JSON-document shape. If you have used one, the other will feel familiar within a day.

Billing differs in kind rather than degree. IoT Hub sells provisioned tiers with daily message allowances, so you buy a shape of capacity and fill it. Steady, predictable traffic that fills a tier is efficient under that model. Bursty traffic pays for headroom it uses occasionally. AWS meters activity, so cost tracks usage closely and a misbehaving fleet shows up faster. Neither is cheaper in the abstract, and anyone telling you one wins on cost without seeing your message pattern is guessing.

What Differs Between AWS IoT Core and Azure IoT Hub?

Less than the comparison tables imply, and the differences that exist are mostly about assembly rather than capability. Both speak MQTT. Both do per-device identity. Both handle fleets far larger than yours will be for years.

Read the last row twice. In almost every engagement we have taken on, the cloud was chosen before anyone opened an IoT comparison. The identity provider is there, the data warehouse is there, the compliance paperwork is signed, and the team knows the console. Picking the other vendor's IoT service means running two clouds to save nothing.

That is not a cop-out answer. It is the answer, and the comparison pages bury it because "use the cloud you already have" does not fill two thousand words.

Does the Choice Actually Matter?

Less than you fear, and the reason is structural rather than reassuring.

MQTT is an open standard. A device publishes a payload to a topic and has no idea which company operates the thing receiving it. Point it at a different hostname, give it a different certificate, and it carries on. That is the whole migration at the device layer, and it is why the connection is the most portable part of your stack.

So the three weeks spent choosing a broker are buying a decision that is largely reversible. Meanwhile the decisions that are not reversible get made in the first sprint after, by whoever is closest to the keyboard, without a meeting.

Here is the shape of it in practice. A team deliberates for a month, picks AWS, and then a developer writes eleven rules engine statements containing business logic, has the application read the device shadow directly, and parses the vendor payload envelope in forty places. Eighteen months later somebody asks what leaving would cost, and the answer has nothing to do with the broker.

We have never been called in to move a fleet because the broker was wrong. We have been called in because everything built on top of it had grown into the vendor.

Where Does the Lock-In Come From?

Four places, and the broker is not one of them.

The rules engine. Its routing syntax and its bindings to cloud-native services have no equivalent anywhere else, so every rule gets rewritten by hand on migration. Rules that only route are quick to redo. Rules carrying business logic are a rewrite of logic nobody has documented, because it never felt like code.

The device shadow or twin. The concept is portable and the implementation is not. Once application code reads and writes that document directly, you have taken a hard dependency on a proprietary state store, and it will be spread across your codebase rather than sitting behind one interface.

The provisioning flow. This is the one that genuinely traps people. Getting identity onto a device at the factory is baked into firmware, and firmware on units already boxed and shipped is not something you revise over a sprint. A provisioning decision made in month two constrains you for the service life of every device manufactured after it.

The telemetry you have already stored. A year of readings in a vendor time-series store has real gravity. Moving it costs egress and engineering, and keeping it means keeping a foot in the old cloud. This is the reason migrations stall halfway more often than any technical blocker.

None of these are arguments against picking a platform. They are arguments for knowing which of your decisions are cheap and which are permanent, because the expensive ones do not announce themselves.

What Breaks First as the Fleet Grows?

Not the thing you are benchmarking. Every platform on your shortlist handles the connection counts you are worried about, and connection count is the number vendors publish precisely because it is the one they all win.

We build and run this class of system, including a fleet platform tracking 30,000+ vehicles and a real-time GPS platform serving 10M+ requests a minute. Across those, three things fail first, and none of them is throughput.

The storage cost curve. Telemetry retained at full resolution grows as devices multiplied by frequency multiplied by time, which is linear in a way that feels harmless at pilot scale and does not stay harmless. The pilot has forty devices and a month of history. Production has ten thousand devices and a compliance requirement to keep three years. That is not a bigger bill, it is a different bill, and the fix is a downsampling and retention policy designed before the data exists rather than after somebody escalates it.

Fleet-wide firmware updates. Updating a hundred devices is a script. Updating ten thousand devices that are moving, intermittently connected and occasionally powered off mid-write is a staged rollout problem with cohorts, health checks and a rollback path. Teams that treat over-the-air updates as a feature to add later discover the hard version of it, which is a bad update on a fleet with no way back.

Certificate expiry. The quiet one. Certificates issued at manufacture have an expiry date, and devices in the field cannot always be reached to rotate them. A fleet without a rotation path has an outage already scheduled, and the date is written on the certificates. We have watched teams find this out with weeks of notice rather than months.

For how these constraints translate into build effort and team shape, see our IoT app development cost drivers, and for two worked examples the 30,000 vehicle fleet build and the real-time GPS platform.

Do You Need a Managed IoT Platform at All?

A good number of teams reading this do not, and we would rather say so than sell you architecture you will not use.

If you have a few hundred devices reporting on a schedule, no requirement to push firmware remotely, and no need for per-device identity beyond one credential per unit, a managed MQTT broker or a self-hosted Mosquitto behind TLS will carry you for years. Not as a stopgap. As the actual answer.

The managed platforms start earning their keep when several things arrive together: per-device identity you have to audit, fleet-wide updates, staged rollouts, device state your application reads while devices are offline, and a compliance requirement that someone external will check. That bundle is what you are buying. Buying it before you have those problems means paying in operational surface and vendor coupling for machinery nobody on the team is using.

The tell is simple. If you cannot name which of those five you need this year, you are not ready for the platform, and the pilot broker is not the thing holding you back.

That advice costs us nothing, which is worth being honest about. A team with three hundred devices and no update requirement was never going to hire a development partner, so telling them the truth is free. It is still true.

When Is a Plain MQTT Broker the Right Answer?

When you want the broker and not the platform, or when where it runs is a hard requirement rather than a preference.

Mosquitto is a single lightweight broker. It is excellent for small fleets, edge gateways and development, it runs comfortably on modest hardware, and it is not designed to be a clustered production backbone by itself. Teams get into trouble by scaling it past what it claims to be, not by using it.

HiveMQ and EMQX are the serious clustered options, both with a self-managed path and a hosted one. This is what you choose when data residency, air-gapped operation, or a customer contract makes a hyperscaler impossible. Industrial and automotive teams end up here regularly, and usually for contractual reasons rather than technical ones.

The trade is real. You take on broker operations, high availability, patching and capacity planning, and you give up the provisioning, shadow and rules machinery, which you will then build yourself if you need it. That is a fair deal when the requirement is genuine and a bad one when it is a preference for self-hosting.

One thing worth saying plainly, since the comparison pages present these as rivals to AWS and Azure. They are not competing at the same layer. Mosquitto against AWS IoT Core is a broker against a platform, and a table that lines them up feature by feature is comparing an engine to a car.

What About Greengrass, Sitewise, IoT Central and the Rest?

These come up constantly in searches next to the main two, and mostly they are not alternatives at all. They sit at different layers, which is why comparing them head to head produces confusion.

Greengrass and IoT Edge run code on gateway hardware at the edge. You want them when devices must keep working through a network outage, when local latency matters, or when you need to filter and aggregate before paying to ship data to the cloud. If your devices have reliable connectivity and modest data volume, this is a layer you can skip entirely.

Sitewise is industrial equipment modelling, aimed at plant and machinery data rather than general connected products. If you are not in industrial operations you almost certainly do not need it.

IoT Central is the finished application built on IoT Hub, with device templates, dashboards and rules already there. It gets a pilot running fast. The cost is the customisation you may want later, and moving off it is a real project. Choose it when your requirements match its shape and you can say honestly that they will keep matching.

Kinesis, Event Hubs and Kafka are downstream of all of this. They are the pipe your telemetry flows into after the broker, not a replacement for it. A comparison of AWS IoT Core against Kafka is comparing two different hops in the same path.

How Do You Keep the Door Open?

One thin translation layer between the platform and your application, held to firmly. This is a first-sprint decision, and it is cheap exactly once.

Normalise at the first hop. Incoming messages get converted into your own event schema the moment they land, so no application code ever parses a vendor payload envelope. This single habit removes most migration pain, and it costs one small module.

Keep the rules engine dumb. It routes and it does nothing else. The moment a rule contains a business decision, that decision has been written in a language you cannot take with you, and it will not be documented anywhere.

Mirror device state into a store you own. Read the vendor shadow or twin at the boundary and write it into your own model. Application code talks to your model. When the shadow changes shape or vendor, one adapter changes.

Make the endpoint configuration, never a constant. Firmware that reads a hostname from configuration can be repointed. Firmware with a compiled-in endpoint is a recall.

Retain what you need and downsample the rest, from day one. Full-resolution telemetry kept forever is the bill nobody forecasts, and a retention policy written before the data exists takes an afternoon.

That list is not exotic and none of it slows a first release down. All of it is expensive to retrofit once a hundred thousand lines of application code depend on a vendor's payload shape.

Where This Leaves You

Pick the cloud your team already runs. If that is Azure, use IoT Hub. If it is AWS, use IoT Core. If you have a residency or air-gap requirement that rules both out, look at HiveMQ or EMQX self-managed and accept the operations you are taking on. If you have three hundred devices and no update story, run Mosquitto and revisit this in two years.

Then spend the attention you just saved on the parts that are actually permanent. The provisioning flow, because firmware ships and does not come back. The retention policy, because storage is the bill that grows on its own. The update path, because you will need it under pressure and not on a calm Tuesday. And a thin event contract, so this whole page becomes a decision you can revisit rather than one you are stuck with.

The teams we see in real trouble are almost never the ones that picked the wrong platform. They are the ones that picked carefully and then built as though the choice could never change.

If you want another pair of eyes on your telemetry path before the next production run, that is the kind of review we do, and we will tell you when there is nothing to fix.