What is a brokered connection and how am I charged for them?
A brokered connection is defined as one of the following:
- An AMQP connection from a client into a Service Bus topic, subscription, queue or event hub.
- An HTTP call to receive a message from a Service Bus topic or queue that has a receive timeout value greater than zero. Microsoft charges for the peak number of concurrent brokered connections that exceed the included quantity (1,000 in the standard and premium tiers). Peaks are measured on an hourly basis, prorated by dividing by 730 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. Examples:
- 5,000 clients each connect via a single AMQP connection 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): 5,000 connections * 12 hours * 30.5 days/730 = 2,500 brokered connections. After the monthly allowance of 1,000 brokered connections, you would be charged for 1,500 brokered connections.
- 5,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): 5,000 HTTP receive connections * 12 hours per day * 30.5 days/730 hours = 2,500 brokered connections.
Related questions and answers
A hybrid connection allows you to establish bi-directional, binary stream communication between two networked applications, and 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.
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 only closed 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 until the time the last relay listener disconnects from the Service Bus address of that relay.
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.
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.
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. If a message exceeds 64 KB, such as an HTTP reply that returns an image, each further 64 KB counts as an additional billable message. For a normal relayed service that implements a request/response scheme, the request first travels to the relay, then to the service, and the reply traverses the same path. That amounts to at least four billable messages. For a multicast service that has 4 listeners, the message sent to the relay counts as 1 message, and the 4 messages sent to the listeners also each count as a message, resulting in a total of 5 messages.
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 to be 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 reading. 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 TypeDescription ManagementCreate, read, update, delete against queues, topics or subscriptions MessagingSending and receiving messages with queues, topics or subscriptions Session stateGetting or setting session state on a queue, topic or subscription Premium tier does not charge for operations up to the purchased capacity limit.