• <1 minute

Windows Azure Platform Billing Overview

There have been a lot of questions about how Windows Azure Platform billing works so we thought we'd provide some additional explanations and definitions.  Feel free to contact…

There have been a lot of questions about how Windows Azure Platform billing works so we thought we’d provide some additional explanations and definitions.  Feel free to contact Microsoft Online Services customer support or post a comment here if you have any additional questions.  You can also review the Windows Azure Platform Offers Comparison Table to help you decide which of the current Windows Azure Platform Offers best suits your needs.

The Microsoft Online Customer Service Portal (MOCP) limits one Account Owner Windows Live ID (WLID) per MOCP account.  The Account Owner can create and manage subscriptions, view billing and usage data and specify the Service Administrator for each subscription.  Large companies may need to create multiple subscriptions in order to design an effective account structure that supports/reflects their go-to-market strategy. The Service Administrator (Service Admin WLID) manages services and deployments but cannot create subscriptions.

For each MOCP account, the Account Administrator can create one or more subscriptions. For each subscription, the Account Administrator can specify a different WLID as the Service Administrator.  The Service Administrator WLID can be the same or different as the Account Owner and is the persona who actually uses the Windows Azure Platform.  The creation of a subscription in the Microsoft Online Customer Service Portal (MOCP) portal results in a Project in the Windows Azure portal.

The diagram below shows the relationship between components. You can currently upgrade any of the components in GREEN:

 

Projects

A project can allocate up to twenty Services. Resources in the Project are shared between all the Services created. The resources are divided into Compute Instances/Cores and Storage accounts:

  • By default the Project will have 20 Small Compute Instances that you can utilize. These Small Compute Instances could be any combination of VM sizes so long as the total number of Cores across all deployed services within the Project does not exceed 20.
  • If you need to increase the number, contact Microsoft Online Services customer support and they will verify the billing account and provide the requested Small Compute Instances/Cores, subject to a possible credit check. You can also design how you want to have the Cores allocated. By default, the available resources are counted as number of Small Compute Instances. This is the conversion on Compute Instances: 

 

Compute Instance Size

CPU

Memory

Instance Storage

Small

1.6 GHz

1.75 GB

225 GB

Medium

2 x 1.6 GHz

3.5 GB

490 GB

Large

4 x 1.6 GHz

7 GB

1,000 GB

Extra large

8 x 1.6 GHz

14 GB

2,040 GB

Table 1: Compute Instances Comparison

  • The Compute Instances are shared between all the running services in the project (including Production and Staging environments), so you can have multiple Services with different number of Compute Instances, up to the number of maximum available for that Project.
  • 5 Storage accounts per Project. You can request to increase this up to 20 Storage accounts per Project by contacting Microsoft Online Services customer support. If you need more than 20 Storage accounts, you will need to purchase a new subscription.

Services

You can have a total of 20 Services per Project.  Services are where applications are deployed and each Service provides two environments: Production and Staging.  This is visible when you create a service in the Windows Azure portal.   

A Service can have a maximum of five roles per application. This includes any combinations of different web and worker roles on the same configuration file up to a maximum of 5. Each role can have any number of VMs. For example:

Standard 3-tier Application: Web-Business-Data Tiers to Windows Azure Roles

 

In this example the Service has 2 roles, each role with a specific worker role. Web Role worker, web tier, takes care of the Web interface. The Worker Role, business tier, is responsible for the business logic. Each role can have any number of VMs/Cores, to the maximum available on the Project.

From the Azure resources perspective, if we deploy this service we will be using the following resources:

1 x Service

–       Web Role = 3 Small Compute Nodes (3 x Small VMs)

–       Worker Role = 4 Small Compute Nodes (2 x Medium VMs)

–       2 Roles used

Total resources left on the Project:

–       Services (20 -1) = 19

–       Small Compute Nodes (20 – 7) = 13 small compute instances

–       Storage accounts = 5

NOTE: You will get billed for role resources utilized on a deployed Service, even if the roles on those Services are not running (i.e.,”suspended”). If you don’t want to get charged for a Service, you need to delete the deployments associated with the Service.