# Differences Between Classic and Shared Load Balancers

Each type of load balancer has their advantages.

- Classic load balancers are suitable for web services with low traffic and simple traffic patterns.

  Classic load balancers can no longer be created on the management console. Use shared load balancers or dedicated load balancers instead.

- Shared load balancers are suitable for choices for web services with heavy traffic. (Shared load balancers were previously named enhanced load balancers.)

Table 1 compares the features supported by the two types of load balancers. √ indicates that an item is supported, and — indicates that an item is not supported.

Table 1 Features supported by each type of load balancers
Feature | Description | Classic | Shared
--- | --- | --- | ---

Load balancing over public and private networks

- Each load balancer on a public network has a public IP address bound to it and routes requests from clients to backend servers over the Internet.
- Load balancers on a private network work within a VPC and route requests from clients to backend servers in the same VPC.

√

√

Layer 4 and Layer 7 load balancing

- Layer 4 load balancing: 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.
- Layer 7 load balancing: After receiving an HTTP or HTTPS request, the load balancer identifies the fields in the HTTP/HTTPS packet header and routes the request based on these fields. Though the routing efficiency is lower than that at Layer 4, load balancing at Layer 7 provides some advanced features such as encrypted transmission and cookie-based sticky sessions.

√ (UDP is not supported for load balancers on a private network.)

√

Load balancing algorithm | Round robin, least connections, and source IP hash | √ | √
Sticky session | If you enable sticky sessions, requests from the same client will be routed to the same backend server during the session. | √ | √
WebSocket protocol | 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. | √ | √
Domain name- or URL-based forwarding | ELB allows you to add forwarding policies to forward requests to different backend server groups based on the domain names or URLs specified in the forwarding policies. | — | √ (Currently, you can add forwarding policies only to HTTP or HTTPS listeners.)
Adding ECSs as backend servers | You can add ECSs to backend server groups to handle requests from load balancers. | √ | √
Whitelist-based access control | You can whitelist the IP addresses that can access a listener. | — | √
Standard OpenStack APIs | OpenStack APIs are supported and are compatible with self-developed APIs. | — | √
Adding BMSs as backend servers | BMSs can also be used as backend servers to handle requests distributed by load balancers. | — | √
SNI for certificates | Server Name Indication (SNI) is an extension to Transport Layer Security (TLS) and is used in cases that a server uses multiple domain names and certificates. After SNI is enabled, certificates corresponding to the domain names are required. | √ | √
SSL protocol | Load balancers use SSL to receive requests from clients. | √ | —
OBS storage for access logs | Access logs of load balancers can be dumped to OBS buckets for storage. | √ | —
Server weight | You can configure different weights for backend servers when you select the round robin or least connections as the load balancing algorithm. | — | √
Modifying certificate content | You can modify the content of a certificate. | — | √
Mutual authentication | The identities of both communication parties are authenticated to ensure security. You need to deploy both the server certificate and client certificate. Only HTTPS listeners support this feature. | — | √
HTTP redirection | HTTP traffic is redirected to HTTPS. When the client sends an HTTP request, the backend server returns an HTTPS response. | — | √
Performance monitoring on a per listener basis | Cloud Eye allows you to monitor your resources, including load balancers. | — | √

Parent topic: Service Overview