Explanation of Billing for Azure Core Services

VM Billing

With the Azure Management Platform, in just a few minutes, you can create one VM or as many as a thousand VM instances based on your needs.

Azure supports a variety of conventional VMs with support for Linux, Windows, SQL Server, Oracle and SAP, providing customers with the flexibility of multiple types of virtualization and enabling the implementation of a variety of compute solutions. You can use Azure VMs to deploy Windows Server, Linux, or third-party software images to Azure, as well as choosing existing images in the library or using your own custom images.

A key feature of Azure VM billing is charging per minute, with prices given as hourly rates. If the VM runs for less than 1 hour, you will be billed by the total number of minutes. If the VM runs for less than 1 minute, you will not be charged.

When you start calculating the cost of using Azure VMs, in addition to the billing units, you need to consider the following factors:


Azure’s resources in China are divided into four data centers located in Beijing and Shanghai. You can choose the corresponding location when you deploy the VM. In June 2018, we officially opened two new data centers in North China and East China, so that you can enjoy plentiful service resources when you are deploying services.

High availability

In order to ensure that deployment is consistent with the VM Service Level Agreement (SLA), you must deploy two or more VMs running loads in the availability set. We strongly recommend that you use availability sets with high availability, to ensure that VMs are distributed in multiple fault domains within our data centers, as well as being deployed to hosts during different maintenance periods. The Azure Single Instance Virtual Machine SLA has availability of up to 99.9% (on condition that all disks are deployed to the VM using premium storage).


The SLA does not cover previews of the latest services or single instance VMs that do not use premium storage. We recommend that you deploy VMs in high availability sets, as they provide better safeguards for the operation of your VMs.


Online Service Premier Agreement (OSPA) Enterprise Customers

Each Azure subscription has default quotas for creating services. It is important to find out about your default quotas, which depend on the purchase channel you used and the subscription attributes (Trial subscription, Standard Pay-in-advance (PIA) subscription, or Enterprise Pay-in-advance account subscriptions). If you need more than the default quota, please contact the support team for help.

If you purchased your subscription by signing an Enterprise Premier Service Agreement offline, each subscription under that account can be used to create VMs with up to 100 cores.

Standard Pay-in-advance (PIA) customers

If you have a Standard Pay-in-advance (PIA) subscription, each subscription under that account can be used to create VMs with up to 20 cores.

Launching and shutting down a VM

If you want to shut down a VM so it no long incurs charges, please note that the VM instance must be in “stopped” (deallocated) state. If the VM is in this state, you will not be charged. If your instance is in “stopped” state, the allocated VM cores will be billed because they still occupy compute resources, but you will not be billed for the software licenses. You can refer to the points below to check the state of your VM and see if it is still incurring charges:

  • Starting. The VM is initializing, and will incur charges during this period;
  • Running (started). The VM is running, and will incur charges during this period;
  • Stopped. The VM has stopped (but has not been deallocated), so there are no software fees, but the cores will still incur charges;
  • Stopped (deallocated). There are no charges (excluding storage fees, which will still be charged);
  • Deleted. The VM has been deleted and occupies no cores. In order to prevent users from accidentally deleting data, we will continue to charge for storage. If the disk is deleted, there will be no further storage charges.

VM Service Level Agreement (SLA):https://www.azure.cn/zh-cn/support/sla/virtual-machines/


Q1: Is there a charge for temporary disks for VMs?

A: There is no charge for storage on temporary disks on VMs, but the data on the temporary disk will be lost when the VM is shut down or restarted, and you are not be protected by an SLA. Azure provides a range of types and data disks. We recommend that you choose persistent storage, so that you have access to the best management functions, availability and security.

Q2: How much will I be charged if my VM has been running for 1 minute 45 seconds?

A: We charge per whole minute for VMs, so you don’t need to pay anything for the additional seconds. In this example, you will be billed for 1 minute of usage. If you use the VM for 59 seconds, we will not charge you.

Q3: If I want to use SQL Server, do I need to purchase a separate Windows VM?

A: No. The prices on our website are the total prices for a Windows VM with SQL Server.

Q4: If I want to deploy the SQL Server for Windows, SQL Server for Ubuntu Linux, or Machine Learning Server VMs, how will you bill me?

A: You will be billed in two parts: VM fees + fees for all the servers you deploy.

Q5: What is the difference between D-series VMs and DS-series VMs?

A: The unit price for the VMs is the same, but there are significant difference in performance. If you need to use Premium Storage, please use a variable DS-series VM and purchase Premium Storage separately.

Q6: How do I check that the VM has been stopped correctly and I will no longer be billed for it?

A: If the status says “Stopped (deallocated)”, then you will no longer be billed for it. To stop a VM, sign in to Azure portal. As the storage and RIP associated with the VM continue to occupy resources after the VM has been stopped, unless you delete the VM, you will continue to be charged for storage and RIP.

Q7: If I have instances in two different regions, how will I be charged for data transfer fees?

A: You will be charged for cross-regional data transfers in and out of each instance.

Q8: I am an enterprise customer who has purchased through CPP (Compute Pre-Purchase). How many hours of usage are included in the monthly CPP package with 1 VM? If I don’t use up this time in the current month, can it be rolled over to the next month?

A: A monthly CPP package for a single VM includes 744 hours of usage. This figure resets to zero at the end of the month and cannot be rolled over to the next month, even if you do not use up the full amount. See here for further details. If you are purchasing VMs using CPP, please note that you need to select the correct model and region. Please contact your Microsoft client manager for further information.


CPP is currently only available to enterprise customers who have signed an Online Service Premier Agreement (OSPA), and is a VM package service provided on a monthly or annual basis. This service is not currently available to Standard Pay-in-advance (PIA) customers.

Storage Billing

Storage is a basic function of VMs. We will provide detailed explanations about storage billing a little later, but first we would like to tell you about the basic storage functions that you need to know about when using VMs, so that you understand in detail how we bill you for VM storage.

  • Azure VM disks include a temporary disk, which is located on the D: drive (Windows) or /dev/sdb1 (Linux). As they are only intended to provide temporary storage, you may be at risk of losing data, and such data may be unrecoverable. If you need to migrate a VM, change the size of a VM, or restart a VM, the temporary disk will disappear. While you will not be billed for temporary disks, we strongly recommend that you do not store important information on temporary disks, in order to avoid losing your data. If data on a temporary disk is lost, you will not be protected by the SLA.
  • Azure VMs now support Azure Managed Disks, so you can create a virtual machine without the need to create or manage any Azure storage accounts. You simply need to specify whether you need premium or standard storage, and Azure will then create managed disks. VMs that use Managed Disks have many important functions, including: 1) support for automatic scaling, with availability sets providing greater reliability, while Azure ensures that managed disks are automatically isolated within the availability set; and 2) enhanced access control. Managed Disks launches a variety of operations controlled by Azure’s role-based access control (RBAC).
  • Hot storage and cool storage. Azure’s hot storage is optimized for storing frequently-accessed data. Hot storage is also the default storage type for Blob Storage. Cool storage is optimized for storing data that requires long-term storage. In general, cool storage is the best place to store data that is only rarely accessed. For this reason, you should select the most appropriate type of storage for the data you need to store, in order to minimize costs.
  • Redundancy. Redundancy involves replicating data in Azure storage accounts to ensure that it is persistent and highly available, so that the requirements of the SLA can be met, even if a sudden hardware failure occurs. When you create a storage account, you can choose from the following replication options: locally redundant storage (LRS), zone-redundant storage (ZRS) geo-redundant storage (GRS), and read access geo-redundant storage (RA-GRS). We will explain more about billing details in the section on storage.

The Basics of Storage Billing

Azure Storage is a type of cloud storage with high persistency, high availability, and high scalability, allowing you to access data anywhere at any time. There are five types of cloud storage: Block Blob, Page Blob, disk, file, tablet and queue.

Azure Storage space is charged based on storage capacity, storage transaction numbers (the number of read and write operations performed on the storage), and the amount of data transferred. Storage fees are made up of these three key elements:

  1. Bandwidth - the amount of data transferred at the location of the storage account.
  2. Transactions - the number of requests executed on your storage account.
  3. Total capacity - the total amount of data in persistent storage.

Of course, we may make changes to billing for these three key elements if we add more functions to storage. Below is an overview of billing for three areas:

  1. Bandwidth - we can place the managed services in the same location as the corresponding storage. This provides free bandwidth between compute services and storage services in the same location. You just need to pay for bandwidth arising from access to storage services outside the current location.
  2. Transactions - each Blob, table and queue REST request generated for a storage service will be regarded as a billable transaction. It is therefore important to understand the frequency and quantity of requests, in order to keep transaction costs under control. We analyze every request received, and then determine whether to charge for the request based on how it is processed and the source of the request.
  3. Total capacity - in order to work out the billable storage capacity, we calculate the total capacity of the stored objects (Blobs, entities and messages) and the relevant apps and system metadata.

Pricing and billing for cool storage and hot storage.

Blob Storage customers can now choose hot or cool storage tiers as the account tier based on their access mode, or can select hot, cool, or archive tiers as the Blob tier.

  • Store cool data that is less frequently accessed at storage fees lower than those for hot data. Good examples include short-term backups and disaster recovery datasets; older content that you no longer regularly view, but still need to be immediately available when you access it.
  • Store more frequently accessed hot data at the lowest access fees. Examples include data that is in active use, or that you expect to access (read and write) frequently.

If you use a Blob Storage Account, please pay attention to the following billing methods:

  • Storage costs: the cost of storing data depends not only on the amount of data, but also on the storage tier. The cool storage tier costs less per GB of storage than the hot storage tier.
  • Data access fees: you have to pay read and write access fees per GB of data in cool storage.
  • Transaction costs: transaction fees are charged for both tiers. However, the cost per transaction for the cool tier is a little higher than for the hot tier.
  • Geo-replication data transfer costs: only applicable to accounts configured with geo-replication, including GRS and RA-GRS. Geo-replication generates a cost per GB of data transferred.
  • Outbound data transfer costs: outbound data transfers (data transferred out of the Azure region) are charged for the bandwidth usage generated by each GB of data, in the same way as ordinary storage accounts.
  • Changing storage tier: there is a charge for changing the storage tier from cool to hot. The fee for each change is equivalent to the cost of reading all the data in the storage account. There is no charge for changing the storage tier from hot to cold.

Storage Service Level Agreement (SLA):https://www.azure.cn/zh-cn/support/sla/storage/

Storage Fee FAQs

Q1: If I only use storage services for a few days each month, can I pay on a pro rata basis?

A: Yes. Storage capacity is charged on the basis of the average amount of data stored per day over the month (in GB). For example, if you use 2 GB on May 1, 4 GB on May 2, and 5 GB on May 3, your storage fees for these three days will be calculated using this formula: (2/31+4/31+5/31) × Storage Unit Price.

Q2: Is the price shown for Managed Disks a monthly price? If I use Managed Disks for less than one month, how will I be charged?

A: You will be charged a monthly price calculated on the basis of the number of hours and the proportion.

Q3: How do the pricing models differ for Managed Disks and unmanaged disks?

A: Unmanaged disk storage (Block Blob, Page Blob, files, queues and tables) are charged a monthly fee based on the amount of data stored (in GB). The total cost of Standard/Premium Managed Disk storage depends on the size and number of disks, the number of transactions, and the amount of outbound data transfers. Regardless of how much disk you use, you will be charged the same rate for the disks you configured.

Data transfer fees

When you create an Azure VM, you must create a virtual network (VNet) or use an existing VNet. There is no charge for setting up a VNet. However, we will charge you for the VPN Gateway that connects your local VNet to other VNets in Azure. If you are using VNets in different regions, please pay attention to the following points:

  • Inbound inter-VNet data transfers Inbound data transfers between two VNets in the same region are free.
  • However, we do charge for inbound data transfers between VNets in different regions (China East Data Center, China North Data Center).
  • Outbound inter-VNet data transfers Outbound data transfers between two VNets in the same region are free.
  • However, we do charge for outbound data transfers between VNets in different regions (China East Data Center, China North Data Center).
  • Outbound P2S (point-to-site) VPN data transfers Data transfers out of Azure VNets via P2S (point-to-site) are charged at standard data transfer rates.

How are transactions counted?

To understand transaction numbers, it is important to understand what constitutes a transaction in the context of Windows Azure Storage. Every REST call performed for a Windows Azure Blob, tablet or queue is regarded as one transaction. However, whether that transaction is billable depends on the billing type, as discussed earlier. Every operation resulting from any of the REST calls referred to above is counted as one transaction.

Here are a few examples:

  • 1 GetBlob request performed for the Blob service = 1 transaction
  • 1 PutBlob request performed for the Blob service = 1 transaction
  • Uploading a large amount to Blobs, generating 100 requests via PutBlock, and lastly using one PutBlockList to submit = 101 transactions
  • Using a total of 5 requests (because there are 4 continuation tokens ) to list a large amount of Blob content = 5 transactions
  • Table-entity AddObject request = 1 transaction
  • Performing table Save Changes (without using SaveChangesOptions.Batch) for 100 objects = 100 transactions
  • Performing table Save Changes (using SaveChangesOptions.Batch) for 100 objects = 1 transaction
  • A table query specifying exact matches for PartitionKey and RowKey (returning 1 entity) = 1 transaction
  • A table query performing one storage request, and returning 500 entities (without encountering continuation tokens) = 1 transaction
  • A table query generating 5 storage requests for table storage (as there are 4 continuation tokens) = 5 transactions
  • Queue storage message = 1 transaction
  • A queue getting 1 message = 1 transaction
  • A queue getting a message via an empty queue = 1 transaction
  • A queue getting 32 messages using batch processing = 1 transaction
  • A queue deleting a message = 1 transaction

If a transaction received by our services falls into any of the categories below, we will not regard it as a billable transaction, and these transactions do not generate bandwidth fees:

  • Authentication failed
  • Quota permissions failed
  • The HTTP action involves a Shared Access Signature (SAS) error
  • Anonymous request failed
  • Unexpected timeout

If you encounter any of the situations described above, the corresponding transaction will not be regarded as a billable transaction, and the request will not generate bandwidth fees.

Other key services


Every cloud service that involves one or more Azure VMs is automatically allocated a free dynamic virtual IP (VIP) address. For an additional charge, you can also get:

  • Instance-level public IP address: dynamic public IP (PIP) address, allocated to the VM for use in direct access.
  • Reserved IP address: we can reserve a public IP address for you subscription, and this address can be used as the VIP address for any cloud service within the region.
  • Load-balanced IP address: other load-balanced VIP addresses can be allocated to cloud services involving one or more Azure VMs.


If you want to back up an Azure VM that generates load balancing, please use Azure Backup. Azure Backup supports application-consistent backups for both Windows and Linux VMs. Azure Backup can create restore points that are stored in a geo-redundant Recovery Vault. When you restore from the restore point, you can restore the entire VM, or only restore specific files. The backup service charges you based on the size of every protected instance, in increments of 500 GB. There are also separate charges for Azure Storage space, so you can reduce long-term storage costs. You can choose from flexible storage options including LRS, GRS, or Block storage.

Protected instances are a billable unit used in Azure backups, and software fees will be charged based on the size of the protected computer. For this reason, the larger a protected instance is, the higher the cost to the customer.

Backup Service Level Agreement (SLA):https://www.azure.cn/zh-cn/support/sla/backup/


If the entire region suffers from disruption as a result of a major natural disaster or large-scale service disruption, Azure Site Recovery protects your VM from the effects of the major disaster. You can configure Azure Site Recovery for the VM, so that you can recover your applications in a few minutes with just one click. You can replicate it to all the selected Azure regions (it is not limited to the associated region).

Azure Site Recovery charges you for the number of protected instances. There are also separate charges for storage, storage transactions, and data transfers. Azure Site Recovery charges you based on the average daily number of protected instances each month. For example, if you continuously protect 20 instances for the first two weeks of a month, but you do not protect any instances for the last two weeks of the month, the average daily number of protected instances for that month will be 10.

Site Recovery Service Level Agreement (SLA):https://www.azure.cn/zh-cn/support/sla/site-recovery/

SQL Databases

A type of relational database provided as a service, making it easy to obtain the following benefits:

  • The ability to scale up to thousands of databases
  • Scale freely with predictable performance
  • Availability guarantees provided by copies and runtime SLAs
  • Protect your data using recovery and geo-replication
  • Pseudo-programmable DBA functions enable efficient development and operations
  • Can be self-managed, requires virtually no manual maintenance

SQL Database Service Level Agreement (SLA): https://www.azure.cn/zh-cn/support/sla/sql-data/

Azure Database for MySQL

Azure Database for MySQL provides fully managed, enterprise-ready community MySQL database as a service (DBaaS).

The MySQL Community edition helps you easily lift and shift to the cloud, using languages and frameworks of your choice. On top of that, you get built-in high availability and dynamic scaling, helping you easily adjust to changes in customer demands. Additionally, you benefit from the unparalleled security and compliance, including Azure IP advantage, as well as Azure’s industry-leading reach. All of this comes with a flexible pricing model so you can choose resources for your workload with no hidden cost.

Azure Database for MySQL Service Level Agreement (SLA): https://www.azure.cn/zh-cn/support/sla/mysql/