Skip to content

Comparison of MQTT Support by IoT Cloud Platforms

by HiveMQ Team
10 min read

The success of MQTT can be measured by the widespread adoption by the different IoT cloud vendors. However, support for MQTT is not always equal across the cloud vendors. In fact, Microsoft states clearly on its website that:

“IoT Hub is not a full-featured MQTT broker and does not support all the behaviors specified in the MQTT v3.1.1 standard.”

Open standards are important to avoid vendor lock-in. If a vendor partially supports a standard like MQTT then it is one step towards vendor lock-in. For this reason, we think it is interesting to evaluate the support of MQTT by some IoT cloud vendors, including AWS IoT, HiveMQ Cloud, and MS Azure IoT.

The following is a detailed analysis based on the documentation available for each of these vendors.

Deviations From Specification

Basic MQTT features such as QoS 2, Retained Messages and guaranteed message ordering are often used to implement business critical systems. In order to be MQTT compliant these features are not optional but mandatory, which means cloud platforms that do not support these features are not compliant to the MQTT specification. HiveMQ provides support for MQTT 3.1, MQTT 3.1.1 and MQTT 5. In fact, HiveMQ has supported MQTT 5 since December 2018.

What does this mean for you as a user of these cloud platforms that do not support MQTT 5 features? You will miss out on critical features such as shared subscriptions, session and message expiry, topic aliases, user properties and negative acknowledgements. These features are essential for successful deployments of mission critical user cases in key industries, such as manufacturing.

AWS IoT Core announced support for MQTT 5, but they do not support shared subscriptions. Microsoft Azure IoT support for topic names and topic filters is very limited. From the Microsoft document:

“Since IoT Hub is not a general-purpose pub-sub messaging broker, it only supports the documented topic names and topic filters.”

It would appear all MQTT messages in Azure IoT need to be from a topic namespace of


This greatly reduces the flexibility of designing a topic namespace to fit the organizations' IoT use case. It also tightly ties the IoT application to Azure IoT.

Finally, it is important to consider the SDKs that can be used to connect devices to each service. HiveMQ Cloud and MS Azure allow for open-source MQTT client SDKs (ex. Eclipse Paho) to be used to connect to their service. AWS IoT only supports device connectivity using the AWS IoT SDK. MS also has the MS IoT SDK to connect to the MS Azure IoT Hub. Restricting device connectivity to the cloud services via a proprietary vendor SDK limits the options for changing the MQTT cloud service at a later date.

Deviations From MQTT Specification

Feature AWS IoT MS Azure IoT Hub HiveMQ Cloud
MQTT 5 YesNoYes
QoS 2 Support NoNoYes
QoS 0 Support Non conformance to specification [1]YesYes
Retained Messages YesNoYes
Guaranteed message ordering NoYesYes
Direct access to messages after a successful subscription Possible delay between subscription and receipt of messages [2]YesYes
Topic Filter No restrictions# and + are not supportedNo restrictions
Topic namespace restrictions No restrictionsTopic structure limited [3]No restrictions
Compatibility with standard MQTT client libraries (ex. Eclipse Paho) YesLimited Use [4] (Preferred connectivity via MS Azure SDK)Yes

[1] AWS IoT QoS is defined as delivered zero or more times. MQTT 3.1.1 spec defines QoS 0 as at most once delivery.

[2] When a client subscribes to a topic, there might be a delay between the time the message broker sends a SUBACK and the time the client starts receiving new matching messages.

[3] Topic need to follow specific format of 'devices/{device_id}/messages/events'

[4] Microsoft has a very restrictive way that you can use a MQTT library.

Limitations of MQTT Support

AWS IoT and MS Azure IoT impose a number of limitations on their MQTT broker that restrict the potential use cases for their services.

Both AWS and MS make it impossible to create an MQTT client back-end consumer service that could subscribe to all the messages in the system so they can be stored in a database or another enterprise system. AWS limits each client to 100 publish events per second and throughput of 512kb/second/connection. MS limits the publishing rate to 120 events/sec/unit and throughput is limited to 300MB per device stream. A scalable back-end MQTT client consumer service would require much higher rate limits. In addition, the lack of MQTT 5 Shared Subscriptions makes it even more difficult to implement. The integration with other backend services must be done using the AWS or MS proprietary event handle services, which locks companies into proprietary cloud functionality.

AWS IoT restricts the QoS 1 retry interval to 1 hour meaning if a device was offline for more than an hour, the message would not be received. For many enterprise IoT use cases, like connected cars that can go offline for extended periods of time, it is unacceptable to lose messages after a period of time. This limitation effectively makes QoS 1 support in AWS IoT non-functional.

AWS and MS limits the size of the MQTT message. AWS limits messages size to 128kb and MS limits messages size device to cloud at 256kb and cloud to device at 64kb. The MQTT specification specifies the MQTT message size limit to be 256MB. HiveMQ supports the MQTT specification of 256MB.

MQTT Limitations

Limitation AWS IoT MS Azure IoT Hub HiveMQ Cloud
QoS 1 retry interval 1 hrunlimitedunlimited
Publish request per second per client 100120/second/unit 6000/second/unit at higher price levelunlimited
Subscriptions per connection 50Limit depends on pricingunlimited
Cloud to device message queue unlimited50unlimited
Throughput 512kb/sec/connection300MB/dayunlimited
Message Size 128kb256kb device to cloud 64kb cloud to deviceunlimited

Ref: AWS Limitations, MS Azure IoT


MQTT is a widely used and accepted ISO IoT standard. Standardization of functionality across vendors is one of the key success factors for MQTT, as this protects customers from vendor lock-in of their IoT devices, which are very often part of a company’s value chain. Unfortunately, not all MQTT cloud services have implemented the entire specification and are not MQTT compliant since they lack mandatory features that are required to implement the MQTT 3.1.1 standard. These deviations from the MQTT standard often lead to using the vendor’s proprietary IoT SDKs to send the MQTT message. The use of proprietary SDKs promote vendor lock-in and makes it difficult to switch MQTT cloud services at a later point in time. Open standards are important to avoid vendor lock-in but incomplete implementations of open standards might lead to vendor lock-in.

Cavest emptor - Buyer beware

Unlock the full potential of MQTT with HiveMQ Cloud Starter, a complete MQTT platform ideal for testing and small-scale production! Begin your free trial now and enjoy unlimited connections, 99.95% uptime SLA, 24/7 support, data streaming integrations, and more.

Sign-up Now

HiveMQ Team

The HiveMQ team loves writing about MQTT, Sparkplug, Industrial IoT, protocols, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.

Related content:

HiveMQ logo
Review HiveMQ on G2