This topic describes instance types and billing methods of Message Queue for MQTT. You can select an instance type and a billing method based on your business requirements.

Notes

  • Message Queue for MQTT V3.x.x and later no longer use Message Queue for Apache RocketMQ for storage. A maximum of 25 topics can be created for a single Message Queue for MQTT instance. If you want to create more topics,submit a ticket. Extra resources will be billed.
  • If you use Message Queue for MQTT V3.x.x to exchange data with other Alibaba Cloud services based on rules, these services are billed based on their respective billing methods. Message Queue for MQTT can only interact with Message Queue for Apache RocketMQ, for which the topic resource usage and API operation calls are billed. For more information, see Detailed prices of Message Queue for Apache RocketMQ.

Instance types

The following table lists the differences between different instance types of Message Queue for MQTT.

Item Enterprise Platinum Edition Basic Edition Pay-as-you-go
Instance type Dedicated instance with physical isolation. Each Enterprise Platinum Edition instance owns exclusive underlying hardware resources and is deployed as one independent cluster. Therefore, this type of instance is not affected by traffic peaks of other users and can provide after-sales services and stability assurance at a higher priority. Shared instance with logical isolation. Multiple Basic Edition instances share the underlying hardware resources and the same backend cluster. Message Queue for MQTT ensures service availability in multitenancy scenarios. Shared instance with logical isolation. Multiple pay-as-you-go instances share the underlying hardware resources and the same backend cluster. Message Queue for MQTT ensures service availability in multitenancy scenarios.
Billing method Subscription. The instances are yearly or monthly billed in advance based on their specifications. Pay-as-you-go. The instances are billed based on the actual usage.
Scenarios
  • Large-scale services are running.
  • Customization is required.
  • High upper limits are required for the messaging transactions per second (TPS), number of connections, and number of subscriptions.
  • Small-scale services are running.
  • No high upper limits are required for the messaging TPS, number of connections, and number of subscriptions.
  • The service scale fluctuates.
  • The number of sent and received messages, the number of connections, and the number of subscriptions fluctuate.
Service support DingTalk group for product consultation
Alibaba Cloud ticket channel × ×
Assistance during system launch and sales promotions × ×
Exclusive DingTalk group × ×
Dedicated service manager support × ×
Dedicated technical expert support

The core R&D team provides technical support.

× ×
Point-to-point troubleshooting

Customer Services are available on a 24/7 basis.

× ×
Features Upper limit of subscriptions (rules) for a single device Theoretically not limited.

You can customize an upper limit of subscriptions (rules) for a single device.

Up to 30 subscriptions. Up to 30 subscriptions.
Message retention period Up to seven days.

You can customize a message retention period.

Up to three days. Up to three days.
Protocol type MQTT

You can customize the protocol type.

MQTT MQTT
Client status notification
P2P
Message tracing × ×
Ordered messages
Authorization to third-party accounts
WebSocket
Management API operations
Note The symbol ✓ indicates that the service or feature is supported, whereas ✗ indicates that the service or feature is not supported. For more information about how to obtain the DingTalk group for product consultation, see Contact us.

Subscription

The following table lists the billing items of subscription instances of Message Queue for MQTT.

Item Definition Description Example
Maximum number of connections The maximum number of TCP-based client connections on a single instance at any time. The number of concurrent connections is a transient value and is updated every minute. The maximum number of connections must be at least the actual number of connections for the service. Otherwise, peak connections for the service will trigger throttling in Message Queue for MQTT, causing some clients to fail to be connected. Assume that 1,000 concurrent connections are available in instance_a at 10:00 and 2,000 concurrent connections are available at 10:01. In this case, the service can properly run only when the maximum number of concurrent connections for instance_a is greater than 2,000, for example, 5,000.
Maximum messaging TPS The maximum number of messages that are sent and received per second by using protocols supported by Message Queue for MQTT.
  • To avoid service exceptions, you must ensure that the maximum messaging TPS is at least the actual messaging TPS.
  • These messages only include the messages that are sent and received by using Message Queue for MQTT, but do not include the messages that are sent and received by using Message Queue for Apache RocketMQ.
  • The messaging TPS include the message receiving TPS and message sending TPS.
  • If the system fails to push messages with QoS set to 1 and cleanSession set to false, the system stores these messages as offline messages for retrying. Storing offline messages is also considered as one push call.
  • The fees are calculated by multiplying the total number of received and sent messages (including calls of the client API and the cloud API) by the ratio that corresponds to the transmission quality level in the specified protocol. For more information, see Calculation ratio.
Assume that instance_a has 100 clients, and cleanSession is set to true for each client. When one QoS0 message, two QoS1 messages, and three QoS2 messages are sent per second, and one QoS0 message, one QoS1 message, and one QoS2 message are received per second, the messaging TPS of instance_a is calculated in the following formula: 100 × (1 + 2 × 2 + 3 × 5) + 100 × (1 + 1 × 2 + 1 × 5) = 2800. Therefore, to ensure that the service runs properly, the maximum messaging TPS for instance_a must be greater than 2,800, for example, 3,000.
Maximum number of subscriptions The maximum number of subscriptions that a user has registered with the Message Queue for MQTT broker.
  • To avoid service exceptions, you must ensure that the maximum number of subscriptions must be at least the actual number of subscriptions.
  • Each subscription to a Message Queue for MQTT topic by a client ID is counted as one subscription.
  • The number of subscriptions is counted every minute. The Message Queue for MQTT broker outputs the maximum value obtained in each statistical cycle.
  • Based on the Message Queuing Telemetry Transport (MQTT) protocol, if cleanSession is set to true on a Message Queue for MQTT client and the Message Queue for MQTT client goes offline, the Message Queue for MQTT broker cancels all the topics subscribed to by the Message Queue for MQTT client. If cleanSession is set to false on a Message Queue for MQTT client and the Message Queue for MQTT client goes offline, the Message Queue for MQTT broker retains all the topics subscribed to by the Message Queue for MQTT client.
Assume that instance_a is connected with client_1 and client_2, client_1 subscribes to TopicA/sub_1, TopicA/sub_2, and TopicB/sub_1, and client_2 subscribes to TopicA/sub_1 and TopicB/sub_2. Then, the number of subscriptions for instance_a is calculated as 3 + 2 = 5. Therefore, to ensure that the service runs properly, the maximum number of subscriptions for instance_a must be greater than 5, for example, 1000.

The following table lists the upper limits and the billing rules for connections of subscription instances of Message Queue for MQTT.

Instance type Maximum number of connections Price (USD/month)
Basic Edition 100 3
1,000 29
5,000 142
10,000 284
20,000 567
50,000 1,417
100,000 2,833
Enterprise Platinum Edition 100,000 3,852
300,000 11,329
500,000 18,805
1,000,000 37,836
2,000,000 75,446

The following table lists the upper limits and the billing rules for the messaging TPS of subscription instances of Message Queue for MQTT.

Instance type Maximum messaging TPS Price (USD/month)
Basic Edition 100 29
1,000 284
5,000 1,417
10,000 2,833
20,000 5,665
Enterprise Platinum Edition 20,000 5,211
50,000 7,930
100,000 12,009
200,000 18,125
500,000 42,368

The following table lists the upper limits and the billing rules for subscriptions of subscription instances of Message Queue for MQTT.

Instance type Maximum number of subscriptions Price (USD/month)
Basic Edition 1,000 12
10,000 114
50,000 567
100,000 1,133
200,000 2,266
500,000 5,665
1,000,000 11,329
Enterprise Platinum Edition 100,000 1,586
500,000 7,477
1,000,000 15,180
2,000,000 30,133
5,000,000 75,446
Note You can switch a subscription instance of Message Queue for MQTT to a pay-as-you-go instance. For more information, see Switch the billing method from subscription to pay-as-you-go.

Pay-as-you-go

The following table lists the billing items of pay-as-you-go instances of Message Queue for MQTT.

Item Definition Description Example
Number of concurrent connections The number of TCP-based client connections on a single instance at any time. The number of concurrent connections is a transient value and is updated every minute. The billing cycle is one day. Specifically, the maximum number of concurrent connections within the 24 hours starting from 00:00 in the previous day is counted in the daily bill. Assume that the number of concurrent connections of instance_a was 1,000 at 10:00 on August 8, 2017 and was 2,000 at 11:00 on August 8, 2017, and the number did not reach 2,000 afterward on that day. In this case, the maximum number of concurrent connections of instance_a was 2,000 on August 8, 2017. Therefore, the number used for billing was 2000.
Number of sent and received messages The maximum number of messages that are sent and received by using protocols supported by Message Queue for MQTT.
  • The billing cycle is one day. Specifically, the total number of messages that are sent and received within the 24 hours starting from 00:00 in the previous day is counted in the daily bill.
  • These messages only include the messages that are sent and received by using Message Queue for MQTT, but do not include the messages that are sent and received by using Message Queue for Apache RocketMQ.
  • Both received messages and sent messages are counted.
  • If the system fails to push messages with QoS set to 1 and cleanSession set to false, the system stores these messages as offline messages for retrying. Storing offline messages is also considered as one push call.
  • The fees are calculated by multiplying the total number of received and sent messages (including calls of the client API and the cloud API) by the ratio that corresponds to the transmission quality level in the specified protocol. For more information, see Calculation ratio.
Assume that instance_a has 100 clients, and cleanSession is set to true for each client. When one QoS0 message, two QoS1 messages, and three QoS2 messages are sent, and one QoS0 message, one QoS1 message, and one QoS2 message are received, the number of sent and received messages of instance_a is calculated in the following formula: 100 × (1 + 2 × 2 + 3 × 5) + 100 × (1 + 1 × 2 + 1 × 5) = 2800. Then, the number used for billing is 2,800.
Number of subscriptions The number of subscriptions that a user has registered with the Message Queue for MQTT broker. The billing cycle is one day. Specifically, the maximum number of subscriptions within the 24 hours starting from 00:00 in the previous day is counted in the daily bill. Assume that the number of subscriptions of instance_a was 1,000 at 10:00 on August 8, 2017 and was 500 at 11:00 on August 8, 2017, and the number did not reach 1,000 afterward on that day. In this case, the maximum number of subscriptions of instance_a was 1,000 on August 8, 2017. Therefore, the number used for billing was 1,000.

The following table lists the billing rules for the number of concurrent connections of pay-as-you-go instances of Message Queue for MQTT.

Number of concurrent connections Price (USD)
[1,100] 0.07
> 100 Number of concurrent connections × 0.0007

The following table lists the billing rules for the number of sent and received messages of pay-as-you-go instances of Message Queue for MQTT.

Number of sent and received messages (million) Price (USD)
> 0 Number of sent and received messages × 0.91

The following table lists the billing rules for the number of subscriptions of pay-as-you-go instances of Message Queue for MQTT.

Number of subscriptions Price (USD)
[1,100] 0.01
> 100 Number of subscriptions × 0.0001

Calculation ratio

The following table lists the calculation ratios of messages in Message Queue for MQTT.

Transmission quality level Calculation ratio
QoS = 0 and cleanSession = true in MQTT 1
QoS = 0 and cleanSession = false in MQTT 1
QoS = 1 and cleanSession = true in MQTT 2
QoS = 1 and cleanSession = false in MQTT 5
QoS = 2 and cleanSession = true in MQTT 5
Note Message Queue for MQTT does not support the MQTT-based transmission quality level with QoS set to 2 and cleanSession set to false. However, if you use this transmission quality level, the price is calculated by multiplying the billing unit by 5.