I thought I’d start a blog series all about Azure – things I’ve learned while getting a few web sites up and running in the (Microsoft) cloud. First up – billing. Microsoft offers a “free” 90-day trial to get your feet wet, but BE CAREFUL, may not be free, especially when you quickly go over your quotas and start getting charged.
A lot of this information is available deep in the dark depths of the Azure SDK help, and you might just tell me to RTFM, but even as a Microsoft support engineer admitted to me: “there is WAY too much documentation out there, it’s impossible to find anything”. My thoughts exactly, and this is the reason for this quick post to summarize the information.
There are multiple “billing meters” used to charge you for your Azure usage: Compute Time, Database Size, Storage Amount, Storage Transactions, Data Transfer (in and out), and a couple others. I will focus on what we have found to be both the most misunderstood, as well as the meters for which you will most probably go over the free quota if you don’t know what to watch for: Compute Time and Storage Transactions.
Rule #1 – Compute Hours are NOT just the time your site is WORKING on a request
My first assumption was that if my site is hosted up there, but it’s not being hit very often, I won’t incur many (any?) compute hours. Turns out, compute hours are a measurement of how many hours your site (more correctly your instances) exist on the Azure servers. Back when I was starting with Azure, I wrote a super simple ASP.NET MVC “Hello World” app and published it to Azure – super easy. I first published to staging, incremented the instance count to 2 just to see how easy that was, and then published a new version to production. Out there, I set the instance count to 3, and learned how to “flip the VIP”, switching staging with production in (not exactly) the blink of an eye.
Fast forward 5 days later, and we get our first billing email, saying that we’ve reached the trial period’s limit of 700 COMPUTE HOURS! Seriously? 3 instances in production, 2 in staging, but nobody is hitting these sites, nobody would know they’re out there (for that matter the staging one has a GUID in the URL so it’s not discoverable by accident). Long story short, after further reading, I find that a compute hours is any portion of an hour that any of your instances (staging or production) are deployed to the cloud!
A couple more little gotchas:
- You get charged the first hour(s) the first minute your app gets deployed. When the clock strikes 12, the next hour starts. So if you deploy a single instance at 10:50AM, you will get charged 1 hour for the first 10 minutes, and then at 11:00, the second hour is charged. If you’re unlucky enough to deploy 5 instances in the 59th minute of an hour, you will get billed for 10 hours in 2 minutes of human time.
- Each time you deploy your project, a new clock is started. If you are iteratively trying something out and deploy 3 versions in an hour, you get hit for 3 hours (assuming single instance on a small VM).
- A “VM size factor” is used to multiply the hours for the larger VMs. A small instance (counts as 1 core) is a value of 1, medium 2, large 4, extra large 8.
To summarize the compute hours – here is the formula:
# of instances (each web and worker role instance counts individually, for both staging and production) * VM size factor * number of partial clock hours
Rule #2 – Turn off diagnostics before you publish to Azure
This one is really buried. There is a setting in the properties for each Azure role that allows you to turn diagnostics on or off – it’s ON by default. Diagnostics are captured by Azure on the local VM, and then persisted to YOUR storage account VERY FREQUENTLY if you have this turned on. The problem is, each time the logs are saved to your storage account, you get hit with storage transactions. In those first 5 days of my Hello World app, we were averaging over 7000 transactions per day. When you only get 50,000 transactions in the trial period, it’s easy to see how you can go over. The MS support engineer told me the default is that the logs are persisted EVERY MILLISECOND. I have trouble believing that, but that’s what he said. It’s “really fast” whatever it is.
Turn OFF diagnostics unless you need them, and if you need them, throttle down the period after which they’re persisted to storage.
Right click, properties on each role in your Azure project. In Configuration, clear the “Enable Diagnostics” checkbox.
If you DO need logging enabled, there are ways to control exactly what data gets logged and the period at which it’s written to your storage account. You can either use code in your OnStart method, or place a configuration file in your storage account to control the settings. I plan on writing a post about the configuration based method soon.
I think the bottom line with all this Azure billing – watch your bill (you can view it online through the portal) like a hawk, even if you have a simple app and are just in the “free” trial period. Always know what unit of measure you’re dealing with: human minutes, or Azure hours. 🙂