Before I publish the next post on Relayed Messaging, I thought I would take this opportunity to share some lessons learned yesterday about the AppFabric Service Bus billing.
While I was preparing to present on the Azure Service Bus at some recent Code Camps, I decided to create a different Service Bus namespace for every session in an effort to tailor the code to the audience. I selected the pack of 5 connections for each of the namespaces rationalizing that I would not go over 5 concurrent connections at any point during any of my demos. The scenario I did not completely think through was that by provisioning the namespaces a few days in advance of my sessions and running several tests to ensure I was hitting the right namespace, the cycles had a much larger impact on my overall monthly allowance than I expected. I am operating off of my MSDN Premium Subscription which provides me with a pack of 5 Service Bus Connections total for the month. If I were to consume more than the allotted 5 connections averaged out over the entire billing cycle, I would need to pay an additional per connection charge. I did not pay close enough attention to the incremental, daily bill (which Microsoft provides) during the days leading up to my presentations which would have alerted me to the consumption boost that I imposed on myself. In order to keep track of charges against an Azure Subscription, go to the
Microsoft Azure Portal and select ‘View My Bills’ from the Actions pane on the right.
- For a summarized view of the current charges, click the AppFabric Usage Charges link.
- For a detailed view of the unique charges accumulated per day, click the Daily Usage link.
Prior to yesterday, I did not appreciate the functionality to export the data to a CSV file from within the Daily Usage page, but the exported data allowed me to filter and drill-down into the specific charges that pushed me over the limit. Without even looking at the specific consumption details, I could see that I had 40 line items just in the Service Bus Connections breakdown for a 31 day billing cycle – a big red flag. When I reviewed the exported data, I was finally able to see precisely how the charges piled up:
| Days of Use | Consumption(5 Connection Pack/31 days) | Total | |
|---|---|---|---|
| Namespace1 | 23 | .16129 | 3.709692 (GOOD) |
| Namespace2 | 11 | .16129 | 1.77419 (GOOD) |
| Namespace3 | 6 | .16129 | 0.96774 (GOOD) |
| COMPILED TOTAL | 40 | .16129 | 6.4516 (BAD) |
Whoops. While each individual namespace stayed within the 5 connection threshold, I managed to over consume when all of the charges were aggregated. With the consumption aggregated, the total processing of 6.4516 put me over the limit and generated a charge of (6.4516 – 5) * $1.99 = $2.98. I am hopeful that I will be able to absorb the cost or work out a payment plan with Microsoft. The point is I lost sight of the fact that I had multiple namespaces concurrently provisioned and at least one transaction per day on each namespace for at least a week. My decision to provision multiple namespaces and consume cycles on each caused multiple charges to accrue for the same day on each namespace, effectively double billing, sometimes triple billing and ultimately taking me over the limit when the charges for the month were compiled. It appears that I would not have gone over my limits if I had simply kept all of my demos under one namespace. I specifically told the Code Camp attendees to understand the billing practices in order to not get caught off guard. Touché. This is fantastic advice that I will follow a bit more closely in the future.
Additional Resources
Microsoft Online Services Customer Portal
https://mocp.microsoftonline.com/Site/Home.aspx
Help and How-to -> Read a Bill for Windows Azure Platform
http://www.windowsazure.com/en-us/support/contact
Windows Azure Pricing Overview
http://www.windowsazure.com/en-us/pricing/calculator/