# Billing of Table Store

Last Updated: Jan 16, 2019

Table Store is a Pay-As-You-Go service, which means it charges fees based on the actual usage of each resource within a billing cycle. You do not need to buy an additional volume for instances.

Currently, Table Store bills an instance in the following four dimensions:

• Stored data volume

• Downstream Internet traffic

Table Store bills an instance based on the actual usage of resources in a billing cycle (per hour).

## How is Table Store billing calculated per hour?

### Scenario

In a billing cycle, assume that the data volume and Internet downstream traffic are 50 GB and 10 GB, respectively. At the 20th minute within the one hour, the reserved read/write throughput of all tables under the instance is adjusted from (1000,1500) to (1200,800). 50,000 volume-based read CUs and 10,000 volume-based write CUs are consumed.

#### Billing formula

The instance of this hour is billed using the following formulas:

• Storage fee: 50 GB * Unit price per hour per GB

• Traffic fee: 10 GB * Unit price of the Internet downstream traffic

• Reserved CU fee:

• Average reserved read CUs of this hour: (1000*20 + 1200*40)/60 = 1133.3

• Average reserved write CUs of this hour: (1500*20 + 800*40)/60 = 1033

• Fee of this hour: 1133.3 * Unit price of the read CUs per hour + 1033.3 * Unit price of the write CUs per hour

• Fee of the volume-based CUs: 50,000/10,000 * Unit price of the volume-based read CUs per 10,000 + 10,000/10,000 * Unit price of the volume-based write CUs per 10,000

The total amount is the sum of the preceding fees.

The stored data volume and reserved read/write throughput are precise to the minute. At the end of a billing cycle, the average values of the stored data volume and reserved read/write throughput are calculated as the actual usage of the resource in the billing cycle. The volume-based read/write throughput is precise to the second. The volume-based CU used per second in the billing cycle is collected, and all values are aggregated.

Assume that 1000 read CUs are reserved in the first 20 minutes. If 2100 read CUs are consumed in one second, the volume-based read throughput at this second is 1100 (2100–1000). For more information about the metered items of Table Store, see Pricing.

## How is Table Store billing calculated per day?

### Scenario 1

The preceding figure shows access per day of an app. In this example, assume that the read and write volumes of the app are the same. To make sure that the app contains enough resources to provide read/write services during peak hour, you must buy resources based on the traffic volume in the peak hour. To convert the volume to the CUs of Table Store, you must buy 200 reserved read/write CUs.

#### Billing formula

Fee per day = 200 * Unit price of the reserved read CUs per hour * 24 + 200 * Unit price of the reserved write CUs per hour * 24 + data storage fee per day + Internet downstream traffic fee per day

Table Store provides APIs that enable you to adjust the reserved read/write throughput of each table at any time. An adjusted throughput takes effect within one minute. However, you must make sure that the reserved throughput adjustment does not affect the services.

As a result, you can increase the number of reserved CUs during peak hours to meet service growth, and reduce the number of reserved CUs during non-peak hours to save costs.

### Scenario 2

In one 24 hour cycle:

• 00:00–05:00: Set the read/write throughput to 30 CUs. During the five hours, the read and write operations each consume 100,000 CUs more than the reserved throughput.

• 05:00–10:00: The access traffic of the service is reduced. The number of read/write CUs is adjusted to 20. During the five hours, the read and write operations each consume 5000 CUs more than the reserved throughput.

• 10:00–12:00: The access traffic of the service increases. The number of read/write CUs is adjusted to 45. During the two hours, the read and write operations each consume 10,000 CUs more than the reserved throughput.

• 12:00–18:00: The service peak is met. The number of read/write CUs is increased to 180. During the six hours, the read and write operations each consume 30,000 CUs more than the reserved throughput.

• 18:00–24:00: The access peak lowers. The number of read/write CUs is reduced to 20. During the six hours, the read and write operations each consume 50,000 CUs more than the reserved throughput.

#### Billing formula

In this example, assume that the ratio of the read and write operations is 1:1, and the reserved read and write CUs are adjusted to the same values. The fees of the CUs per day are calculated as follows:

(30 * 5 hours + 20 * 5 hours + 45 * 2 hours + 180 * 6 hours + 20 * 6 hours) * Unit price of the reserved read CUs per hour + (100,000 + 5000+ 10,000 + 30,000 + 50,000) * Unit price of the volume-based read CUs

That is, 1540 * Unit price of the reserved read CUs per hour + 195000 * Unit price of the volume-based read CUs

• Write CU fee:

(30 * 5 hours + 20 * 5 hours + 45 * 2 hours + 180 * 6 hours + 20 * 6 hours) * Unit price of the reserved write CUs per hour + (100,000 + 5000+ 10,000 + 30,000 + 50,000) * Unit price of the volume-based write CUs

That is, 1540 * Unit price of the reserved write CUs per hour + 195000 * Unit price of the volume-based write CUs

Compared with the billing method in Scenario 1, scenario 2 can save the following cost:

4800 * Unit price of the reserved read CUs per hour + 4800 * Unit price of the reserved write CUs per hour - 1540 * Unit price of the reserved read CUs per hour - 19.5 * Unit price of the volume-based read CUs - 1540 * Unit price of the reserved write CUs per hour - 19.5 * Unit price of the volume-based write CUs

## NOTES

• The preceding calculation result does not include the free quota that each registered account is allocated.

• The unit price of the volume-based read/write throughput is slightly higher than that of the reserved throughput. We recommend that you properly adjust the reserved values based on your service conditions to effectively reduce the cost.

• You can use the SDK to set the reserved read/write throughput of a table to a lower value, so that you can preferentially use your free quota resources.