In my recently published post, “Readying Windows Azure to supplement Office (365/2010)”, I talked about how Windows Azure could be used for custom application hosting, in supplementation to Office 365 subscriptions and/or Office 2010. However, as is the case with many cloud services, it can be very difficult to realize both the upfront and long-term costs associated with various pricing constructs. In this post, I hope to clarify a lot of the cagey Azure rates by defining the factors (billing meters as they are called) involved in its pricing model, in respect to some of the more commonly used Azure services. Secondly, I will briefly lay out some strategy to help estimate the cost of a typical Azure application deployment.
Like paying rent
Before attempting to comprehend how Windows Azure pricing works, relative to a particular type of service, one might first endeavor to correlate its overall pricing to something from everyday life. To provide an example, think of Azure in terms of paying rent on an apartment, as well as for additional items like utilities and home furnishings, which all help to make up the idea of living comfortably in one’s home. Furthermore, consider the idea that without utilities like water, heat and electric, and certain luxurious home furnishings like a bed and kitchen table for eating, how beneficial it might be to pay rent for the apartment in the first place - or not. Lastly, also consider how sometimes a landlord (in the case of Azure, this would be Microsoft) might bundle certain utilities and/or home furnishings into the rent.
With the above analogy in mind, one can think of rent on the apartment as comparable to paying for Azure’s Compute and/or VM Role services, as well as Azure’s storage options, as with BLOBs, tables and queues. One could think of paying for utilities as comparable to paying for services like Service Bus, Connect, and ACS. Lastly, think of paying for what can be thought of as non-essential home furnishings, as comparable to paying for perk services like Business Intelligence, or even for those ready-made applications that can be purchased under the Windows Azure Marketplace.
Fundamentally, and not too dissimilar to other scalable cloud services, like Amazon EC2, Windows Azure calculates and charges for resource utilization based upon CPU, bandwidth, storage and the amount of strongly defined service transactions. As seen under Azure’s pricing calculator web page, one can notice how these broad categories break down into the following factors, of which, I’ll go into greater detail.
A Compute Instance could be thought of in the same manner one thinks of an on-premise server. You have a certain amount of physical and network resources available to you. However, if you have too many applications or services running at the same time, the amount of limited resources can become stifling, and bog down performance.
Probably the most important thing to note about the Compute Instance metric is that it only applies to deployed applications. Once you deploy your application, Compute Hours, which range anywhere from $0.05 to around a dollar per service hour, begin to apply.
Every SQL Azure database is charged on a monthly basis, which is dependent on the database edition you use (Web or Business editions). Another dependent factor is the amount of storage used within each database. The Web Edition database only scales slightly up to 5GB, while the Business Edition caps off at robust 50GB.
Storage and transactions
Storage concerns BLOBs, tables, queues and drive storage, which is billed based upon the amount of data stored, within a given month. Transactions, which concern the operations used to add, update, read, and delete that storage data are charged additionally. This is not to be confused with the Data Transfer meter, which is something almost entirely different.
In complex solutions, as with disaster recovery, as well as with web applications that might be referenced throughout the world, large enterprises have the option of staging deployments within Microsoft data centers located in various countries. This is charged by GB egress, or the data that is moved between these data center regions.
Content Delivery Network
The CDN is a hard service to comprehend. Therefore, this makes the challenge of understanding how pricing works that much harder. Essentially, the concept behind this service is to situate data closer to those users who might be more apt to use it. Also, it can provide some performance gain in terms of streaming a higher amount of bandwidth. CDN is obscurely charged based on request, and in accordance with the data center in which it is delivered from (see Data Transfer above).
Access Control and Service Bus
In most enterprise architectures, a hybrid solution of Azure hosted deployments will be used in conjunction with on-premise ones — a situation that even Microsoft admits to be something of an inevitability. This is exactly where the Service Bus comes in to play. This type of connectivity is simply charged by the number of connections from one data source to another.
Access Control is an add-on service for developers who want an easy-to-use, integrated identity management programming model. It holds the ability to hook up to known LDAP identity directories like Active Directory, as well as with authorization service APIs like Windows Live ID and Google. Although it is offered as an elective as part of a flat-fee subscription, Access Control is also priced on a pay-as-you-go basis, at $1.99 per 100k transactions.
Regardless of the amount of actual cache used, the AppFabric Cache service, or designated amount of in-memory cache provisioned to a deployment, is simply based on the amount of elected storage. Yes, this is probably the most straightforward of all meters. Oddly enough, it’s probably one of the more underutilized services.
Getting a full understanding of the pricing implications bracketed with Azure’s metered use, not to mention the consequences of connecting and sharing data with both on-premise and one of Microsoft’s global data centers, could be noted as an extremely hands on experience. To lessen the financial burden of experimentation, it’s wise to understand how metered usage works in terms of the needed service (as done above), but to also try and apprehend any expected overage charges, as well as come to terms with the idea that system-wide Azure outages are probably not going to be reimbursed (especially in the case of lower-cost offerings).
A good place to start with all this are Azure’s SLAs, which are actually written for the layperson (not in legalese), and the OSA, respectively. Outside of that, if you are planning to at start with a small Compute deployment, the 90-day free trial is a good hedge, so long as you recognize that you’ll still be charged for any overages. Also, an even better hedge for developers might be to download the Windows Azure SDK, and work with it locally, for practically nothing. However, so long as you already have a Windows PC and Visual Studio, that cost will have to be allocated to your municipal electric company alone.