How to calculate costs for Service Bus?

When working with Windows Azure Service Bus, architects and developers have an additional conceptual task. This is cost estimation based on number of messages which will system exchange. 
Depending on system this might be very complex task. Usually when you started to plan the solution, project owners usually want to know the budged (costs) long before the project is started. 
Unfortunately the relative precise cost estimation is possible after the technical design of the system is completed. In a case of Service Bus this might be even more complex. Even after technical design 
you will probable not know exactly ho many messages will flow through the system. 
Typically, Service Bus messages are grouped in two groups according to used entities: 

• Topic and Queue messages 
• Relay Messages

Pricing details can be found here. 

To explain how to estimate costs I will use following hypothetical system.

http://developers.de/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/damir_5F00_dobric/image_5F00_thumb_5F00_385DCAC7.png

As you see, this system uses Topics. By explaining of topics cost estimation we will automatically learn how to estimate costs for Queues. Cost estimation of Relays is not explained in this post. 
Fortunately you can apply same Topic/Queue rules on Relay. According to pricing details the charging unit is a message package (sometime called operation package). For example for N messages you have to pay K EUR. 
That means, each time the message is sent or received the message counter is incremented. 

Example: 

Assume you have a system like shown at the picture above with one subscriber only. Sender sends one message and receiver receives the message. This process requires obviously two messages. 
Please note that maximum message size is limited by 256kB.However billing of the message is related to 64k block size. That means if you send a single message of 256 kB, it will be billed in 4 block of 64kB. 
If the message size is less than 64kB it is treated as one message. That means you can send 4 messages with 10kb size or one message with 200kb, you will be billed for 4 64kB blocks. In other words you will be billed for 4 messages. 
As next example, an 8 KB message sent to the Service Bus will be billed as one message, but a 96 KB message sent to the Service Bus will be billed as two messages.

Example :

Assume you have now a topic with two subscriptions. You send 1 message  (<64kB) to the topic. If both receivers receive the message we will be charged for 3 messages (1 to topic + 2 from subscriptions). 
If the message is 100kB, then we will have 2*3 messages, because each one is treated as two, because it fits in two 264kB blocks.

If we one receiver don’t receive the message it will not be charged.

Almost all high-level SDKs of Service Bus sends controlling messages when Abandon(), Complete() and related methods are invoked.Usually you are not aware of this. Anyhow these messages are not charged.

Please note, if one receiver is trying to receive the message and there is no message in the queue, one empty message (NULL-message) will be received and charged.

Setting and getting state on a MessageSession will also result in billable messages.

 

Last but not least, all traffic will be additionally charged for network traffic. Fortunately in most service bus solutions this charge can be almost ignored.

 If you are interested on this topic, you can also read Service Bus undocumented scaling tips & tricks