SALES: 1-800-867-1380

Service Bus Pricing FAQ

Updated: August 19, 2014

If you have questions about the Microsoft Azure Service Bus pricing structure, see the FAQ in the following section. You can also visit the Azure Platform pricing FAQ for general pricing information. For complete information about Service Bus pricing, see Service Bus Pricing Details.

noteNote
The pricing for Service Bus Event Hubs is described in Event Hubs Preview Availability and Support.

These meters are billed as follows:

  1. Messages – Messages sent to or delivered by Service Bus are billed at $0.01 per 10,000 messages. Messages are charged based on the number of messages sent to, or delivered by, Service Bus during the billing month. This includes delivery of “null” messages in response to receive requests against empty queues/subscriptions. Messages over 64KB in size are charged an additional message for each additional 64KB of data (rounded up). This meter applies to relays as well as queues, topics, and subscriptions.

  2. Relay Hours – This meter applies only when using the Service Bus relay capability. There is no relay hour charge if you are only using Service Bus queues, topics, and subscriptions. Relay hours are billed at $0.10 per 100 relay hours, and charged from the time the relay is opened (the first listener connect on a given relay address) to the close of the relay (the last listener disconnect from that relay address), and rounded up to the next whole hour.

For more information about Service Bus pricing, see Service Bus Pricing Details. In addition to the prices noted above for Service Bus, you are charged for associated data transfers for egress outside of the data center in which your application is provisioned. You can find more details in the What usage of Service Bus is subject to data transfer? What is not? section below.

Any data transfer within a given region is provided at no charge. Any data transfer outside a region is subject to egress charges at the rate of $0.15 per GB from the North America and Europe regions, and $0.20 per GB from the Asia-Pacific region. Any inbound data transfer is provided at no charge.

A relay is a Service Bus entity that relays messages between clients and Web services. The relay provides the service with a persistent, discoverable Service Bus address, reliable connectivity with firewall/NAT traversal capabilities, and additional features such as automatic load balancing. A relay is implicitly instantiated and opened at a given Service Bus address (namespace URL) whenever a relay-enabled WCF service, or “relay listener,” first connects to that address. Applications create relay listeners by using the Service Bus .NET managed API, which provides special relay-enabled versions of the standard WCF bindings.

Relay hours are billed for the cumulative amount of time during which each Service Bus relay is “open” during a given billing period. 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. The relay is 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. In other words, a relay is considered “open” whenever one or more relay listeners are connected to its Service Bus address.

In some cases, a single relay in Service Bus may have multiple connected listeners. This can occur with load-balanced services that use the netTCPRelay or *HttpRelay WCF bindings, or with broadcast event listeners that use the netEventRelay WCF binding. A relay in Service Bus is considered “open” when at least one relay listener is connected to it. Adding additional listeners to an open relay does not change the status of that relay for billing purposes. The number of relay senders (clients that invoke or send messages to relays) connected to a relay also has no effect on the calculation of relay hours.

Service Bus no longer charges for connections. However, there are quotas limiting the number of simultaneous connections that can be open against any single Service Bus entity. See the Does Service Bus have any usage quotas? section below.

Each message sent to or delivered by Service Bus counts as a billable message. This applies to all Service Bus entity types, including queues, topics/subscriptions, and relays.

A message is defined as a unit of data which is 64KB or less in size. In the case of brokered entities (queues and topics/subscriptions), any message that is less than or equal to 64KB in size is considered as one billable message. If the message is greater than 64KB in size, the number of billable messages is calculated according to the message size in multiples of 64KB. For example, an 8 KB message sent to Service Bus is billed as one message, but a 96 KB message sent to Service Bus is billed as two messages. In most cases, the same method of determining billable messages is applicable to relays as well. See How is the Messages meter calculated for relays? for details about the exception cases for relays.

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

In general, management operations and “control messages,” such as completes and deferrals, are not counted as billable messages. There are two exceptions:

  1. Null messages delivered by Service Bus in response to requests against an empty queue or subscription, are also billable. Thus, applications that poll against Service Bus entities will effectively be charged one message per poll.

  2. Setting and getting state on a MessageSession will also result in billable messages, using the same message size-based calculation described above.

In general, billable messages are calculated for relays using the same method as described above for brokered entities (queues, topics, and subscriptions). However, there are several notable differences:

  1. Sending a message to a Service Bus relay is treated as a “full through” send to the relay listener that receives the message, rather than a send to the Service Bus relay followed by a delivery to the relay listener. Therefore, a request-reply style service invocation (of up to 64 KB) against a relay listener will result in two billable messages: one billable message for the request and one billable message for the response (assuming the response is also <= 64 KB). This differs from using a queue to mediate between a client and a service. In the latter case, the same request-reply pattern would require a request send to the queue, followed by a dequeue/delivery from the queue to the service, followed by a response send to another queue, and a dequeue/delivery from that queue to the client. Using the same (<= 64 KB) size assumptions throughout, the mediated queue pattern would thus result in four billable messages, twice the number billed to implement the same pattern using relay. Of course, there are benefits to using queues to achieve this pattern, such as durability and load leveling. These benefits may justify the additional expense.

  2. Relays that are opened using the NetTCPRelay WCF binding treat messages not as individual messages but as a stream of data flowing through the system. In other words, only the sender and listener have visibility into the framing of the individual messages sent/received using this binding. Thus, for relays using the netTCPRelay bindng, all data is treated as a stream for the purpose of calculating billable messages. In this case, Service Bus will calculate the total amount of data sent or received via each individual relay on a 5-minute basis and divide that total by 64 KB in order to determine the number of billable messages for the relay in question during that time period.

Management operations, such as enumerating subscriptions on a topic or determining queue depth, and “control messages,” such as completes and deferrals, are not generally counted as billable messages. There are two exceptions:

  1. “Null” messages delivered by Service Bus in response to requests against an empty queue or subscription are billable. Therefore, applications that poll against Service Bus entities will effectively be charged one message per poll.

  2. Setting and getting state on a MessageSession will also result in billable messages, using the same message size based calculation described above.

No, Service Bus does not charge for storage. However, there is a quota limiting the maximum amount of data that can be persisted per queue/topic. See the Does Service Bus have any usage quotas? section below.

  • Assume all messages in each queue are delivered exactly once.

  • 1 message of 128 KB = 2 billable messages (128 KB/64 KB).

  • 2 billable messages sent per minute + 2 billable messages delivered per minute = 4 billable messages per queue per minute.

  • 4 messages per queue per minute * 1,440 minutes per day = 5,760 messages per queue per day.

  • Total billable messages per day sent to/delivered by Service Bus = 5,760 messages per queue per day * 100 queues = 576,000 messages per day.

  • 576,000 Service Bus messages cost 576,000/10,000 * $0.01 = 58 * $0.01 = $0.58 per day.

  • Assume all subscriptions receive all messages, and all messages in each subscription are delivered exactly once.

  • 1 message of 48 KB = 1 billable message.

  • 1 billable message per second * 86,400 seconds per day = 86,400 billable messages per day sent to the topic.

  • 86,400 messages per day * 4 subscriptions = 345,600 messages per day delivered to subscription clients.

  • Total billable messages per day sent to/delivered by Service Bus = 86,400 + 345,600 = 432,000 messages per day.

  • 432,000 Service Bus messages cost 432,000/10,000 * $0.01 = 44 * $0.01 = $0.44 per day.

  • Assume a request/reply pattern and all requests receive replies <= 64 KB in size.

  • 1 message of 8 KB = 1 billable message.

  • 1 billable message per second * 86,400 seconds per day = 86,400 billable messages per day for request messages sent via each relay.

  • Since all requests receive replies, also have 86,400 billable messages per day for reply messages sent via each relay.

  • Total billable messages per day per relay = 86,400 * 2 = 172,800.

  • Total billable messages per day sent to/received by Service Bus = 172,800 * 10 Relays = 1,728,000.

  • 1,728,000 Service Bus messages cost 1,728,000/10,000 * $0.01 = 173 * $0.01 = $1.73.

  • 10 relays open 24 hours = 240 relay hours.

  • 240 relay hours cost 240/100 * $0.10 = 3 * $0.10 = $0.30.

  • Total cost = $1.73 + $0.30 = $2.03 per day.

  • Assume a request/reply pattern and all requests receive replies <= 64 KB in size.

  • 8 KB per second * 3,600 seconds per hour = 28,800 KB per hour for request messages sent via each relay.

  • Since all requests receive replies, also have 28,800 KB per hour for reply messages sent via each relay.

  • Total message data per hour per relay = 57,600 KB.

  • 57,600 KB = 57,600/64 or 900 billable messages per hour per relay = 900 * 24 or 21,600 billable messages per day per relay.

  • Total billable messages per day sent to/received by Service Bus = 21,600 messages * 10 relays = 216,000.

  • 216,000 Service Bus messages cost 216,000/10,000 * $0.01 = 22 * $0.01 = $0.22.

  • 10 relays open 24 hours = 240 relay hours.

  • 240 relay hours cost 240/100 * $0.10 = 3 * $0.10 = $0.30.

  • Total cost = $0.22 + $0.30 = $0.52 per day.

By default, for any cloud service Microsoft sets an aggregate monthly usage quota that is calculated across all of a customer’s subscriptions. Because we understand that you may need more than these limits, please contact customer service at any time so that we can understand your needs and adjust these limits appropriately. For Service Bus, the aggregate usage quotas are as follows:

  • 5 billion messages

  • 2 million relay hours

While we do reserve the right to disable a customer's account that has exceeded its usage quotas in a given month, we will provide e-mail notification and make multiple attempts to contact a customer before taking any action. Customers exceeding these quotas will still be responsible for charges that exceed the quotas.

As with other services on , Service Bus enforces a set of specific quotas to ensure that there is fair usage of resources. The following are the usage quotas that the service enforces:

  • Queue/topic size – You specify the maximum queue or topic size upon creation of the queue or topic. This quota can have a value of 1, 2, 3, 4, or 5 GB. If the maximum size is reached, additional incoming messages will be rejected and an exception will be received by the calling code.

  • Number of concurrent connections

    • Queue/Topic/Subscription - The number of concurrent TCP connections on a queue/topic/subscription is limited to 100. If this quota is reached, subsequent requests for additional connections will be rejected and an exception will be received by the calling code. For every messaging factory, Service Bus maintains one TCP connection if any of the clients created by that messaging factory have an active operation pending, or have completed an operation less than 60 seconds ago. REST operations do not count towards concurrent TCP connections.

  • Number of concurrent listeners on a relay – The number of concurrent NetTcpRelay and NetHttpRelay listeners on a relay is limited to 25 (1 for a NetOneway relay).

  • Number of concurrent relay listeners per service namespace –Service Bus enforces a limit of 2000 concurrent relay listeners per service namespace. If this quota is reached, subsequent requests to open additional relay listeners will be rejected and an exception will be received by the calling code.

  • Number of topics/queues per service namespace – The maximum number of topics/queues (durable storage-backed entities) on a service namespace is limited to 10,000. If this quota is reached, subsequent requests for creation of a new topic/queue on the service namespace will be rejected. In this case, the management portal will display an error message or the calling client code will receive an exception, depending on whether the create attempt was done via the portal or in client code.

  • Message size quotas

    • Queue/Topic/Subscription

      • Message size – Each message is limited to a total size of 256KB, including message headers.

      • Message header size – Each message header is limited to 64KB.

    • NetOneway and NetEvent relays - Each message is limited to a total size of 64KB, including message headers.

    • Http and NetTcp relays –Service Bus does not enforce an upper bound on the size of these messages.

    Messages that exceed these size quotas will be rejected and an exception will be received by the calling code.

  • Number of subscriptions per topic – The maximum number of subscriptions per topic is limited to 2,000. If this quota is reached, subsequent requests for creating additional subscriptions to the topic will be rejected. In this case, the management portal will display an error message or the calling client code will receive an exception, depending on whether the create attempt was done via the portal or in client code.

  • Number of SQL filters per topic – the maximum number of SQL filters per topic is limited to 2,000. If this quota is reached, any subsequent requests for creation of additional filters on the topic will be rejected and an exception will be received by the calling code.

  • Number of correlation filters per topic – the maximum number of correlation filters per topic is limited to 100,000. If this quota is reached, any subsequent requests for creation of additional filters on the topic will be rejected and an exception will be received by the calling code.

For more information about quotas, see Azure Service Bus Quotas.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft