Updated on 2026-09-07 GMT+08:00

Backend Server Group Overview

What Is a Backend Server Group?

A backend server group is a logical collection of one or more backend servers to receive massive concurrent requests at the same time. A backend server can be a cloud server, supplementary network interface, or IP address.

The following table describes how a backend server group works in the traffic forwarding process.

Table 1 Traffic distribution process

Step 1

A client sends a request to your application. The listeners added to your load balancer use the protocols and ports you have configured to forward the request to the associated backend server group.

Step 2

Healthy backend servers in the backend server group receive the request based on the load balancing algorithm, handle the request, and return a result to the client.

Step 3

In this way, massive concurrent requests can be processed at the same time, improving the availability of your applications.

For dedicated load balancers, the backend server group type can be Hybrid or IP as a backend server. You can add cloud servers, supplementary network interfaces, or IP addresses to a hybrid backend server group. If you set the type to IP as a backend server, you can only add IP addresses as backend servers.

Figure 1 shows the architecture of different types of backend server groups. For details, see Table 2.

Figure 1 Backend server group architecture
Table 2 Backend server group types

Backend Server Group Type

Backend Server Type

Example

Hybrid

  • Cloud servers (ECSs and BMSs) and supplementary network interfaces that are in the same VPC as the load balancer
  • Cloud servers in other VPCs or on-premises servers if IP as a backend is enabled for the load balancer

As shown in Figure 1:

  • In backend server group A, you can add ECSs or supplementary network interfaces in VPC1.
  • In backend server group B, you can add IP addresses in VPC2 as backend servers.

IP as a backend server

IP addresses of cloud or on-premises servers if IP as a backend is enabled for the load balancer

As shown in Figure 1, IP addresses can be added to backend server group C as backend servers.

Advantages

Backend server groups can bring the following benefits:

  • Reduced costs and easier management: You can add or remove backend servers as traffic changes over time. This can help avoid low resource utilization and make it easier to manage backend servers.
  • Higher reliability: The health check function ensures traffic is routed only to healthy backend servers in the backend server group.

Controlling Traffic Distribution

You can configure the key functions listed in Table 3 for each backend server group to ensure service stability.

Table 3 Key functions

Key Function

Description

Detail

Forwarding Mode

Specifies the forwarding mode used by the load balancer to distribute traffic.

There are two options: Load balancing and Active/Standby.

  • Load balancing: Multiple backend servers can be added to this type of backend server group. The load balancer distributes requests across these backend servers based on the load balancing algorithm configured for this backend server group.
  • Active/Standby: After the active and standby nodes are configured, the load balancer distributes traffic based on the health check results of the active and standby nodes. The roles of the active and standby nodes are not switched. The following shows how this works:
    • If the active node is healthy, the load balancer forwards traffic to the active node.
    • If the active node is unhealthy but the standby node is healthy, new connections will be established with the standby node, and the existing connections with the active node are disconnected after the timeout interval expires.
    • When the active node becomes healthy, new connections will be established with the active node again, and the existing connections with the standby node are disconnected after the timeout interval expires.

Creating a Backend Server Group

Load Balancing Algorithm

A load balancer distributes incoming traffic across backend servers based on the load balancing algorithm configured for the backend server group. For details about the comparison between different load balancing algorithms, see Table 4.

Configuring Load Balancing Algorithms to Distribute Traffic

Sticky Session

Specifies whether to enable the sticky session option. If you enable this option, all requests from the same client during one session are sent to the same backend server. For details about the comparison between different sticky session types, see Table 5.

Enabling Sticky Session to Accelerate Access

Slow Start

Specifies whether to enable slow start. After you enable it, the load balancer linearly increases the proportion of requests to new backend servers in the backend server group.

When the slow start duration elapses, the load balancer sends full share of requests to these backend servers and exits the slow start mode.

Configuring Slow Start for a Backend Server Group

Forward to Same Port

Specifies whether to enable the forward to same port option. After you enable it, 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.

NOTE:

This option is available only for TCP, UDP, or QUIC backend server groups associated with a dedicated load balancer.

Creating a Backend Server Group

AZ Affinity

If this option is enabled, ELB forwards traffic across the backend servers in the same AZ as the load balancer, minimizing access latency.

Using AZ Affinity to Minimize Access Latency

Table 4 Load balancing algorithms

Load Balancing Algorithm

Description

Weighted round robin

Requests are routed to backend servers in sequence based on their weights. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests.

Weighted least connections

In addition to the number of active connections established with each backend server, each server is assigned a weight based on its processing capability. Requests are routed to the server with the lowest connections-to-weight ratio.

Consistent hashing

  • Source IP hash
  • Connection ID

Calculates the request fields using the consistent hashing algorithm to obtain a hash value and routes requests with the same hash value to the same backend server, even if the number of backend servers in the backend server group changes.

  • Source IP hash: Calculates the source IP address of each request and routes requests from the same source IP address to the same backend server.
  • Connection ID: Calculates the QUIC connection ID and routes requests with the same ID to the same backend server.
Table 5 Comparison of sticky session types

Sticky Session Type

Description

Stickiness Duration (Minutes)

Scenarios Where Sticky Session Become Invalid

Source IP address

The source IP address of each request is calculated using the consistent hashing algorithm to obtain a unique hashing key, and all backend servers are numbered. The system allocates the requests from a client to a particular server based on the generated key. This allows requests from the same IP address to be forwarded to the same backend server.

  • Default: 20
  • Maximum: 60
  • Range: 1–60
  • Source IP addresses of the clients have changed.
  • The session stickiness duration has been reached.

Load balancer cookie

The load balancer generates a cookie after it receives a request from a client. All the subsequent requests with the same cookie are distributed to the same backend server.

  • Default: 20
  • Maximum: 1440, in minutes
  • Range: 1–1440, in minutes
  • Sticky sessions do not take effect when requests sent by the clients do not contain cookies.
  • The session stickiness duration has been reached.

Application cookie

The application deployed on the backend server generates a cookie after receiving the first request from the client. All subsequent requests with the cookie are routed to the same backend server.

Backend Server Group and Listener Protocols

You can associate a backend server group with different dedicated load balancers under the same enterprise project or different listeners.

The backend protocol of the new backend server group must match the frontend protocol of the listener, as described in Table 6.

Table 6 The frontend and backend protocols

Load Balancer Specification

Frontend Protocol

Backend Protocol

Network load balancing

TCP

TCP

Network load balancing

UDP

  • UDP
  • QUIC

Network load balancing

TLS

  • TLS
  • TCP

Application load balancing

HTTP

HTTP

Application load balancing

HTTPS

  • HTTP
  • HTTPS
  • gRPC

Application load balancing

QUIC

  • HTTP
  • HTTPS

TLS, gRPC, and QUIC will be available in more regions. You can see which regions support them on the console.