This topic provides answers to some frequently asked questions about the billing of Classic Load Balancer (CLB).
Am I charged a specification fee for internal-facing CLB instances?
Why are the monitoring statistics of CLB different from the statistics on the bills of CLB?
Why is the actual amount of HTTPS traffic higher than the amount of traffic on my bills?
Do upgrades or specification changes cause service interruptions?
How are CLB instances billed?
CLB instances support the pay-as-you-go billing method. For more information, see Pa-as-you-go.
Adjustments are made to the billable items of CLB. Beginning 00:00:00 (UTC+8), December 1, 2024, the following new billable items are used by pay-as-you-go CLB instances:
Instance fee is renamed public IP retention fee.
A billable item instance fee is added.
For more information, see CLB billing adjustments.
Am I charged for inbound traffic on CLB instances?
No, you are charged only for outbound traffic on CLB instances. For more information about traffic on CLB instances, see Network traffic flow.
Am I charged for traffic generated by health checks?
No, you are not charged for traffic generated by health checks on CLB instances.
Do the billing rules for a CLB instance change after Elastic Compute Service (ECS) instances are added as backend servers to the CLB instance?
No, the billing rules for the CLB instance do not change no matter what billing method the ECS instances added to the CLB instance use. CLB and ECS instances are separately billed.
Am I charged for traffic generated due to network attacks?
CLB is interfaced with Alibaba Cloud Security to protect your workloads. When an attack is detected, traffic scrubbing or blackhole filtering provided by Alibaba Cloud Security is triggered after a delay of a few seconds. If your CLB instance responds to malicious traffic during the delay, fees are charged for the responses. In addition, network attacks consume the bandwidth resources of CLB.
If all backend ECS instances of a CLB instance are stopped or removed, am I still charged Internet data transfer fees?
CLB charges instance fees and specification fees. Take note of the following information about Internet data transfer fees:
Pay-by-data-transfer
For a pay-by-data-transfer CLB instance, no traffic fee is incurred when the CLB instance is stopped, released, or idle.
CLB is a traffic distribution and control service that distributes network traffic to backend ECS instances and provides services based on the CLB service address. If all backend ECS instances of a CLB instance are stopped, but the CLB instance remains running, requests can still reach the service address of the CLB instance. If health checks detect that no backend ECS instances are available, the CLB instance responds to the requests based on the health check result.
Layer 4 CLB instances returns only three-way handshake packets. Layer 7 CLB instances return a Tengine 503 error page because Layer 7 load balancing is provided by Tengine. If requests keep reaching the CLB instance, the CLB instance keeps responding to the incoming requests. You are charged for the traffic generated by the responses.
This also applies to CLB instances that have no ECS instances attached. To avoid unexpected data transfer fees for CLB, we recommend that you stop or release CLB instances that you no longer use.
Pay-by-bandwidth
For pay-by-bandwidth CLB instances, fees are irrelevant to the instance status or data transfer. You are charged based on the specified bandwidth from when a pay-by-bandwidth CLB instance is created to when it is released.
Am I still charged after a CLB instance is stopped?
Yes, you are charged for stopped CLB instances. The billing of a CLB instance stops only when the CLB instance is released.
After a CLB instance is stopped, you may be charged an instance fee, a specification fee, and a bandwidth fee.
Instance fee: The billing of a CLB instance continues if the CLB instance is stopped but not released.
Specification fee: The specification of a CLB instance determines the resources allocated to the CLB instance. The resources for a stopped CLB instance are retained in case the CLB instance needs to be enabled again. If the CLB instance is billed on a pay-by-specification basis, you are charged a specification fee even if the CLB instance is stopped.
Bandwidth fee: The bandwidth fee of a CLB instance is irrelevant to the instance status or data transfer. You are charged based on the maximum bandwidth specified for the CLB instance. The billing of the bandwidth resources stops only when the CLB instance is released.
After a CLB instance is stopped, you are no longer charged a data transfer fee or an LCU fee.
Data transfer fee: After a pay-by-data-transfer CLB instance is stopped, the CLB instance no longer forwards network traffic. Therefore, you are not charged a data transfer fee for the CLB instance.
LCU fee: After a pay-by-LCU CLB instance is stopped, the CLB instance no longer consumes LCUs. Therefore, you are not charged an LCU fee for the CLB instance.
Am I charged a specification fee for internal-facing CLB instances?
If your internal-facing CLB instance is a shared-resource instance (unavailable for purchase), you are not charged a specification fee.
If the internal-facing CLB instance is a high-performance CLB instance, you are charged a specification fee.
The specification fee for an internal-facing CLB instance is calculated in the same way as the specification fee for an Internet-facing CLB instance. You are not charged instance fees or Internet data transfer fees for using internal-facing CLB instances.
Am I charged specification fees for using shared-resource CLB instances? What are the differences between the billable items of shared-resource CLB instances and high-performance CLB instances?
No,
you are not charged specification fees if you do not change existing shared-resource CLB instances to high-performance CLB instances. However, if you change existing shared-resource CLB instances to high-performance CLB instances, you are charged specification fees.
The billable items vary based on the instance type and the billing method of Internet data transfer.
Network type | Metering method for Internet data transfer | Instance type | Instance fee | Data transfer fee | Bandwidth fee | Specification fee |
Internet-facing | Pay-by-data-transfer | Shared-resource | ✔ | ✔ | - | - |
High-performance | ✔ | ✔ | - | ✔ | ||
Pay-by-bandwidth | Shared-resource | ✔ | - | ✔ | - | |
High-performance | ✔ | - | ✔ | ✔ | ||
Internal-facing | - | Shared-resource | - | - | - | - |
High-performance | - | - | - | ✔ |
In the preceding table, "-" indicates that you are charged the fee and "✔" indicates that you are not charged the fee.
Why are the monitoring statistics of CLB different from the statistics on the bills of CLB?
Take traffic statistics as an example. The traffic statistics displayed in the CLB console are average values. CLB collects statistics every minute and reports the statistics to CloudMonitor, which then calculates the average value of each period of 15 minutes. However, the statistics on your CLB bills are accumulated values. CLB collects statistics every minute, sums the statistics every hour, and then reports the accumulated values to the billing system.
The values reported to the billing system are the sum of the values that are collected every minute. The values displayed in the monitoring system are the sum of the average values that are collected every 15 minutes. Therefore, the statistics in the monitoring system are not equal to the statistics in the billing system because the statistics are generated based on different time intervals.
CLB makes the best efforts to provide real-time data. However, the timeliness of data is difficult to guarantee throughout the entire data processing pipeline. In this pipeline, CLB collects statistics and reports the statistics to CloudMonitor. Then, CloudMonitor calculates the average values and displays the results on dashboards. Even if the delay is short, it may cause discrepancies between the statistics in the monitoring and billing systems. The billing system can tolerate a delay of at most 3 hours. For example, the billing data generated from 01:00 to 02:00 is expected to be reported to the billing system before 03:00. With a tolerance to the maximum delay, the billing data can be reported to the billing system at 05:00. The discrepancy between the timeliness of the monitoring and billing systems causes the discrepancy between the monitoring statistics and billing statistics.
Monitoring data and billing data are used for different purposes. The purpose of monitoring data is to help you observe whether instances run as expected. If the instances do not run as expected, you can troubleshoot the issues at the earliest opportunity. The purpose of billing data is to generate bills based on the actual usage of resources within your account. Therefore, the statistics on bills shall prevail when you compare the statistics in the monitoring and billing systems for accounting purposes.
Why is the actual amount of HTTPS traffic higher than the amount of traffic on my bills?
A certain amount of traffic is generated due to TLS or SSL handshakes for establishing HTTPS connections. Therefore, the actual amount of HTTPS traffic is higher than the amount of traffic on your bills.
Do upgrades or specification changes cause service interruptions?
No, upgrades do not cause service interruptions. However, changes to the metering method of data transfer take effect at 00:00:00 on the next day. Specification changes cannot be made before the current specifications take effect.
If I change the metering method of an existing CLB instance from pay-by-specification to pay-by-LCU, are my services affected?
If your CLB instance is of the Super Large I specification or below, changing the metering method does not affect your services.
If your CLB instance is of a specification higher than Super Large I, changing the metering method may degrade the instance performance. Proceed with caution.
NoteBy default, CLB does not provide specifications higher than Super Large I. If you require more concurrent connections at Layer 4, use Network Load Balancer (NLB). If you require more queries per second at Layer 7, use Application Load Balancer (ALB).
For more information about NLB, see What is NLB?
For more information about ALB, see What is ALB?
Pay-by-LCU CLB instances are also subject to performance limits. For more information, see Change the metering method of a CLB instance from pay-by-specification to pay-by-LCU.