For both subscription and pay-as-you-go instances, the computing specification for sending and receiving messages is a required billable item in ApsaraMQ for RocketMQ. ApsaraMQ for RocketMQ provides different computing specifications based on the maximum Transactions Per Second (TPS) for sending and receiving messages. Fees are calculated based on the specification and the subscription duration.
Computing specification description
Computing specification capabilities and constraints
TPS for sending and receiving messages
The computing specification for ApsaraMQ for RocketMQ defines the maximum Transactions Per Second (TPS) that ApsaraMQ for RocketMQ can process for sending and receiving messages.
Each specification corresponds to a different maximum TPS. For more information, see Instance types.
Other resource quotas
In addition to the core TPS capabilities for sending and receiving messages, each instance type has different limits on management resources and configurations. For more information, see Instance types.
Behavior when specification limits are exceeded
If the actual TPS for sending and receiving messages exceeds the limit of your purchased specification, the following rules apply:
If the elastic TPS feature is enabled for the instance, the instance can run normally as long as the TPS is within the range of the base specification and the elastic specification. The portion that uses elastic TPS is billed on a pay-as-you-go basis. If the TPS exceeds the elastic capacity limit, the instance is throttled.
For more information about elastic TPS billing, see Elastic TPS fees.
If the elastic TPS feature is not supported or enabled for the instance, ApsaraMQ for RocketMQ throttles the instance.
For more information about instance throttling, see Message throttling mechanism.
Calculation rules for message sending and receiving TPS
The TPS for sending and receiving messages is the total number of messages sent and subscribed to per second.
The default ratio of sending to receiving capabilities for an instance is 1:1. For scenarios that involve fewer writes and more reads, you can modify this ratio in the ApsaraMQ for RocketMQ console.
The minimum unit for calculating the message size is 4 KB. Messages smaller than 4 KB are counted as 4 KB messages. For example, if 5,000 messages are received per second and 5,000 messages are sent per second, and the average message body size is 16 KB, the TPS for sending and receiving messages is (16 / 4) × (5,000 + 5,000) = 40,000 calls/second.
For messages that use advanced features:
In message sending scenarios, sending ordered messages, scheduled and delayed messages, or transactional messages consumes five times the TPS of sending normal messages.
For example, if you send 10 transactional messages per second, the message sending TPS is 10 × 5 = 50 calls/second.
In message consumption scenarios, consuming ordered messages consumes five times the TPS of consuming normal messages.
In multi-consumer group scenarios, read TPS is calculated independently for each consumer group. Each message counts as one write TPS only once, regardless of how many consumer groups subscribe to it. However, each consumer group independently contributes its own read TPS, and all consumer groups share the total TPS quota of the instance.
For example, if one producer sends 100 normal messages per second and two different consumer groups each subscribe to and consume the same topic, the actual TPS consumption is: write TPS = 100, read TPS = 100 × 2 = 200, for a total of 300 TPS against the shared instance quota. The more consumer groups that subscribe to the same topic, the higher the combined TPS consumption.
TPS consumption depends on the actual message processing rate, not on the number of consumer instances or consumer groups. If multiple consumer instances within the same consumer group share the workload, the read TPS of that group equals the sum of the actual consumption rates of all consumer instances — it does not automatically multiply as the number of consumers increases.
For example, if three consumer instances in one consumer group collectively consume 300 messages per second, the read TPS for that group is 300, not 300 × 3 = 900. The read TPS multiplier effect, where read TPS scales proportionally, occurs only when multiple consumer groups each independently consume every message in a topic.
Billing rules
The fees for the basic computing specification of an ApsaraMQ for RocketMQ instance are based on the specification size. Both subscription and pay-as-you-go billing methods are supported. The following table describes the billing details.
Item | Pay-as-you-go | Subscription |
Billable item | Fees are charged based on the purchased computing specification. | Fees are charged based on the purchased computing specification. |
Billing formula | Computing specification fee = Service duration after instance purchase (in hours) × Unit price of the specification (in USD/hour) Important For the pay-as-you-go billing method, the billable duration for a computing specification is the service duration after the instance is purchased. Billing starts immediately after purchase, regardless of whether an application is connected to the instance. | Computing specification fee = Subscription duration (in months) × Unit price of the specification (in USD/month) |
Billing logic | When you purchase an instance, select the desired computing specification to create the instance. No payment is required at this time. After the instance is purchased, billing starts immediately based on the billing specification and the instance service duration, regardless of whether the instance has started sending or receiving messages. At the end of a settlement period, a bill is generated, and the corresponding fees are deducted from your Alibaba Cloud account. | When you purchase an instance, select the desired computing specification and subscription duration (in months). Pay the calculated price to start using the instance. |
Billing period | Billed hourly Within the current billing period, if the service duration of an instance is less than 1 hour, it is calculated as 1 hour. For example, if an instance is purchased at 10:30, the computing specification fee for the billing period from 10:00 to 11:00 is 1 hour × unit price, not 0.5 hours × unit price. | Billed monthly |
Unit price | The specific unit price is subject to the price on the product purchase page. | |
FAQ about computing specification fees
Why am I being charged for a pay-as-you-go instance that I have not used?
The computing specification for ApsaraMQ for RocketMQ 5.0 Series pay-as-you-go instances is billed as follows:
After an instance is purchased, billing starts immediately based on the computing specification and the duration of the instance. This occurs regardless of whether you have started to send or receive messages using the instance.
What is the hourly fee for a pay-as-you-go instance? Am I charged even when the instance is idle?
For ApsaraMQ for RocketMQ 5.x series pay-as-you-go instances, the computing specification fee is billed on an hourly basis. The hourly unit price is the base price for the message sending and subscription computing specification. For the exact unit price, refer to the product pricing page.
Pay-as-you-go billing starts immediately after you purchase an instance, regardless of whether the instance is idle, whether any applications are connected, or whether messages are being sent or received. The base computing specification fee accrues as long as the instance exists. Idle instances are charged at the same rate as active ones. To stop billing, release the instance in the console.