Server Load Balancer:CLB Billing FAQ

How are guaranteed-performance instances billed?

Are shared-resource instances charged extra specification fees? What are the differences in billable items between shared-resource and guaranteed-performance instances?

No.

No specification fee is charged for a shared-resource instance unless you change it to a guaranteed-performance instance. If you change a shared-resource instance to a guaranteed-performance instance, a specification fee is charged.

Are private-network CLB instances also charged specification fees?

• No specification fee is charged for a shared-performance private-network instance (discontinued).

• A specification fee is charged for a guaranteed-performance private-network instance.

  The billing rules for the specification fee are the same as those for a public network instance. For more information about billing, see Billing methods for instances.

How can I estimate LCU usage and fees?

Does adding ECS instances to the backend server pool of a CLB instance affect CLB billing?

No. Regardless of the billing method used for the ECS instances added to the backend of a CLB instance, the billing rules for the CLB instance do not change due to this association. This is because CLB and ECS are billed and settled separately based on your usage.

Am I still charged after a CLB instance is stopped?

Yes, a Cloud Load Balancer (CLB) instance stops being billed only after it is released.

how long does it take for the service to be restored after top-up?

• For a pay-as-you-go instance that is suspended due to an overdue payment, the service resumes immediately after you top up your account and clear the overdue payment.

• If the service does not resume for a long time, check your account status to confirm whether the payment was successful, or submit a ticket to contact technical support.

Is inbound traffic to CLB billed?

CLB currently charges only for outbound traffic. Inbound traffic is not billed. For more information about CLB network traffic paths, see Inbound traffic path and Outbound traffic path.

Does Internal CLB incur data transfer fees?

No, private-network CLB instances do not incur data transfer fees.

• The billable items for a private-network CLB instance include only the instance fee and LCU fee (or specification fee). They do not include public IP address retention fees, data transfer fees, or bandwidth fees.

• If you bind a separately purchased EIP to the CLB instance, the EIP incurs public network data transfer fees. These fees are billed to the EIP and are not reflected in the CLB bill.

Is traffic generated by health checks billed?

No, it is not. The traffic generated by CLB health checks is not included in the data transfer fees for the instance.

Is attack traffic billed?

CLB works with Alibaba Cloud Security to provide protection. A delay of a few seconds occurs between the time an attack starts and reaches the traffic scrubbing or blackhole triggering threshold and the time Alibaba Cloud Security starts traffic scrubbing or blackholing. Therefore, responses to attack packets during this period incur fees. Such attacks also consume the bandwidth resources of CLB.

Why is the actual traffic for HTTPS more than the billed traffic?

The HTTPS protocol uses some traffic for protocol handshakes. Therefore, the actual traffic generated is more than the billed traffic.

If all backend ECS instances of a CLB instance are stopped or no ECS instances are attached, are public network fees still charged?

CLB public IP address retention fees, instance fees, and specification fees are still charged. The billing for public network fees is as follows:

• Pay-by-data-transfer

  For a pay-by-data-transfer instance, data transfer fees are not incurred only when the CLB instance is stopped, released, or has no access requests.

  CLB is a load balancing service that is placed in front of ECS instances and provides services through an endpoint. If all backend ECS instances of a CLB instance are stopped but the CLB instance itself is not stopped, traffic still reaches the CLB endpoint when a request is made. The CLB health check then determines that no backend ECS instances are available and sends a response.

  For Layer 4 load balancing, only three-way handshake packets are sent in response. For Layer 7 load balancing, because the service is provided by Tengine, the response is a Tengine 503 error page. If access requests continue to arrive and the load balancer continues to respond, this response traffic is billed.

  This also applies to CLB instances that are not attached to any ECS instances. Therefore, to avoid data transfer fees for CLB instances, we recommend that you stop or release CLB instances that you no longer use.

• Pay-by-bandwidth

  For a pay-by-bandwidth instance, fees are not related to the instance status or traffic usage. As long as the service is enabled, you are billed for the fixed bandwidth. Billing stops only after the instance is released.

Which CLB traffic can be offset by Data Transfer Plans?

• IPv4 traffic generated by the public IP address allocated to a public-network CLB instance that uses the pay-by-data-transfer billing method.

• IPv4 traffic (excluding premium EIP traffic) generated by a pay-by-data-transfer EIP that is bound to a private-network CLB instance in a VPC.

For more information, see Data Transfer Plan.

If I change an existing pay-by-specification instance to pay-by-LCU, will my services be affected?

• If your instance specification is super large I or lower, changing the instance configuration does not affect your services.

• If your instance type is Super Large I or higher, switching from specification-based billing to usage-based billing may degrade instance performance. Proceed with caution.

  Note

  • By default, CLB specifications higher than super large I are not available. For Layer 4 load balancing, if you require more concurrent connections, select a Network Load Balancer (NLB) product. For Layer 7 load balancing, if you require a higher number of queries per second (QPS), select an Application Load Balancer (ALB) product.

    • For more information about NLB, see What is NLB?.

    • For more information about ALB, see What is ALB?.

  • Starting from 00:00:00 (UTC+8) on June 1, 2025, new purchases of pay-by-specification CLB instances are discontinued, and you cannot change from pay-by-LCU to pay-by-specification. For more information, see Discontinuation Notice for Pay-by-Specification Classic Load Balancer (CLB) Instances.

  Pay-by-LCU instances also have performance limits. For more information about performance limits, see Change from pay-by-specification to pay-by-LCU.

Does the upgrade or specification change process affect services?

An Upgrade/Downgrade operation does not affect your business. However, if the operation involves a change to the or traffic, the change takes effect at 00:00:00 the next day. You cannot perform other Upgrade/Downgrade operations until the change is complete.

How do I view the traffic usage of CLB?

• View real-time traffic in CloudMonitor: Log on to the CloudMonitor console, locate the target instance, and view the traffic monitoring data.

• View billed traffic from your bill: Log on to the Expenses and Costs console, filter for the target instance, and view the usage details.

Discrepancies may exist between monitoring data and bill data. This is normal and is caused by different statistical methods and reporting times. Your bill is calculated based on the bill data.

Why is the monitoring data for CLB different from the actual bill data?

• The instance traffic data displayed in the CLB console is collected by the CLB system at a 1-minute granularity and reported to the CloudMonitor system. The bill metering data for a CLB instance is collected at the same frequency. After a billing cycle, the data is reported to the billing system as an hourly accumulated value for settlement.

  Bill data is the accumulated value per minute. The Server Load Balancer system reports the hourly accumulated value to the billing system for settlement. Monitoring traffic data is collected by the Server Load Balancer system once per minute and reported to the CloudMonitor system. Therefore, these two sets of data are generated differently and are not comparable.

• An unavoidable delay occurs when the CLB system collects data and reports it to CloudMonitor. Although this delay is small and we try to ensure data timeliness, it can cause discrepancies between the monitoring data and the bill metering data. The bill metering data used for billing can tolerate a delay of up to three hours. For example, bill metering data generated between 01:00 and 02:00 is normally reported by Server Load Balancer to the billing system before 03:00 for billing. However, the system allows this reporting to be completed and billed as late as 05:00. Therefore, because of the different timeliness requirements for the data, these two sets of data are not comparable.

• The definitions of monitoring and bill metering are also different. The purpose of monitoring is to observe whether the running status of the monitored instance is abnormal so that you can take measures to resolve any issues. The purpose of bill metering is to charge based on the actual resource consumption of the instance. Therefore, for billing reconciliation, the data produced by the bill metering system must be used as the basis for billing, not the monitoring data.

How to Troubleshoot Abnormal Data Transfer Fees?

If you find that your CLB public network data transfer fees suddenly increase, perform the following steps to troubleshoot the issue:

1. View traffic trends: Log on to the CloudMonitor console, view the traffic monitoring data of the CLB instance, and identify the point in time when the traffic spike occurred.

2. Analyze the traffic source:

   • Check the access logs of the backend servers to identify abnormal requests.

     CLB supports configuring backend servers to obtain the real IP addresses of clients.

   • Analyze the request source using CLB access logs. You must enable this feature in advance.

3. Investigate abnormal access: Check for malicious attacks or web crawler access. Check whether any sudden business activities have caused an increase in traffic.

4. Protection recommendations:

   • Use Web Application Firewall (WAF) to protect against malicious traffic.

   • Use access control policies to restrict source IP addresses.

   • Set bandwidth monitoring alerts to detect abnormalities promptly.