doc-exports/docs/elb/umn/elb_pro_0004.html

Differences Between Dedicated and Shared Load Balancers

Each type of load balancer has their advantages.

• In the eu-de region, you can create both dedicated and shared load balancers, and you can create either type of load balancers on the management console or by calling APIs.
• In the eu-nl region, you can only create dedicated load balancers, either on the console or by calling APIs.

Feature Comparison

Dedicated load balancers provide more powerful forwarding performance, while shared load balancers are less expensive. You can select the appropriate load balancer based on your application needs. The following tables compare the features supported by the two types of load balancers. (√ indicates that an item is supported, and x indicates that an item is not supported.)

Table 1 Performance

Item	Dedicated Load Balancers	Shared Load Balancers
Deployment mode	Each dedicated load balancer has exclusive use of underlying resources and can provide guaranteed performance that is not affected by other load balancers. Dedicated load balancers are available in different specifications.	Shared load balancers are deployed in clusters, and all the load balancers share underlying resources, so that the performance of a load balancer is affected by other load balancers.
Concurrent connections	A dedicated load balancer can establish up to 20 million concurrent connections. If you deploy a dedicated load balancer in multiple AZs, the number of concurrent connections will multiply. For example, if you deploy a dedicated load balancer in two AZs, it can handle up to 40 million concurrent connections. NOTE: If requests are from the Internet, the load balancer in each AZ you select routes the requests based on source IP addresses. For requests from a private network: If clients are in an AZ you select when you create the load balancer, requests are distributed by the load balancer in this AZ. If the load balancer is unavailable, requests are distributed by the load balancer in another AZ you select. If clients are in an AZ that is not selected when you create the load balancer, requests are distributed by the load balancer in each AZ you select based on source IP addresses.	The clusters can establish up to 1 million new connections and 100 million concurrent connections per second.

Table 2 Supported protocols

Protocol	Description	Dedicated Load Balancers	Shared Load Balancers
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.	√	√
HTTP/HTTPS (Layer 7)	After receiving a request, the listener needs to identify the request and forward data based on the fields in the HTTP/HTTPS packet header. 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.	√	√
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.	√	√

Table 3 Supported backend types

Backend Type	Description	Dedicated Load Balancers	Shared Load Balancers
ECS	You can use load balancers to distribute incoming traffic across ECSs.	√	√

Table 4 Advanced features

Feature	Description	Dedicated Load Balancers	Shared Load Balancers
Multiple specifications	Load balancers allow you to select appropriate specifications based on your requirements. For details, see Specifications of Dedicated Load Balancers.	√	x
HTTPS support	Load balancers can receive HTTPS requests from clients and route them to backend servers.	√	x
Mutual authentication	In this case, you need to deploy both the server certificate and client certificate. Mutual authentication is supported only by HTTPS listeners.	√	√
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.	√	√
Passing the EIP of each load balancer to backend servers	When you add an HTTPS or HTTP listener, you can store the EIP bound to the load balancer in the HTTP header and pass it to backend servers.	√	√
Security policies	When you add HTTPS listeners, you can select appropriate security policies to improve service security. A security policy is a combination of TLS protocols and cipher suites.	√	√

Table 5 Other features

Feature	Description	Dedicated Load Balancers	Shared Load Balancers
Cross-AZ deployment	You can create a load balancer in multiple AZs. Each AZ selects an optimal path to process requests. In addition, the AZs back up each other, improving service processing efficiency and reliability. If you deploy a dedicated load balancer in multiple AZs, its performance such as the number of new connections and the number of concurrent connections will multiply. For example, if you deploy a dedicated load balancer in two AZs, it can handle up to 40 million concurrent connections. NOTE: If requests are from the Internet, the load balancer in each AZ you select routes the requests based on source IP addresses. For requests from a private network: If clients are in an AZ you select when you create the load balancer, requests are distributed by the load balancer in this AZ. If the load balancer is unavailable, requests are distributed by the load balancer in another AZ you select. If clients are in an AZ that is not selected when you create the load balancer, requests are distributed by the load balancer in each AZ you select based on source IP addresses.	√	x
Load balancing algorithms	Load balancers support weighted round robin, weighted least connections, and source IP hash.	√	√
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.	√	√
Modifying the bandwidth	You can modify the bandwidth used by the EIP bound to the load balancer as required.	√	√
Binding/Unbinding an IP address	You can bind an IP address to a load balancer or unbind the IP address from a load balancer based on service requirements.	√	√
Sticky session	If you enable sticky sessions, requests from the same client will be routed to the same backend server during the session.	√	√
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.	√	√
Health check	Load balancers periodically send requests to backend servers to check whether they can process requests.	√	√
Certificate management	You can create two types of certificates: server certificate and CA certificate. If you need an HTTPS listener, you need to bind a server certificate to it. To enable mutual authentication, you also need to bind a CA certificate to the listener. You can also replace a certificate that is already used by a load balancer.	√	√
Tagging	If you have a large number of cloud resources, you can assign different tags to the resources to quickly identify them and use these tags to easily manage your resources.	√	√
Monitoring	You can use Cloud Eye to monitor load balancers and associated resources and view metrics on the management console.	√	√
Log auditing	You can use Cloud Trace Service (CTS) to record operations on load balancers and associated resources for query, auditing, and backtracking.	√	√

Parent topic: Service Overview