All Products
Search
Document Center

ApsaraMQ for RocketMQ:Billing

Last Updated:Mar 11, 2026

ApsaraMQ for RocketMQ Enterprise Platinum Edition uses the subscription (prepaid) billing method. Each instance is billed based on a fixed combination of peak TPS, maximum topics, and message storage capacity. This reserves dedicated resources with a guaranteed service level agreement (SLA) for production workloads that require high reliability or handle large message volumes.

Compared with Standard Edition, Enterprise Platinum Edition provides higher availability and supports attribute-based SQL filtering and pull consumers.

Billable items

The subscription fee for an Enterprise Platinum Edition instance is determined by three billable items:

Billable itemDescription
Peak TPSThe maximum number of API calls per second for sending and receiving messages. See How API calls are counted for details.
Maximum topicsThe maximum number of topics that can be created on the instance.
Message storageThe size of exclusive physical storage space allocated to the instance.
Total subscription fee = Peak TPS fee + Maximum topics fee + Message storage fee

For current prices, see the Enterprise Platinum Edition buy page.

How API calls are counted

Peak TPS measures the total number of send and receive API calls per second. The following rules determine how API calls are counted.

Normal messages vs. advance-featured messages

Message typeMultiplierCounting rule
Normal message1xEach send or receive operation counts as 1 API call, regardless of whether the message is consumed.
Advance-featured message5xEach send or receive operation counts as 5 API calls.

Advance-featured messages include scheduled messages, delayed messages, transactional messages, and ordered messages. Normal messages are the only type that does not use the 5x multiplier. For more information, see Message types.

Example: A transactional message is received once and delivered to consumers twice. The total API call count is:

(1 receive x 5) + (2 deliveries x 5) = 15 API calls

Message body size

API calls are calculated in 4 KB increments, up to a maximum message body size of 4 MB.

Message sizeAPI call count per operation
Up to 4 KB1
8 KB2
16 KB4
64 KB16

Formula: API calls per operation = ceil(message size in KB / 4)

Both multipliers stack. For example, a 16 KB advance-featured message costs (16 / 4) x 5 = 20 API calls per operation.

HTTP protocol consumption

When consuming messages over HTTP, the consumer client actively polls the broker to retrieve messages. Two polling modes are available:

Polling modeBehaviorAPI call counting
Long polling (recommended)If no messages are available, the request stays open for up to 30 seconds until a message arrives or the wait time expires.Messages returned: counted using the standard multipliers (message type x message size). No messages returned: counted as 1 API call.
Short pollingIf no messages are available, the server returns an empty response immediately. The client then sends another request.Each request counts as 1 API call, even if no messages are returned.
Important

Short polling can generate a large number of empty requests when no messages are available, and each request is still billed as an API call. Use long polling to reduce unnecessary costs. For configuration details, see Subscribe to messages.

FAQ

How are transactional messages billed?

Transactional messages are advance-featured messages. Each send or receive operation counts as 5 API calls. For example, if a transactional message is received once and delivered twice, the total is (1 + 2) x 5 = 15 API calls. The message body size multiplier applies on top of this. A 16 KB transactional message that is received once and delivered twice costs (1 + 2) x 5 x (16 / 4) = 60 API calls.

Does message size affect billing?

Yes. API calls are calculated in 4 KB increments. A 16 KB message counts as 4 API calls per operation. This size multiplier stacks with the advance-featured message multiplier.

Which polling mode should I use for HTTP consumption?

Use long polling. Short polling generates continuous requests even when no messages are available, and each empty request counts as a billed API call. Long polling waits up to 30 seconds for messages, reducing billed requests during idle periods.

See also