How Do You Figure Out the Cost of Using the Azure AppFabric Service Bus?

So the Windows Azure platform AppFabric was recently launched into production and made available for commercial use.  For many of us, this meant that Azure moved from “place to mess around with no real consequences” to “crap, I better figure out what this is going to cost me.” 

I’ve heard a few horror stories of folks who left Azure apps online or forgot about their storage usage and got giant bills at the end of the month.  This just means we need to be more aware of our cloud service usage now.

That said, I’ve personally been a tad hesitant to get back into playing with the Service Bus since I didn’t fully grok the pricing scheme and was worried that my MSDN Subscription only afforded me five incremental “connections” per month.

Today I was pointed to the updated FAQ for AppFabric which significantly cleared up what “connections” really meant.  First off, a “connection” is established whether the service binds to the AppFabric Service Bus, and also when a client(s) bind to the cloud endpoint.  So if I have a development application and press F5 in Visual Studio, when my service and client bind to the cloud, that counts as 2 “connections.”

Now if you’re like me, you might say “sweet fancy Moses, I’ll use up my 5 connections in about 75 seconds!”  HOWEVER, you aren’t billed for an aggregate count of connections, but a concurrent average.  From the FAQ (emphasis mine):

That means you don’t need to pay for every Connection that you create; you’ll only pay for the maximum number of Connections that were in simultaneous use on any given day during the billing period. It also means that if you increase your usage, the increased usage is charged on a daily pro rata basis; you will not be charged for the entire month at that increased usage level.  For example, a given client application may open and close a single Connection many times during a day; this is especially likely if an HTTP binding is used. To the target system, this might appear to be separate, discrete Connections, however to the customer this is a single intermittent Connection. Charging based on simultaneous Connection usage ensures that a customer would not be billed multiple times for a single intermittent Connection.

So that’s an important thing to know.  If I’m just testing over and over, and binding my service and client to the cloud, that’s only going to count as two of my connections and not put me over my limit.

As for how this is calculated, the FAQ states:

The maximum number of open Connections is used to calculate your daily charges. For the purposes of billing, a day is defined as the period from midnight to midnight, Coordinated Universal Time (UTC).Each day is divided into 5-minute intervals, and for each interval, the time-weighted average number of open Connections is calculated. The daily maximum of these 5-minute averages is then used to calculate your daily Connection charge.

So, unless you are regularly binding multiple clients to an endpoint (which is possible when we’re talking about the event relay binding), you shouldn’t worry too much about exceeding your “connection pack” limits.  The key point is, connections are not incrementally counted, but rather, calculated as part of concurrent usage.

Hope that helps.  I’ll sleep better tonight, and bind to the cloud better tomorrow.