Alibaba Cloud offers load balancing through a small family of services that share the Server Load Balancer name but differ substantially in their internals. Two are most often compared in production architecture decisions: Classic Load Balancer (CLB), historically and still commonly called SLB, and Application Load Balancer (ALB), a dedicated Layer 7 service introduced as a separate product. The two are sometimes treated as interchangeable; they are not, and the differences have direct consequences for routing flexibility, protocol support, and operational behaviour under load.
*Figure 1: Comparative architecture of Alibaba Cloud CLB and ALB.
*
CLB is a general-purpose load balancer that accepts both connection-level (TCP, UDP) and request-level (HTTP, HTTPS) traffic on a single instance. Its design favours protocol breadth and predictable forwarding behaviour over advanced HTTP semantics. ALB, by contrast, is purpose-built for HTTP-family traffic only; there is no TCP or UDP listener type, and it exposes the routing, rewriting, and mirroring capabilities that become available once the load balancer is parsing application-layer payloads.
CLB exposes TCP, UDP, HTTP, and HTTPS listeners, which lets it front databases, message brokers, and custom binary protocols alongside HTTP services. The HTTP listeners parse the protocol but support only basic distribution and cookie-based session persistence, no HTTP/2 between client and load balancer, no gRPC, no WebSocket termination. ALB inverts this profile: it does not accept TCP or UDP traffic, but supports HTTP/1.1, HTTP/2 end-to-end, QUIC, gRPC, and WebSocket over plain or TLS transport.
The routing model diverges just as sharply. A CLB listener binds to a single backend server group and distributes traffic by scheduling algorithm round-robin, weighted round-robin, weighted least connections, or consistent hashing on source IP. ALB replaces this single binding with an ordered rule list on each listener, where each rule combines match conditions (host, path, method, header, query parameter, cookie, source IP) with forwarding actions that extend beyond proxying: redirect, rewrite, header insertion, fixed response, or traffic mirroring. ALB server groups can also target Function Compute, enabling hybrid architectures where specific routes resolve to serverless backends without dedicated capacity.
Both services terminate TLS and integrate with the Certificate Management Service for centralised certificate handling. CLB HTTPS listeners support TLS 1.2; ALB adds TLS 1.3, along with Server Name Indication, useful for hosting multiple TLS hostnames behind a single virtual IP and supports mutual TLS through a CA-backed configuration that requires clients to present valid certificates during the handshake.
Health checks operate similarly on both: probes run at a configurable interval, and healthy and unhealthy thresholds govern when backends enter or leave rotation. The meaningful difference is what counts as healthy. CLB evaluates HTTP response codes; ALB additionally supports response body matching, which lets a health endpoint signal application-level readiness rather than mere TCP reachability. Connection draining is supported on both and should be tuned to the worst-case request duration of the workload, particularly for file uploads, streaming responses, and batch operations.
Capacity scaling is the most consequential operational difference. CLB capacity is fixed at provisioning time by selecting an instance specification, and outgrowing the chosen tier requires resizing. ALB scales horizontally with traffic, measured in Load Balancing Capacity Units that aggregate new connections, active connections, processed bytes, and rule evaluations. Both services emit metrics to CloudMonitor and stream access logs to Log Service; listener-level access control lists work on both, and ALB additionally integrates with Web Application Firewall in an in-path mode for Layer 7 filtering.
If the workload is not HTTP-family, CLB is the only option in this pair, since ALB does not accept TCP or UDP. If the workload is HTTP-family but requires only simple distribution across a single backend group, CLB is sufficient and uses fewer concepts. Beyond that, ALB is the correct selection for any one of host or path-based routing, HTTP/2 or gRPC, WebSocket termination, request rewriting, mutual TLS, traffic mirroring, or Function Compute targets individually justifies it. The two services frequently coexist in a single architecture, with CLB fronting Layer 4 components while ALB fronts the HTTP-facing surface.
SLB (CLB) and ALB solve the same general problem at different levels of abstraction: CLB offers protocol breadth across Layer 4 and Layer 7, and ALB offers HTTP depth confined to the application layer. The architectural decision between them is not about which is better in the abstract but about which set of constraints matches the workload protocol coverage, routing complexity, certificate requirements, and capacity scaling characteristics. Network Load Balancer (NLB) sits alongside both for ultra-low-latency Layer 4 workloads, and Container Service deployments typically front Kubernetes clusters with ALB through ingress controller annotations, keeping load balancer configuration under the same version control as application manifests.
Disclaimer: The views expressed herein are for reference only and don’t necessarily represent the official views of Alibaba Cloud.
Designing Production Network Architecture on Alibaba Cloud VPC
98 posts | 2 followers
FollowAlibaba Cloud Native - February 15, 2023
Alibaba Clouder - February 24, 2021
JDP - August 19, 2021
Kidd Ip - May 19, 2025
Alibaba Cloud Community - March 31, 2022
Alibaba Cloud TC Content - January 14, 2022
98 posts | 2 followers
Follow
Server Load Balancer
Respond to sudden traffic spikes and minimize response time with Server Load Balancer
Learn More
Cloud Migration Solution
Secure and easy solutions for moving you workloads to the cloud
Learn More
CloudBox
Fully managed, locally deployed Alibaba Cloud infrastructure and services with consistent user experience and management APIs with Alibaba Cloud public cloud.
Learn MoreMore Posts by PM - C2C_Yuan
