← All articles

November 13, 2023 · 6 min read · Updated October 7, 2026

Managed MQTT services compared: what changed since 2023

How EMQX Cloud, HiveMQ Cloud, AWS IoT Core, Azure and the retired Google IoT Core differ in MQTT behavior, billing model and risk.

On this page

Your devices speak MQTT, and a broker has to sit between them. Running that broker yourself means patching it, sizing it for next quarter's fleet and getting paged when it falls over. A managed service moves that work to a provider and bills you for use.

The catch is that "managed MQTT" covers very different products. Some are full brokers. Some are device-ingest services that speak MQTT on the way in. One of the services this post originally covered no longer exists, and another is on its way out. This is a 2026 revision of a 2023 post, rewritten against the providers' own documentation as of 7 October 2026.

What serverless MQTT means

You get an endpoint, credentials and a TLS port. The provider runs the broker, and you pay per connected minute, per message or per gigabyte, not for a server that idles. That suits prototypes and bursty fleets. It also means your bill depends on how chatty your devices are, so the billing model matters as much as the free tier.

Check these four things first

The MQTT specification defines three delivery levels. QoS 0 is best effort and messages can be lost, QoS 1 guarantees arrival but allows duplicates, and QoS 2 delivers exactly once. Providers do not all implement all of it, and that is where migrations hurt.

  1. QoS 2. AWS IoT Core supports QoS 0 and 1 only. Azure Event Grid's MQTT broker says QoS 2 is not supported. Azure IoT Hub closes the connection if a device publishes QoS 2.
  2. Retained messages. IoT Hub does not store them. It passes the retain flag to your backend as a message property. AWS IoT Core stores them, but a client only receives the retained message on subscribe if its filter matches the topic exactly. A wildcard filter gets later messages only.
  3. MQTT 5. Azure IoT Hub supports v3.1.1 only. Event Grid supports v3.1.1 and v5. AWS IoT Core supports both.
  4. Free tier expiry. AWS has a 12-month free tier. EMQX has a monthly allowance with no stated end. HiveMQ's free Serverless plan is being retired.

The providers

Service What it is Billing model Watch out for
EMQX Cloud Serverless Shared managed EMQX broker Session minutes, traffic, rule actions Inactive deployments get stopped
HiveMQ Cloud Managed HiveMQ broker Hourly plus per message (Starter) Serverless plan ends 2026-12-31
AWS IoT Core Device platform with an MQTT broker Connection minutes plus messages in 5 KB units No QoS 2
Azure Event Grid MQTT General MQTT broker inside Azure Per Azure pricing No QoS 2
Azure IoT Hub Device service that speaks MQTT Per Azure pricing Not a general broker
Google Cloud IoT Core Retired None Gone since August 2023

EMQX Cloud Serverless

EMQX publishes a monthly free allowance of 1 million session minutes, 1 GB of traffic and 1 million rule actions. Beyond that it charges $2.00 per extra million session minutes, $0.15 per GB and $0.25 per extra million rule actions. EMQX says the session allowance keeps 23 devices online around the clock for 30 days. You can set a monthly spend limit that suspends the deployment. Deployments default to ports 8883 (MQTT over TLS) and 8084 (secure WebSocket), and EMQX stops a deployment after 30 inactive days. That last rule is easy to miss on a weekend project.

HiveMQ Cloud

HiveMQ's documentation says the Serverless plan retires on 2026-12-31, after which clients can no longer connect and clusters and data are deleted. That plan was multi-tenant and aimed at learning, with a free allowance of up to 100 connections. Its Starter plan is a dedicated broker, listed from $0.34 an hour plus $0.80 per million messages. If an old tutorial points you at the free Serverless tier, plan for Starter or another provider.

AWS IoT Core

AWS IoT Core is a device platform with an MQTT broker, based on MQTT 3.1.1 and 5. Billing combines connection minutes and messages, with messages metered in 5 KB increments, so an 8 KB payload counts as two. The default limit is 500,000 concurrent connections per account, and AWS lists it as adjustable. A single MQTT payload can be up to 128 KB, and a persistent session expires after one hour by default. If your backend already lives in AWS, the rules engine and IAM-based access save glue code. If you need QoS 2, look elsewhere.

Azure IoT Hub and Event Grid

Microsoft's own documentation says IoT Hub is not a full-featured MQTT broker. It uses fixed topic names, does not support device-to-device messaging and speaks v3.1.1 only. For a cloud-hosted broker it points you to Azure Event Grid, which supports v3.1.1 and v5, custom hierarchical topics with wildcards, shared subscriptions and messages up to 1 MB. Pick IoT Hub when you want its device twins and device management. Pick Event Grid when you want a broker.

Google Cloud IoT Core

Google retired IoT Core on 16 August 2023 and pointed customers to its partners. Devices can no longer connect. The 2023 version of this post kept it for reference. It now stays only so you recognise it in old tutorials.

Test the contract before you commit

Pricing pages do not tell you whether a provider matches your topic design. A quick check with mosquitto_sub and mosquitto_pub does. Name topics from general to specific, so a filter can select a whole line or one sensor:

mosquitto_sub -h broker.example.com -p 8883 --capath /etc/ssl/certs \
  -u USER -P PASS -t 'plant1/line2/+/temperature' -q 1 -v

mosquitto_pub -h broker.example.com -p 8883 --capath /etc/ssl/certs \
  -u USER -P PASS -t 'plant1/line2/press4/temperature' \
  -m '{"celsius":21.4}' -q 1 -r

Run the publish again with -q 2 to see whether the provider downgrades it, rejects it or drops the connection. Then subscribe with a wildcard after publishing and see whether you get the retained value. The certificate path varies by operating system, and some providers require a client ID or a specific username format. A phone client such as Mqtizer is handy for the same checks away from a desk.

Which one to try

Which managed MQTT service to try first Decision chain for picking a managed MQTT service. Production on AWS leads to AWS IoT Core, production on Azure to Event Grid with IoT Hub for twins, a weekend prototype to EMQX Cloud Serverless, and anything else to HiveMQ Cloud Starter or EMQX dedicated. Productionon AWS?yesAWS IoT CoreQoS 0 and 1 onlynoProductionon Azure?yesEvent GridIoT Hub for twinsnoWeekendprototype?yesEMQX CloudServerlessnoHiveMQ Cloud Starter or EMQX dedicatedpriced against your real volume
  • Weekend prototype: EMQX Cloud Serverless, mindful of the inactivity rule and the spend limit.
  • Production on AWS: AWS IoT Core, if QoS 0 and 1 are enough.
  • Production on Azure: Event Grid for a broker, IoT Hub for twins and device management.
  • Standalone broker without a cloud platform: HiveMQ Cloud Starter or EMQX's dedicated plans, priced against your real message volume.

Whatever you pick, test with a realistic number of devices and your real payload sizes. Per-message billing and 5 KB metering turn small payload choices into line items.

References