CloudMQTT Migration
Using Mosquitto on CloudMQTT? RabbitMQ on CloudAMQP could be an alternative.
We invite you to read our RabbitMQ 3.12 release blog to learn more about native MQTT support in RabbitMQ 3.12 and its impact on performance and scalability.
RabbitMQ has had MQTT support for a long time, and with RabbitMQ 3.12.0 it’s even better. Starting from this release, RabbitMQ supports MQTT natively – it will parse MQTT messages and send them to queues directly without proxying via its core protocol. The results of this new change are really good:
- More efficient use of memory
- RabbitMQ can now support millions of MQTT connections
If at this point you are interested in migrating to RabbitMQ on CloudAMQP, you will find the migration steps below.
Migration Steps
- Setup a CloudAMQP account
Sign up for a CloudAMQP account, add your billing information and invite your teammates. - Create a RabbitMQ instance
All plans support MQTT, use RabbitMQ >3.12 for best performance. - Set up custom hostname and certificate
Optional. If you have IoT devices, we recommend a custom hostname and a custom certificate to ensure you have full control. Easy to configure via the CloudAMQP console. - Migrate users and access control list
Convert CloudMQTT users and ACLs to RabbitMQ users and permissions. RabbitMQ and Mosquitto are not fully compatible, so you may need to adjust your ACLs. - Link instances
Optional. Use a bridge to link your CloudMQTT instance with your CloudAMQP instance while migrating clients. - Update your clients
Update your clients to connect to CloudAMQP. - Delete your CloudMQTT instance
Features
CloudAMQP offers a wider set of features than CloudMQTT that you might find useful.
- More datacenter regions available
- MQTT 5 (available in RabbitMQ 3.13)
- Alarms
- Diagnostics
- Logs & Metrics
- EventBridge & Webhooks
- AMQP, STOMP, HTTP, and WebSockets support
- VPC peering & Private connect
- Firewall
Differences
These CloudMQTT features are unfortunately not available on CloudAMQP.
- Multiple users and ACLs on the Shared plans
- ACLs with variables and wildcards
- AWS Kinesis stream and Mosquitto bridges
Consider using RabbitMQ shovels, RabbitMQ federation, AWS EventBridge or Webhooks to move messages. - MQTT QoS2
Motivation by the RabbitMQ team to not support QoS2. - Limited retained messages functionality
RabbitMQ does have support for retained messages but comes with some limitations.
MQTT versions
RabbitMQ has supported MQTT 3.1.1 for a long time, and now MQTT 5 is available in RabbitMQ 3.13.
Topics to Exchanges and Queues
With the MQTT protocol, you publish messages to topics and subscribe to topics while with the AMQP protocol, you publish messages to exchanges and subscribe to queues. Which messages are delivered to which queues is determined by the exchange and queue bindings.
When a MQTT client connects to RabbitMQ and subscribes to a topic, RabbitMQ will create a queue for the client and bind it to the exchange. Messages will then be routed to the client’s queue and delivered to the client.
The default naming schema for MQTT queues are
mqtt-subscription-<clientid><qos>.
ACL tips
In mosquitto you have the possiblity to turn on a setting called
use_username_as_clientid. This is needed to get a one-to-one relation between
authentication and identity. There is no such setting in RabbitMQ, but you can
achieve the same result with the following permissions for the user, replacing
USERNAME with the name of the user:
| Permission | Pattern |
|---|---|
| configure | ^mqtt-subscription-USERNAMEqos[01]$ |
| write | ^(mqtt-subscription-USERNAMEqos[01]|amq\.topic)$ |
| read | ^mqtt-subscription-USERNAMEqos[01]$ |
In need of support?
Our support team is here to assist and answer any questions you might have regarding a migration. E-mail us at support@cloudamqp.com or visit our support page.