Azureのアカウントと請求の関係性（Windows azure billing overview）が公開されているので紹介します。
以下、上記URLから本文を引用して紹介します。
There have been a lot of questions regarding Windows Azure Platform billing and how it works. This diagram shows the relationship between components. The current diagram shows the current configuration. This configuration may change in the future:
Notes:
· The green components are the ones that you can upgrade.
· The 20 small computes instances could be any combination of VM sizes so long as the total number of cores across all slots and services within the project does not exceed 20.
Billing and Subscriptions
The Microsoft Online Customer Service Portal (MOCP) limits one Account Owner Windows Live ID (WLID) per MOCP account. These are the accounts descriptions:
Account Administrator (Account Owner WLID). The Account Owner can create and manage subscription, view billing and usage data and specify the Service Administrator for each subscription. Large companies may need to create multiple accounts in order to design an effective account structure that supports/reflects their go-to-market strategy. The account Administrator cannot create services.
Service Administrator (Service Admin. WLID): Manages Services and deployments.
Note: The WLID for the Account owner and Service Administrator are not necessarily the same WLID. Refer to the Subscriptions explanation below.
Subscriptions (MOCP)
For each MOCP account, the Account Owner can create one or more subscriptions. For each subscription, the Account Owner can specify a different WLID as the Service Administrator. This WLID can be the same or different as the Account Owner. The Service Administrator is the user that actually uses the Windows Azure platform. Only the Account Owner can reassign a subscription’s Service Administrator.
These are the commercial subscriptions currently available through MOCP:
· Azure offers Link: http://www.microsoft.com/windowsazure/offers/
· Compare Azure Subscriptions link: http://www.microsoft.com/windowsazure/offers/popup.aspx?lang=en&locale=en-US&offer=COMPARE_PUBLIC
The creation of a subscription in the Microsoft Online Customer Service Portal (MOCP) portal results in a Project in the Windows Azure portal.
Project (on the Azure Portal)
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 account will have 20 Small Compute Instances that you can utilize. If you need to increase the number, just have to contact Microsoft Online Services customer support. There they will verify the billing account and provide the requested Small Compute Instances / cores, subject to a possible credit check. In addition, you can 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 storage accounts than 20, you will need to order another subscription.
Services
You can have a total of 20 Services per project. The services are space where applications are deployed. 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 is 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
On this example the service has 2 roles, each role with a specific workers 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
Notes about Services: 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.
