Feature Comparison Details

Protocols

**Table 1** Protocols supported by each load balancer type
Protocol	Description	Dedicated Load Balancer	Shared Load Balancer
TCP/UDP (Layer 4)	After receiving TCP or UDP requests from the clients, the load balancer directly routes the requests to backend servers. Load balancing at Layer 4 features high routing efficiency.	Supported	Supported
HTTP/HTTPS (Layer 7)	After receiving an access request, the listener needs to identify the request and forward it based on the header fields. Load balancing at Layer 7 provides some advanced features such as encrypted transmission and cookie-based sticky sessions.	Supported	Supported
HTTPS support	HTTPS can be used as both the frontend and backend protocol.	Supported	Not supported
TLS	Network load balancing: TLS applies to scenarios that require ultra-high performance and large-scale TLS offloading.	Supported	Not supported
QUIC	If you use UDP or QUIC as the frontend protocol, you can select QUIC as the backend protocol, and select the connection ID algorithm to route requests with the same connection ID to the same backend server. QUIC offers low latency, high reliability, and eliminates head-of-line blocking (HOL blocking), making it ideal for mobile Internet applications. It allows seamless switching between Wi-Fi and carrier networks without establishing new connections.	Supported	Not supported
HTTP/2	Hypertext Transfer Protocol 2.0 (HTTP/2) is a new version of the HTTP protocol. It is compatible with HTTP/1.X and provides improved performance and security. Only HTTPS listeners support this feature.	Supported	Supported
gRPC	gRPC is a high-performance general RPC open-source software framework that helps ELB run over HTTP/2. Only when you add an HTTPS listener and enable HTTP/2, you can select gRPC as the backend protocol.	Supported	Not supported
WebSocket	WebSocket is a new HTML5 protocol that provides full-duplex communication between the browser and the server. WebSocket saves server resources and bandwidth, and enables real-time communication.	Supported	Supported

Network Configurations

**Table 2** Network configuration comparison
Feature	Description	Dedicated Load Balancer	Shared Load Balancer
Public IPv4 network	The load balancer routes requests from the clients to backend servers over the Internet.	Supported	Supported
Private IPv4 network	The load balancer routes requests from the clients to backend servers in a VPC.	Supported	Supported
IPv6 network	Load balancers can route requests from IPv6 clients.	Supported	Not supported
Changing a private IPv4 address	You can change the private IPv4 address into another one in the current subnet or other subnets.	Supported	Not supported
Binding or unbinding an EIP	You can bind an EIP to a load balancer or unbind the EIP from a load balancer based on service requirements.	Supported	Supported
Modifying the bandwidth	You can change the bandwidth of public network load balancers as required.	Supported	Supported

Key Features of Listeners

**Table 3** Comparison of key features
Feature	Description	Dedicated Load Balancer	Shared Load Balancer
Forwarding by Port Ranges	The listener listens to requests from all ports in the port range you specify and routes them to the corresponding ports on the backend servers. Only TCP and UDP listeners support this feature.	Supported	Not supported
Access Control	You can add IP addresses to a whitelist or blacklist to control access to a listener. A whitelist allows specified IP addresses to access the listener. A blacklist denies access from specified IP addresses.	Supported	Supported
Mutual Authentication	This feature allows the clients and the load balancer to authenticate each other. Only authenticated clients will be allowed to access the load balancer. Mutual authentication is supported only by HTTPS listeners.	Supported	Supported
SNI	Server Name Indication (SNI) is an extension to TLS and is used when a server uses multiple domain names and certificates. After SNI is enabled, certificates corresponding to the domain names are required. SNI can be enabled only for HTTPS listeners.	Supported	Supported
Transfer Client IP Address	This feature allows backend servers to obtain the real IP addresses of the clients. This feature is enabled for dedicated load balancers by default and cannot be disabled.	Supported	Supported
Advanced features of HTTP/HTTPS listeners
Default Security Policy	You can select appropriate security policies to improve service security when you add HTTPS listeners. A security policy is a combination of TLS protocols and cipher suites.	Supported	Supported
Custom Security Policy	You can select a TLS protocol and cipher suite to custom a security policy when you add HTTPS listeners.	Supported	Not supported
Transfer Load Balancer EIP	You can store the EIP bound to the load balancer in the X-Forwarded-ELB-IP header and pass it to backend servers.	Supported	Supported
Transfer Load Balancer ID	You can store the load balancer ID in the X-Forwarded-ELB-ID header and pass it to backend servers.	Supported	Not supported
Transfer Listener Port Number	You can store the listener port number in the X-Forwarded-Port header and pass it to backend servers.	Supported	Not supported
Transfer Port Number in the Request	You can store the port number used by the client to connect to the load balancer, in the X-Forwarded-For-Port header and transmit it to backend servers.	Supported	Not supported
Rewrite X-Forwarded-Host	You can rewrite the Host header in the request into the X-Forwarded-Host header and transmit it to the backend servers.	Supported	Supported
Rewrite X-Forwarded-Proto	You can rewrite the listener protocol into the X-Forwarded-Proto header and transmit it to the backend servers.	Supported	Not supported
Rewrite X-Real-IP	You can rewrite the source IP address of the client into the X-Real-IP header and transmit it to the backend servers.	Supported	Not supported

Forwarding Capabilities

You can configure forwarding policies for HTTP or HTTPS listeners to forward requests to different backend server groups. Advanced forwarding policies are available only for dedicated load balancers.

Table 4 and Table 5 describe the available forwarding rules and actions.

**Table 4** Forwarding rules supported by each load balancer type
Forwarding Rule	Description	Dedicated Load Balancer	Shared Load Balancer
Domain name	Route requests based on the domain name. The domain name in the request must exactly match that in the forwarding policy.	Supported	Supported
Path	Route requests based on the specified path. There are three matching rules: exact match, prefix match, and regular expression match.	Supported	Supported
HTTP request method	Route requests based on the HTTP method. The options include GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS.	Supported	Not supported
HTTP header	Route requests based on the HTTP header. An HTTP header consists of a key and one or more values. You need to configure the key and values separately.	Supported	Not supported
Query string	Route requests based on the query string.	Supported	Not supported
CIDR block	Route requests based on source IP addresses from where the requests originate.	Supported	Not supported

**Table 5** Actions supported by each load balancer type
Action	Description	Dedicated Load Balancer	Shared Load Balancer
Forward to a backend server group	Forward requests to the specified backend server group.	Supported	Supported
Redirect to another listener	Redirect requests to an HTTPS listener, which then routes the requests to its associated backend server group.	Supported	Supported
Redirect to another URL	Redirect requests to the configured URL. When clients access website A, the load balancer returns 302 or any other 3xx status code and automatically redirects the clients to website B. You can custom the redirection URL that will be returned to the clients.	Supported	Not supported
Return a specific response body	Return a fixed response to the clients. You can custom the status code and response body that load balancers directly return to the clients without the need to route the requests to backend servers.	Supported	Not supported
Rewrite	Rewrite the request URL before forwarding requests to the specified backend server group.	Supported	Not supported

Key Features of Backend Server Groups

**Table 6** Key features supported by each load balancer type
Key Feature	Description	Dedicated Load Balancer	Shared Load Balancer
Health check	ELB periodically sends requests to backend servers to check their running statuses. This process is called health check. You can perform health checks to determine whether a backend server is available.	Supported	Supported
Sticky session	Requests from the same client will be routed to the same backend server during the session.	Supported	Supported
Slow start	The load balancer linearly increases the proportion of requests to the new backend servers added to the backend server group. Slow start gives applications time to warm up and respond to requests with optimal performance.	Supported	Not supported
Active/Standby forwarding	The load balancer routes the traffic to the active server if it works normally and to the standby server if the active server becomes unhealthy. You must add two backend servers to the backend server group, one acting as the active server and the other as the standby server.	Supported	Not supported
Forward to same port	You do not need to specify a backend port when you add a backend server. The listener routes the requests to the backend server over the same port as the frontend port. This option is available only for TCP, UDP, or QUIC backend server groups associated with a dedicated load balancer.	Supported	Not supported
Deregistration delay	If a backend server is removed or the health check fails, ELB continues to route in-flight requests to this server until the deregistration delay timeout expires.	Supported	Not supported

Load Balancing Algorithms

**Table 7** Load balancing algorithm comparison
Load Balancing Algorithm	Description	Dedicated Load Balancer	Shared Load Balancer
Weighted round robin	Route requests to backend servers using the round robin algorithm. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests.	Supported	Supported
Weighted least connections	Route requests to backend servers with the smallest ratio (current connections divided by weight).	Supported	Supported
Source IP hash	Route requests from the same client to the same backend server within a period of time.	Supported	Supported
Connection ID	Calculate the source IP address of each request using the consistent hashing algorithm to obtain a unique hash key and route the requests to the particular server based on the generated key.	Supported	Not supported

Backend Server Type

**Table 8** Supported backend server types
Backend Server Type	Description	Dedicated Load Balancer	Shared Load Balancer
IP as backend server	You can add servers in a peer VPC, in a VPC that is in another region and connected through a cloud connection, or in an on-premises data center at the other end of a Direct Connect or VPN connection, by using the server IP addresses.	Supported	Not supported
Supplementary network interface	You can attach supplementary network interfaces to backend servers.	Supported	Not supported
ECS	You can use load balancers to distribute incoming traffic across ECSs.	Supported	Supported
BMS	You can use load balancers to distribute incoming traffic across BMSs.	Supported	Supported
CCE Turbo cluster	You can use load balancers to distribute incoming traffic across CCE Turbo clusters. For details, see the Cloud Container Engine User Guide.	Supported	Supported