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 our offer and the migration steps below.

CloudAMQP offer - receive 6 months credits

When choosing to migrate to CloudAMQP we can offer you credits covering the first 6 months of an equivalent plan to your current CloudMQTT plan. If you are considering this option, make sure to reach out to the support.

Migration Steps

1. Setup a CloudAMQP account
   Sign up for a CloudAMQP account, add your billing information and invite your teammates.
2. Create a RabbitMQ instance
   All plans support MQTT, use RabbitMQ >3.12 for best performance.
3. 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.
4. 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.
5. Link instances
   Optional. Use a bridge to link your CloudMQTT instance with your CloudAMQP instance while migrating clients.
6. Update your clients
   Update your clients to connect to CloudAMQP.
7. 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. If the client subscribes to multiple topics more bindings will be added to the queue. If both QoS 0 and 1 are used RabbitMQ will create two queues, one for each QoS.

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: