In this post, I talked about how web and worker roles are considered live the moment they are deployed, whether stopped or running. I received a few follow-up questions about billing when using the Staging area, as well as clarification on how compute-hours are measured.
Production and Staging
When deploying to Azure, you have a choice between Production and Staging:
This comes in handy when upgrading your application. Let’s say you have an application already in Production, and you now have a new version you’d like to upgrade to. You can deploy that new version to a separate Staging area, which provides you with a separate “test URL” as well as any worker and web roles your application needs. You can run this app just like you’d run your production app. When you’re done testing, swap staging and production. This is effectively a Virtual IP address swap, so your end-users simply see an upgraded application as soon as you choose to execute the swap.
This is a terrific feature, allowing you to test an application without service disruption. It also allows you to quickly swap back to the previously-deployed version if something go wrong after deploying your new version to production.
Once you’re sure your new version is working ok, consider deleting your service from Staging. Be aware that your staging area is also consuming virtual machine instances. Staging instances and Production instances are equivalent: Each instance is a Virtual machine; Staging instances are billed just like Production instances. If you leave your service deployed to both Production and Staging, you will be accruing Compute-Hour charges for both. Just keep this in mind when estimating your monthly Azure costs.
How the hour is metered
As each application is deployed, its virtual machines are created. The moment those virtual machines are in place, metering begins. This includes stopped services. For instance: assuming we clicked Deploy on the Production area of our service, and uploaded an application comprising one worker role and one web role, we’d then see our deployment in a stopped state:
At this moment, the billing clock begins for each of the instances, and billing is based on a 60-minute window: If you deploy at 4:16pm, your 60-minute window is from 4:16pm to 5:16pm (it’s not 4pm-5pm). In this example, I have two roles, with a combined consumption of 2 compute-hours per clock-hour.
If I decide to stop either of these roles before the entire hour is consumed, it’s still metered for the full hour.
Multiple Deployments in a Clock-Hour
Let’s say I delete my deployment after only 5 minutes. And then I decide to deploy again to Production. At this moment, the clock starts again for my new deployment. Using our sample app above, with one worker role and one web role:
- Deploy to Production at 4:16pm, delete deployment at 4:21pm. Compute-hours billed: 2
- Deploy again to Production at 4:25pm, delete deployment at 4:30pm. Compute-hours billed: 2
- Total clock time: 14 minutes. Total compute-hours: 4
I realize this is a contrived example, but I want to emphasize the fine details of compute-hours:
- Each instance is metered from the moment it comes to life in a Virtual Machine.
- Compute-hours are rounded up to the nearest hour. So a service is metered at 1 compute-hour, whether it runs for only 5 minutes or 59 minutes.
- Services deployed within the same clock-hour are completely unrelated, billing-wise. If you stop and delete your application and then deploy it again, all within the same clock-hour, you will still be billed separately for each deployment.