Service Bus

Connect across private and public cloud environments


Azure Service Bus is a messaging infrastructure that sits between applications allowing them to exchange messages for improved scale and resiliency.

Pricing Details

Service Bus comes in Basic and Standard tiers, and premium tiers. Here’s how they compare:

Features Basic Standard Premium
Scheduled messages
Topics -
Transactions -
De-duplication -
Sessions -
ForwardTo/SendVia -
Message size 256 KB 256 KB 1 MB
Brokered connections included 100 1,000 1 1,000 per MU
Brokered connections (overage allowed) - (billable) Up to 1,000 per MU
Resource isolation
Geo-Disaster Recovery (Geo-DR)

*Requires additional Service Bus Premium namespaces in another region.

Service Bus premium runs in dedicated resources to provide higher throughput and more consistent performance.
1 1,000 brokered connections are included with the standard messaging tier (via the base charge) and can be shared across all queues, topics, subscriptions, and event hubs within the associated Azure subscription.

Message Transfer Operations

An operation is any API call to the Service Bus service.

Starting May 2, 2018, customers will be billed at an hourly rate for Service Bus standard base units. This replaces the current daily and monthly rate billing, making it more consistent with other Azure services. Your customers will pay only for the number of hours they use Service Bus rather than for a whole day or month.

*The following prices are tax-inclusive.

*Monthly pricing estimates are based on 744 hours of usage per month.
Operations ¥0.31 per million operations
Basic charge 1 ¥0.0851/hour (about¥63.3144/month)
First 13M operations/month Included
Next 88M operations (13M - 100M operations)/month ¥5.21 per million operations
Next 2,400M operations (100M - 2,500M operations)/month ¥3.20 per million operations
Over 2,500M operations/month ¥1.27 per million operations

1 Allocated in proportion every hour, 744 hours every month.

Hourly ¥9.4382/hour (about¥7,022.0208/month)

Brokered connections

Number of AMQP connections or HTTP calls to Service Bus.

*The following prices are tax-inclusive.

*Monthly pricing estimates are based on 744 hours of usage per month.
Standard Tier  
First 1k/month Included
Next 99K (1K – 100K)/month ¥0.18 per connection/month
Next 400K (100K – 500K)/month ¥0.15 per connection/month
Over 500K/month ¥0.10 per connection/month

This will be charged by the peak amount of concurrent connections, and the expenses are allocated in proportion every hour, 744 hours every month.

Brokered connections are not charged in the premium tier.

Hybrid connections

Mixed connection is charged per listener, including 5 GB/month of data transmission. In the event of excess of this limit, the extra parts will also be charged.

Hybrid Connection Pricing  
Connection charge (including 5 GB data/month) 1 ¥76.087/listener per month
(¥0.102/listener per hour)
Data transfer overage (data exceeding the included 5 GB/month) ¥13.398/GB
1 The data transfer limit of 5 GB covers total data transfer across all listener units.


*The following prices are tax-inclusive.

*Monthly pricing estimates are based on 744 hours of usage per month.
Relay Pricing  
Relay hours ¥0.52 for every 100 relay hours
Messages ¥0.05 for every 10,000 messages


Expand All
  • How is the number of relay messages calculated?

    The relay counts each message sent to the relay, and each message sent by the relay, as billable. A billable message is a data frame of at most 64 KB.

  • How is the operations meter calculated for queues and topics?

    For brokered entities (queues and topics or subscriptions), an operation is any API interaction with Service Bus service on any protocol.

    A send, receive, delete for a message that's less than or equal to 64 KB in size is considered as one billable operation. If the message is greater than 64 KB in size, the number of billable operations is calculated according to the message size in multiples of 64 KB. For example, an 8-KB message sent to the Service Bus will be billed as one operation, but a 96-KB message sent to the Service Bus will be billed as two operations. Reading the 8-KB message with a lock and then completing or explicitly abandoning the message will be billed as two operations. Renewing the lock on a message also incurs an operation.

    Multiple deliveries of the same message (for example, message fan out to multiple subscribers or message retrieval after abandon, deferral, or dead lettering) will be counted as independent operations. For example, in the case of a topic with three subscriptions, a single 64 KB message sent and subsequently received will generate four billable operations, one "in" plus three "out," assuming all messages are delivered to all subscriptions and deleted during the read.

    You can receive messages by using PeekLock’s ReceiveMode, then deleting the message through a complete call, which will generate two individual operations. Relocking the message will also generate one operation.

    Additionally creating, reading (listing), updating, and deleting a queue, topic, or subscription will each incur an operation charge.

    Operations are API calls made against queue, topic, or subscription service endpoints. This includes management, send/receive, and session state operations.

    Operation Types Description
    Management Create, read, update, delete against queues, topics, or subscriptions
    Messaging Sending and receiving messages with queues, topics, or subscriptions
    Session state Getting or setting session state on a queue, topic, or subscription
  • How are relay hours calculated?

    Relay hours are billed for the cumulative amount of time during which each Service Bus Relay is "open". A relay is implicitly instantiated and opened at a given Service Bus address (service namespace URL) when a relay-enabled WCF service, or "relay listener," first connects to that address. It's closed only when the last listener disconnects from its address. Therefore, for billing purposes a relay is considered "open" from the time the first relay listener connects, to the time the last relay listener disconnects from the Service Bus address of that relay.

  • What is a brokered connection and how do I get charged for them?

    A brokered connection is defined as one of the following:

    1. An AMQP connection from the client into a Service Bus topic, subscription, queue, or event hub.
    2. An HTTP call to receiving a message from a Service Bus topic or queues that has a receive timeout value greater than zero.
      Charges for the peak number of concurrent brokered connections that exceed the included quantity (1,000 in the standard tier). Peaks are measured on an hourly basis, prorated by dividing by 744 hours in a month, and added up over the monthly billing period. The included quantity (1,000 brokered connections per month) is applied at the end of the billing period against the sum of the prorated hourly peaks.7
      1. 10,000 clients connect via a single AMQP connection each, and receive commands from a Service Bus topic and send events to queues. If all clients connect for 12 hours every day, you will see the following connection charges (in addition to any other Service Bus charges)—10,000 connections * 12 hours * 31 days / 744 = 5,000 brokered connections. After the monthly allowance of 1,000 brokered connections, you would be charged for 4,000 brokered connections at a rate of RMB0.18 for every brokered connections, total¥720.
      2. 10,000 clients receive messages from a Service Bus queue via HTTP, specifying a non-zero timeout. If all devices connect for 12 hours every day, you will see the following connection charges (in addition to any other Service Bus charges): 10,000 HTTP receive connections * 12 hours per day * 31 days / 744 hours = 5,000 brokered connections.
  • Do brokered connection charges apply to queues and topics/subscriptions?

    Yes, they do. There are no connection charges for sending events using HTTP, regardless of the number of sending systems or devices. Receiving events with HTTP using a timeout greater than zero, sometimes called "long polling," generate brokered connection charges. AMQP connections generate brokered connection charges regardless of whether the connections are being used to send or receive. Note that 100 brokered connections are allowed at no charge in a basic namespace (this is also the maximum number of brokered connections allowed for the Azure subscription). The first 1,000 brokered connections across any and all standard namespaces in an Azure subscription are included at no extra charge (beyond the base charge). Since these allowances are enough to cover many service-to-service messaging scenarios, brokered connection charges usually only become relevant if you plan to use AMQP or HTTP long-polling with a large number of clients, for example, to achieve more efficient event streaming, or enable bi-directional communication with thousands or millions of devices or app instances.

  • Will I be charged multiple base charges if I have multiple standard namespaces in my Azure subscription?

    No, the standard base charge is billed only once per month per Azure subscription. This means that after you create a single standard tier Service Bus namespace, you will be able to create as many additional standard tier namespaces as you like under that same Azure subscription without incurring additional base charges.

    For other FAQs about Service Bus billing, please refer to MSDN articles.

  • How is the premium tier different from the others?

    The premium tier of Service Bus messaging provides all the messaging features of Azure Service Bus queues and topics with predictable, repeatable performance, higher throughput, and improved availability. The premium tier uses a dedicated resource allocation model to provide workload isolation and consistent performance. Because the compute and memory resources in the premium tier are dedicated, there are no per-message transaction charges as in other tiers. All transactions are included in the message unit allocation.

  • What is a messaging unit?

    A messaging unit is a set of dedicated resources exclusively reserved for premium namespaces. This resource set can deliver a consistent and repeatable performance of messaging workloads. Each premium namespace can have 1, 2, or 4 messaging units and the resource allocation grows linearly—2 messaging units will consist of twice as many resources allocated as 1 messaging unit.

  • How does billing work for the premium tier?

    The premium tier of Service Bus messaging is a flat daily rate per messaging unit purchased. Namespaces created as premium can have 1, 2, or 4 messaging units which will each accrue the given number of messaging unit daily rate charges. Premium namespaces can have the number of purchased messaging units changed at any time, but the daily rate is based on the maximum number of message units assigned to the namespace at any time.

  • Can I upgrade or downgrade between premium and other tiers?

    Yes, it's technically possible to upgrade and downgrade between premium and other tiers. For guidelines on how to migrate your solution from standard messaging to premium messaging please read this blog post.

  • What is a hybrid connection?

    A hybrid connection allows you to establish bi-directional, binary stream communication between two networked applications, one or both parties can reside behind NATs or Firewalls. The listener that accepts this relayed connection and the sender that initiates the connection can both be implemented on any platform, and in any language, that has a basic WebSocket capability, including the WebSocket API in most web browsers.

  • How are mixed connections billed?

    When you create your first hybrid connection listener you will be charged at a per listener unit rate. The same rate applies to each individual listener that you decide to create. 5 GB of free data transfer per month is included with the service. You can use the 5 GB of free data transfer across all your listener units. You will be charged for data transfer overage if your aggregate data transfer across all listener units is more than 5 GB.

    Pricing example 1: If you have a single listener, such as an instance of the hybrid connections manager installed and continuously running for the entire month, and you send 3 GB of data across the connection during the course of the month, your total charge will be¥76.09.

    Pricing example 2: If you have a single listener, such as an instance of the hybrid connections manager installed and continuously running for the entire month, and you send 10 GB of data across the connection during the course of the month, your total charge will be¥143.077. That's based on¥76.087 for the connection and first 5 GB plus¥66.99 for the additional 5 GB of data.

    Pricing example 3: If you have two instances, A and B, of the hybrid connections manager installed and continuously running for the entire month, and you send 3 GB of data across connection A, and 6 GB across connection B, for a total of 9 GB of data, your total charge will be¥205.766. That's based on¥76.087 for connection A plus¥76.087 for connection B plus¥53.592 for the additional 4 GB of data overage.

  • Is there any data transfer charge to make a connection to the hybrid connection listener?

    We will charge 64 KB for each connection to your listener. This will be deducted from the 5 GB free we offer each month with listener units. The listener unit charge is calculated per hour in increments of 5 minutes. You will not be charged for multiple opens and closes for dev/test purposes.

  • How long will a hybrid connection listener remain open if there is no data transfer? What is the charge to keep the connection open?

    If you open a connection and do not transfer any data, we will transfer 1 KB each minute on your behalf to keep the connection alive. We do this so the network doesn’t auto-close the connection every few minutes.

Support & SLA

If you have any questions or need help, please visit Azure Support and select self-help service or any other method to contact us for support.

For Service Bus Relay, we guarantee that at least 99.9% time, applications configured correctly can establish connections with the deployed relay.

For the Service Bus queues and themes, we guarantee that at least 99.9% of the time, applications configured correctly can send or receive messages or perform other operations on the deployed queues or themes.

To learn more about the details of our Service Level Agreement, please visit the Service Level Agreements page.