This topic describes the billable items and pricing of ApsaraMQ for MQTT Basic and Platinum Edition instances.
Billing overview
ApsaraMQ for MQTT instances are available in Basic, Platinum, and Professional editions. For more information about the differences between these editions, see Instance types.
The billing methods and billable items are the same for Basic and Platinum Edition instances. The following table describes the billable items.
Billable item | Billing method | Billing cycle |
Subscription A bill is calculated based on the selected specifications and subscription duration. You must pay for the service before you use it. | Monthly | |
The billing formula for an instance is as follows:
Instance fee = (Unit price of maximum connections + Unit price of maximum messaging TPS + Unit price of maximum subscription relationships) × Subscription duration (in months)
Maximum connections
Description of the billable item
The number of connections is the total number of TCP connections from clients to a specified instance at any point in time. This is an instantaneous value that is updated every minute.
Ensure that the maximum connections for your purchased instance exceeds the peak number of online connections required by your services. This prevents service throttling due to specification limit breaches, which can prevent some clients from connecting.
Example
The number of concurrent online connections for `instance_a` is 1,000 at 10:00 and 2,000 at 10:01. To ensure that your service runs as expected, you must purchase an instance with a maximum connection limit greater than 2,000, such as 5,000.
Unit prices
Basic Edition instances
Region | Maximum connections | Price (USD/month) |
China (Shanghai), China (Hong Kong), Singapore, Japan (Tokyo), US (Virginia), Germany (Frankfurt), US (Silicon Valley) | 1,000 | 29 |
5,000 | 142 | |
10,000 | 284 | |
20,000 | 567 | |
Philippines (Manila), Indonesia (Jakarta), Malaysia (Kuala Lumpur) | 1,000 | 26 |
5,000 | 130 | |
10,000 | 260 | |
20,000 | 520 | |
SAU (Riyadh - Partner Region) | 1,000 | 35 |
5,000 | 170 | |
10,000 | 341 | |
20,000 | 680 |
Platinum Edition instances
Region | Maximum connections | Price (USD/month) |
China (Shanghai), China (Hong Kong), Singapore, Japan (Tokyo), US (Virginia), Germany (Frankfurt), US (Silicon Valley) | 50,000 | 1890 |
100,000 | 3852 | |
300,000 | 11329 | |
500,000 | 18805 | |
1,000,000 | 37836 | |
2,000,000 | 75446 | |
Philippines (Manila), Indonesia (Jakarta), Malaysia (Kuala Lumpur) | 50,000 | 1733 |
100,000 | 3533 | |
300,000 | 10391 | |
500,000 | 17249 | |
1,000,000 | 34705 | |
2,000,000 | 69202 | |
SAU (Riyadh - Partner Region) | 50,000 | 2268 |
100,000 | 4622 | |
300,000 | 13595 | |
500,000 | 22566 | |
1,000,000 | 45403 | |
2,000,000 | 90539 |
Maximum messaging TPS
Description of the billable item
Messaging transactions per second (TPS) is the sum of the number of messages produced and consumed per second in a specified instance. This value is updated every minute.
Ensure that the maximum messaging TPS for your purchased instance exceeds the peak TPS for sending and receiving messages in your services. This prevents service throttling due to specification limit breaches, which can cause failures when sending or receiving some messages.
Calculation rules
Messaging TPS includes only messages sent and received using ApsaraMQ for MQTT. It excludes messages sent and received using ApsaraMQ for RocketMQ.
For a message with a Quality of Service (QoS) level of 1 and `cleanSession` set to false, if the server fails to push the message, the message is stored as an offline message for retry. This attempt is counted as one subscribed message.
When messaging TPS is calculated, the number of messages is multiplied by a corresponding coefficient based on the quality of service (QoS). For more information about the coefficients, see Billing coefficients.
For example, if a client is configured with QoS=2 and `cleanSession=true`, the billing coefficient is 5. If the client produces 10 messages, the number of produced messages is calculated as 10 × 5 = 50.
Example
Assume that there are 5 topics. A producer sends 20 messages to each topic. Each topic is subscribed to by 100 clients. All clients have the same QoS level, and the billing coefficient is 2.
The total number of billable messages is calculated as follows: (Number of topics × Number of messages + Number of topics × Number of messages × Number of client subscriptions) × Billing coefficient = (5 × 20 + 5 × 20 × 100) × 2 = 20,200.
Unit prices
Basic Edition instances
Region | Maximum messaging TPS (messages/second) | Price (USD/month) |
China (Shanghai), China (Hong Kong), Singapore, Japan (Tokyo), US (Virginia), Germany (Frankfurt), US (Silicon Valley) | 500 | 142 |
1,000 | 284 | |
3,000 | 850 | |
5,000 | 1417 | |
10,000 | 2833 | |
20,000 | 5665 | |
Philippines (Manila), Indonesia (Jakarta), Malaysia (Kuala Lumpur) | 500 | 130 |
1,000 | 261 | |
3,000 | 779 | |
5,000 | 1299 | |
10,000 | 2599 | |
20,000 | 5196 | |
SAU (Riyadh - Partner Region) | 500 | 170 |
1,000 | 341 | |
3,000 | 1020 | |
5,000 | 1700 | |
10,000 | 3400 | |
20,000 | 6798 |
Platinum Edition instances
Region | Maximum messaging TPS (messages/second) | Price (USD/month) |
China (Shanghai), China (Hong Kong), Singapore, Japan (Tokyo), US (Virginia), Germany (Frankfurt), US (Silicon Valley) | 50,000 | 7930 |
100,000 | 12009 | |
200,000 | 18125 | |
500,000 | 42368 | |
Philippines (Manila), Indonesia (Jakarta), Malaysia (Kuala Lumpur) | 50,000 | 7274 |
100,000 | 11015 | |
200,000 | 16625 | |
500,000 | 38861 | |
SAU (Riyadh - Partner Region) | 50,000 | 9516 |
100,000 | 14411 | |
200,000 | 21750 | |
500,000 | 50842 |
ApsaraMQ for MQTT no longer supports the 100 TPS specification. Existing instances that were purchased with this specification can continue to be used. However, if you upgrade these instances, you cannot downgrade them back to this specification.
Maximum subscription relationships
Description of the billable item
The number of subscription relationships is the number of subscriptions that are registered and retained on a specified instance.
Ensure that the maximum number of subscription relationships for your purchased instance exceeds the actual number required by your services. This prevents service throttling due to specification limit breaches, which can cause failures when sending or receiving some messages.
If some of your clients are no longer in use and their subscription relationships do not need to be retained, purge the subscription relationships promptly to conserve system resources. For more information, see Purge subscription relationships.
Calculation rules
The number of subscription relationships is calculated over a statistical period of 1 minute. A sample is collected every second, and the peak value from the 60 samples is recorded as the value for that minute.
For example, within 1 minute, if the number of subscription relationships is 30 in the first second, 20 in the second second, 30 in the third second, ..., and 50 in the 60th second, the number of subscription relationships for that minute is 50.
Each subscription to an ApsaraMQ for MQTT topic by a unique client (identified by its Client ID) is counted as one subscription relationship, regardless of the message sending scenario.
If a client subscribes to a parent topic and its child topics, the subscriptions are counted separately.
For example, if Client_1 subscribes to TopicA, TopicA/sub_1, and TopicA/sub_2, the number of subscription relationships is 3.
According to the MQTT protocol, if a client sets `cleanSession=true`, the server purges all of the client's topic subscriptions after the client goes offline. If `cleanSession=false`, the server retains the client's topic subscriptions, and these retained subscriptions are counted.
Example
Three topics, TopicA, TopicB, and TopicC, are created in an instance named `Instance_A`. A total of 10 clients are connected to the server.
Each of the 10 clients produces messages to TopicA, TopicB, and TopicC. Each client subscribes to only TopicA and TopicB to consume messages.
In this scenario, the number of subscription relationships is 10 × 2 = 20.
Unit prices
Basic Edition instances
Region | Maximum subscription relationships | Price (USD/month) |
China (Shanghai), China (Hong Kong), Singapore, Japan (Tokyo), US (Virginia), Germany (Frankfurt), US (Silicon Valley) | 1,000 | 12 |
10,000 | 114 | |
50,000 | 567 | |
100,000 | 1133 | |
Philippines (Manila), Indonesia (Jakarta), Malaysia (Kuala Lumpur) | 1,000 | 11 |
10,000 | 104 | |
50,000 | 520 | |
100,000 | 1040 | |
SAU (Riyadh - Partner Region) | 1,000 | 14 |
10,000 | 137 | |
50,000 | 680 | |
100,000 | 1360 |
Platinum Edition instances
Region | Maximum subscription relationships | Price (USD/month) |
China (Shanghai), China (Hong Kong), Singapore, Japan (Tokyo), US (Virginia), Germany (Frankfurt), US (Silicon Valley) | 500,000 | 7477 |
1,000,000 | 15180 | |
2,000,000 | 30133 | |
5,000,000 | 75446 | |
Philippines (Manila), Indonesia (Jakarta), Malaysia (Kuala Lumpur) | 500,000 | 6858 |
1,000,000 | 13924 | |
2,000,000 | 27640 | |
5,000,000 | 69202 | |
SAU (Riyadh - Partner Region) | 500,000 | 8972 |
1,000,000 | 18216 | |
2,000,000 | 36160 | |
5,000,000 | 90535 |