Server groups for Application Load Balancer (ALB) route client requests to one or more backend servers. To use an ALB instance, you must create a server group and add backend servers to it.
Configuration planning
Before you create a server group, determine the key configurations based on your business requirements. The server group type cannot be changed after creation, so select a type based on the deployment of your backend services.
Server group types
Server group type | Backend service types | Description | References |
Server | Elastic Compute Service (ECS), elastic network interface (ENI), and Elastic Container Instance (ECI) instances | The backend servers must be in the same Virtual Private Cloud (VPC) as the server group. | |
IP | IP addresses |
| |
Function Compute | Function Compute | Function Compute must be activated and in the same region as the ALB instance. | Add functions of Function Compute as backend servers for an ALB instance |
If a backend server of an ALB instance is released or its private IP address is modified, ALB does not automatically update the backend server. To prevent service disruptions, you must first remove the backend server from the ALB server group.
Backend protocols and scheduling algorithms
Backend protocol | Use cases |
HTTP (Default) | Most web application scenarios. Suitable for HTTP, HTTPS, and QUIC listeners. |
HTTPS | Requires encrypted communication between the ALB instance and backend servers. Suitable for HTTPS and HTTP listeners. |
gRPC | Backend services that use the gRPC protocol. Requires an HTTPS listener with HTTP/2 enabled. |
Scheduling algorithm | Use cases |
Weighted round-robin | General-purpose scenarios. Distributes requests evenly based on weight ratios. |
Weighted least connections | Scenarios with long-lived connections or varying request processing times. Considers both weights and real-time connections, prioritizing servers with lower loads. |
Consistent hash | Scenarios that require request affinity, such as for cache hit optimization. Routes requests with the same characteristics to the same backend server based on source IP or URL parameters. |
For details on the algorithm logic, see Load balancing scheduling algorithms.
The following table shows the compatibility between listener protocols, backend protocols, and health check protocols.
Listener protocol | Backend protocols | Server group types | Health check protocols |
HTTP | HTTP and HTTPS | Server, IP, and Function Compute Function Compute server groups do not require configuration for backend protocols or health check protocols. | HTTP, HTTPS, TCP, and gRPC Basic ALB instances do not support HTTPS health checks. |
HTTPS | HTTP, HTTPS, and gRPC gRPC requires an HTTPS listener with HTTP/2.0 enabled. HTTPS listeners for Basic ALB instances only support HTTP and gRPC backend protocols. | ||
QUIC | HTTP |
Create and delete server groups
Console
Create a server group
Go to the Server Groups page in the ALB console.
In the top navigation bar, select a region and click Create Server Group. Configure the following parameters and click Create.
Server Group Type: Select a type based on how your backend services are deployed.
Server: Uses ECS, ENI, or ECI instances as backend servers. The instances must be in the same VPC as the server group.
IP Address: Uses IP addresses as backend servers. Supports IP addresses within the VPC. If you enable remote IP, you can also add IP addresses from other VPCs or on-premises IDCs.
Function Compute: Uses Function Compute as the backend service. Function Compute must be activated and in the same region as the ALB instance.
Server Group Name: Enter a custom name for the server group.
VPC: The VPC to which the server group belongs. Only backend servers in this VPC can be added to this server group.
If you enable remote IP for an IP-type server group, backend servers are not limited to this VPC but must be reachable from the VPC network.
You do not need to configure this parameter for Function Compute server groups.
Backend Server Protocol: Select the communication protocol between the ALB instance and backend servers.
HTTP (Default): Suitable for HTTP, HTTPS, and QUIC listeners. Communication between the ALB instance and backend servers uses HTTP.
HTTPS: Suitable for HTTPS and HTTP listeners. Communication between the ALB instance and backend servers uses HTTPS for encryption.
gRPC: Suitable for HTTPS listeners. Communication between the ALB instance and backend servers uses the gRPC protocol.
HTTPS listeners on Basic ALB instances support only the HTTP and gRPC backend protocols.
You do not need to configure this parameter for Function Compute server groups.
Scheduling Algorithm: Select a request distribution strategy.
Weighted Round-robin: Distributes requests based on weight ratios. Backend servers with higher weights receive more requests.
Weighted Least Connections: Distributes requests based on both weights and real-time connections. Among servers with the same weight, the one with the fewest current connections receives the next request.
Consistent Hash: Routes requests with the same characteristics to the same backend server based on a hash factor.
Hash Factor:
Source IP: Hashes based on the client's source IP address.
URL Parameters: Hashes based on the value of a specified URL parameter. You must enter the Specified URL.
This parameter is not required for Function Compute-type server groups.
Tags and Resource Group: Optional. Used to categorize and manage server groups.
Tag Key and Tag Value: Tag the server group with a key-value pair.
Resource Group: The resource group to which the server group belongs. Default: default resource group.
Backend Persistent Connection: Enabled by default. When enabled, the ALB instance maintains persistent TCP connections with backend servers, reusing existing connections to reduce latency and lower the load on backend servers.
This parameter is not required for Function Compute-type server groups.
Health Check: Enabled by default. Detects the availability of backend servers.
Health checks are disabled by default for Function Compute-type server groups. If enabled, health check probes are counted as Function Compute requests and incur fees.
Health Check Settings: Click Modify on the right to expand the settings. For parameter descriptions, see Health checks for ALB.
Select and Load Health Check: Select an existing health check template and load its configuration.
You can create unassociated health check templates for future use.
Each server group supports only one health check.
Delete a server group
You can delete a server group only if it is not associated with any listener forwarding rules. Deleting a server group does not affect its backend servers.
Go to the Server Groups page in the ALB console. Find the target server group, and in the Actions column, choose 
> Delete and then click OK.
API
Call CreateServerGroup to create a server group.
Call DeleteServerGroup to delete a specified server group.
Add and remove backend servers
Before adding a backend server, ensure that your applications are deployed on it.
ALB uses specific IP addresses to communicate with backend servers and perform health checks. Ensure that your backend servers do not block these addresses with firewall rules, such as iptables, or other security software.
Upgraded ALB instances use private IP addresses (local IPs) from their vSwitch CIDR block for communication. You can view these IPs on the instance details page.
Non-upgraded ALB instances use the 100.64.0.0/10 CIDR block to communicate with backend servers.
Ensure that the backend server configuration does not create a forwarding path that results in a loop.
Console
Add backend servers
Server type
Go to the Server Groups page in the ALB console. Find the target server group and click Modify Backend Server in the Actions column.
On the Backend Servers tab, click Add Backend Server. In the Add Backend Server panel, add the servers and click Next.
Add ECS instances
Set Server Type to ECS/ENI and select the target ECS instances.
If no ECS instances are available, click Purchase ECS Instance in the upper-right corner of the server list.
Add ENIs
Set Server Type to ECS/ENI and enable Advanced Mode.
Click the
icon to the left of the target ECS instance ID and select the target ENI.
To add an ENI, make sure it is already bound to an ECS instance. For more information, see Bind a secondary ENI.
Add ECI instances
Set Server Type to ECI and select the target ECI instances.
If no ECI instances are available, click Purchase Elastic Container Instance in the upper-right corner of the server list.
On the Ports/Weights page, set the ports and weights for the added servers, and then click OK.
Port: The port on which the backend server provides services.
Weight: The proportion of traffic distributed to the server. The value can range from 0 to 100. The default is 100.
For example, if a server group contains three servers with weights of 100, 50, and 50 respectively, requests are distributed in a 2:1:1 ratio. The server with a weight of 100 receives 50% of the requests, while the other two each receive 25%.
NoteIf session persistence is enabled, request distribution among backend servers might be uneven.
If the weight of a server is set to 0, it no longer receives new requests.
Servers that fail health checks do not receive traffic. Requests are distributed among the remaining healthy servers based on their weight ratio.
If all servers in a server group are unhealthy, ALB still attempts to distribute traffic based on server weights to minimize service disruptions.
Batch operations:
Select multiple servers and use the Set Same Port, Set Same Weight, or Remove Backend Servers options at the bottom of the list.
Hover over a port or weight input box and select Replicate to Below, Replicate to Above, or Replicate to All to quickly copy the current value to other servers.
Click Reset in the Port or Weight column header to clear all server ports or restore all weights to their default values.
Function Compute type
ALB supports both Function Compute 2.0 and 3.0. Communication between ALB and Function Compute occurs securely over the Alibaba Cloud internal network.
You must activate the Function Compute service before use. Alibaba Cloud accounts registered after August 27, 2024 that have completed real-name verification can use the service directly without activation.
Limitations
Regions that support adding Function Compute as backend servers.
The ALB instance and the function must be in the same region.
A Function Compute-type server group can have only one function.
For Function Compute 2.0, if the Handler Type is Event Handler, you must configure an HTTP trigger to associate the function with an ALB instance.
Go to the Server Groups page in the ALB console. Find the target server group and click Modify Backend Server in the Actions column.
On the Backend Servers tab, click Add Function. In the Add Backend Server panel, use one of the following methods to configure the function, and then click OK.
Service
Function Name: Select a created function. If no functions are available, you can Create Function. For more information, see Create a function.
Version or Alias: Select Specified Version or Specified Alias. A newly created function has only a LATEST version by default.
Configure by using ARN
ARN: Enter the ARN of the target function. You can obtain the function ARN from the function details page in the Function Compute console.
IP type
If remote IP is not enabled, you can only add IP addresses from the current VPC's CIDR block. If remote IP is enabled, you can also add IP addresses from other VPCs or on-premises IDCs.
Starting from 00:00:00 on February 25, 2025 (UTC+8), new instances will be upgraded ALB instances by default. Existing ALB instances are not affected, except for those created through self-service applications. For details, see Application Load Balancer (ALB) instance upgrade announcement.
Limitations
Non-upgraded ALB instances do not support adding ALB, NLB, or CLB instances from the same VPC to an IP-type server group. If you need to add these resources from the same VPC, make sure you are using an upgraded ALB instance to avoid potential service issues.
Upgraded instances
Backend server limitations
Only private IP addresses are supported. Public IP addresses are not supported.
If IPv6 is enabled, you can add only IPv6 addresses from the server group's VPC CIDR block. The remote IP feature is not supported.
Forwarding configuration limitations
If you use an Enterprise Edition Transit Router, it creates an ENI on a vSwitch in your specified zone. This ENI acts as the traffic ingress from the VPC to the transit router. When you create your VPC instance, ensure that you create at least one vSwitch in the specified zone to connect the VPC instance to the transit router. For details, see How transit routers work.
Traffic between an ALB instance and its backend servers can only be forwarded through the system route table. Custom route tables in the VPC are not supported.
Non-upgraded instances
Backend server limitations
Regions that support adding remote IPs for non-upgraded ALB instances.
Cross-region backend servers are only supported for IP-type server groups.
Only private IP addresses are supported. Public IP addresses are not supported.
Adding ALB, NLB, or CLB instances from the same VPC is not supported.
Forwarding configuration limitations
Remote IP forwarding is supported through an Enterprise Edition Transit Router or Express Connect. Basic Edition transit routers are not supported.
If you use an Enterprise Edition Transit Router, it creates an ENI on a vSwitch in your specified zone. This ENI acts as the traffic ingress from the VPC to the transit router. When you create your VPC instance, ensure that you create at least one vSwitch in a supported zone to connect the VPC instance to the transit router. For more information, see Supported regions and zones for Enterprise Edition Transit Routers.
ALB instances in multiple VPCs within the same region cannot use the same transit router to access a backend service.
ALB instances in multiple VPCs within the same region cannot use multiple transit routers to access the same backend service.
Traffic between an ALB instance and its backend servers can be forwarded only through the system route table. Custom route tables in the VPC are not supported.
Go to the Server Groups page in the ALB console. Find the target server group and click Modify Backend Server in the Actions column.
On the Backend Servers tab, click Add IP Address. In the Add Backend Server panel, enter the IP addresses of the backend servers, and then click Next.
If you enable Remote IP, you can enter IP addresses from the following private CIDR blocks: 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, and 192.168.0.0/16.
If you do not enable Remote IP, you can only enter IP addresses from the current VPC's CIDR block.
To add multiple backend servers, click Add IP Address.
On the Ports/Weights page, set the ports and weights, and then click OK.
Port: The port on which the backend server provides services.
Weight: The proportion of traffic distributed to the server. The value can range from 0 to 100. The default is 100.
For example, if a server group contains three servers with weights of 100, 50, and 50 respectively, requests are distributed in a 2:1:1 ratio. The server with a weight of 100 receives 50% of the requests, while the other two each receive 25%.
NoteIf session persistence is enabled, request distribution among backend servers might be uneven.
If the weight of a server is set to 0, it no longer receives new requests.
Servers that fail health checks do not receive traffic. Requests are distributed among the remaining healthy servers based on their weight ratio.
If all servers in a server group are unhealthy, ALB still attempts to distribute traffic based on server weights to minimize service disruptions.
Batch operations:
Select multiple servers and use the Set Same Port, Set Same Weight, or Remove Backend Servers options at the bottom of the list.
Hover over a port or weight input box and select Replicate to Below, Replicate to Above, or Replicate to All to quickly copy the current value to other servers.
Click Reset in the Port or Weight column header to clear all server ports or restore all weights to their default values.
Remove backend servers
After a server is removed, it no longer handles forwarded requests.
Removing a server directly may cause service interruptions. To prevent this, set the server's weight to 0 before removing it.
Go to the Server Groups page in the ALB console. Find the target server group and click Modify Backend Server in the Actions column.
On the Backend Servers tab, find the target backend server, click Remove in the Actions column, and then click OK.
API
Call AddServersToServerGroup to add backend servers to a server group.
Call RemoveServersFromServerGroup to remove backend servers from a server group.
Session persistence
Enable session persistence when multiple requests from the same client must be handled by the same backend server, such as for shopping carts or login sessions.
Session Persistence: Disabled by default. When enabled, the ALB instance distributes requests from the same client to the same backend server.
This parameter is not required for Function Compute-type server groups.
Only server groups of the Server and IP types are supported. When cross-zone load balancing is disabled, session persistence cannot be enabled.
Console
When creating or editing a server group, enable session persistence and select a cookie handling method:
Cookie Option:
Insert Cookie: Application Load Balancer (ALB) automatically generates a cookie (SERVERID) and inserts it into the response. Subsequent requests that carry this cookie are forwarded to the same backend server. The valid range for Session Persistence Timeout Period is 1 to 86,400 seconds.
Rewrite Cookie: ALB rewrites the value of a user-defined cookie. Enter the Cookie name.
API
Configure session persistence using the StickySessionConfig parameter when you call CreateServerGroup or UpdateServerGroupAttribute.
For more information, see Configure session persistence for an ALB.
Graceful start and shutdown
Slow start
A newly added backend server may not be able to immediately handle a full traffic load due to factors like an unwarmed cache or unestablished connection pools. By enabling slow start, the ALB instance gradually increases the number of requests sent to the new server over a specified period, which prevents traffic spikes from overwhelming a server that is not fully ready.
Supported only when the scheduling algorithm is weighted round-robin.
Only Standard and WAF-enhanced ALB instances are supported. Basic ALB instances are not supported.
You do not need to configure this parameter for Function Compute server groups.
Console
When you create or edit a server group, enable Slow Start and set the Slow Start Duration. The duration must be between 30 and 900 seconds, with a default of 30 seconds. Normal traffic distribution resumes after the duration expires.
API
When you call CreateServerGroup or UpdateServerGroupAttribute, use SlowStartConfig to configure slow start.
How slow start works:
Existing healthy backend servers in a server group do not automatically enter slow start mode. The first backend server added to an empty server group does not enter slow start mode. A new backend server enters slow start mode only if the server group contains at least one healthy backend server that is not in slow start mode.
A backend server in slow start mode exits this mode when it is removed. If the same backend server is added again, it re-enters slow start mode after it becomes healthy.
A backend server in slow start mode exits this mode if it becomes unhealthy. It re-enters slow start mode after it becomes healthy again.
If health checks are enabled, slow start takes effect after a backend server becomes healthy. If health checks are disabled, slow start takes effect immediately.
For more information, see Implement a graceful service launch by using ALB slow start.
Connection draining
When a backend server is removed or fails a health check, existing connections are terminated by default only when the client actively disconnects or the session expires. By enabling connection draining, existing connections can finish processing within a timeout period before being disconnected, ensuring a smooth service shutdown.
Supported only by Standard and WAF-enabled ALB instances. Basic ALB instances do not support this feature.
You do not need to configure this parameter for server groups of the Function Compute type.
Console
When creating or editing a server group, enable Connection Draining and set the Timeout Period. The timeout can be set from 0 to 900 seconds. A value of 0 immediately interrupts connections. The default is 300 seconds.
API
When calling CreateServerGroup or UpdateServerGroupAttribute, use ConnectionDrainConfig to configure connection draining.
For more information, see Use ALB connection draining to gracefully take services offline.
Reduce cross-zone latency
By default, an ALB instance distributes traffic across backend servers in different zones within the same region. If your business is latency-sensitive and has sufficient backend server resources in each zone, you can disable cross-zone load balancing. This ensures that traffic is distributed only among backend servers within the same zone, which reduces cross-zone network latency.
This feature can be disabled only for Standard and WAF-enabled ALB instances. It is not supported for Basic ALB instances.
For IP server groups that have remote IP enabled, you cannot disable cross-AZ load balancing.
Session persistence is not supported when cross-AZ load balancing is disabled.
You do not need to configure this parameter for Function Compute server groups.
Console
When you create or edit a server group, turn off Cross-zone Load Balancing.
API
When you call CreateServerGroup or UpdateServerGroupAttribute, set CrossZoneEnabled to false to turn off cross-zone load balancing. The default is true.
For more information, see Disable cross-zone load balancing in ALB to reduce request latency.
Add IPv6 backend servers
You can enable IPv6 support to add IPv6-type backend servers to a server group.
Supported only for Server and IP type server groups.
The server group's VPC must have IPv6 enabled.
A server group with IPv6 enabled can be added only to forwarding rules of a dual-stack ALB instance.
For an IP-type server group, the ALB instance must be an upgraded instance. This configuration supports only IPv6 addresses from the server group's VPC; the remote IP feature is not available.
Console
When you create a server group, enable IPv6.
API
When you call CreateServerGroup, set Ipv6Enabled to true to enable IPv6 support.
Edit health checks
Modify the health check configuration of a server group.
If you disable health checks, the ALB instance cannot detect backend server failures, and traffic is not automatically routed to healthy servers.
A longer health check interval increases the time it takes for the ALB instance to detect a failed server.
Console
Go to the Server Groups page in the ALB console. Find the target server group and click Modify Health Check in the Actions column.
In the Modify Health Check dialog box, enable or disable health checks as needed. If you enable health checks, click Modify next to Health Check Settings to change the parameters.
API
Call UpdateServerGroupAttribute to update the health check configuration of a server group.
Billing
Server groups are free of charge. However, you are charged for the ALB instance and the backend servers in the server group based on their respective billing rules.
Quotas
Quota name | Description | Default | Maximum value | Adjustable |
alb_quota_loadbalancer_servers_num_basic_edition | Number of backend servers that can be added to a Basic ALB instance | 200 | 400 | |
alb_quota_loadbalancer_servers_num_standard_edition | Number of backend servers that can be added to a Standard ALB instance | 1,000 | 1,500 | |
alb_quota_loadbalancer_servers_num_standardwithwaf_edition | Number of backend servers that can be added to a WAF-enabled ALB instance | 1,000 | 1,500 | |
alb_quota_server_added_num | Number of server groups to which a backend server (by IP address) can be added | 200 | 300 | |
alb_quota_servergroup_attached_num | Number of forwarding rules to which a server group can be attached | 50 | 100 | |
alb_quota_server_groups_weight | Maximum weight of a single server group in a forwarding rule | 100 | 10,000 | Contact your account manager |