Create and manage server groups

An Application Load Balancer (ALB) server group routes client requests to one or more backend servers. To use an ALB instance, you must create a server group and add backend servers to receive forwarded requests.

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. Select a type based on how your backend services are deployed.

Select a server group type

Server group type	Backend service types	Description	Related documentation
Server	Elastic Compute Service (ECS) instances, elastic network interfaces (ENIs), and Elastic Container Instance (ECI) instances	The backend servers must be in the same Virtual Private Cloud (VPC) as the server group.	Quickly implement IPv4 load balancing with an ALB instance Quickly implement IPv6 load balancing with an ALB instance
IP	IP addresses	Remote IP enabled: Use this option when backend servers are not in the server group's VPC, such as IP addresses in other VPCs or on-premises data centers. The following CIDR blocks are supported: 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, and 192.168.0.0/16. Remote IP disabled: Only IP addresses within the server group's VPC are supported.	Use an ALB instance to add servers in a cross-region VPC Use an ALB instance to add servers in an on-premises data center in the same region
Function Compute	Function Compute	You must activate the Function Compute service. The function must be in the same region as the ALB instance.	Add Function Compute as a backend service for an ALB instance

Important

If a backend server of an ALB instance is released or its private IP address is changed, ALB does not automatically update the backend server. We recommend that you first remove the backend server from the ALB server group before you release it or change its private IP address to prevent service disruptions.

Backend protocol and scheduling algorithm

Backend protocol	Use cases
HTTP (default)	Most web application scenarios. Suitable for HTTP, HTTPS, and QUIC listeners.
HTTPS	Scenarios that require encrypted communication between an ALB instance and its backend servers. Suitable for HTTPS and HTTP listeners.
gRPC	Backend services that use the gRPC protocol. This 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. Round-robin scheduling is performed on a per-request, not per-user, basis.
weighted least connections	Scenarios with long-lived connections or significant variations in request processing time. Considers both weight and the number of active connections, and prioritizes servers with a lower load.
consistent hash	Scenarios that require request affinity, such as for optimizing cache hit rates. Routes requests with the same characteristics to the same backend server based on a hash of the source IP or a URL parameter.

For details about algorithm logic, see Load balancing scheduling algorithms.

The following table describes the compatibility between listener protocols, backend protocols, and health check protocols.

Listener protocol	Backend protocols	Server group types	Health check protocols
HTTP	HTTP, HTTPS	Server, IP, and Function Compute You do not need to configure the backend protocol or health check protocol for Function Compute server groups.	HTTP, HTTPS, TCP, and gRPC Basic ALB instances do not support the HTTPS health check protocol.
HTTPS	HTTP, HTTPS, and gRPC gRPC requires an HTTPS listener with HTTP/2 enabled. HTTPS listeners for Basic ALB instances only support HTTP and gRPC backend protocols.
QUIC	HTTP

Create and delete server groups

Create 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 instances, ENIs, or ECI instances as backend servers. The backend servers 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 data centers.
  - Function Compute: Uses Function Compute as a backend service. You must activate the Function Compute service, and the function must be 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.
  For a server group of the IP type, if you enable remote IP, 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 protocol for communication between the ALB instance and backend servers.
  - HTTP (default): Suitable for HTTP, HTTPS, and QUIC listeners. The ALB instance uses HTTP to communicate with backend servers.
  - HTTPS: Suitable for HTTPS and HTTP listeners. The ALB instance uses HTTPS for encrypted communication with backend servers.
  - gRPC: Suitable for HTTPS listeners. The ALB instance uses the gRPC protocol to communicate with backend servers.
  For Basic ALB instances, HTTPS listeners support only 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 the number of active connections. Among servers with the same weight, the server 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.
      For Specified URL, enter the name of a query parameter from the request URL, such as userid or sessionid. ALB hashes the value of this parameter to route requests with the same parameter value to the same backend server.
      For example, if you set Specified URL to userid, requests that contain ?userid=123 are always routed to the same backend server. This method is useful for scenarios that require session persistence, such as binding shopping cart sessions or optimizing cache hit rates.
      We recommend that you add two or more backend servers to the server group to maximize the effectiveness of hash-based distribution.
  You do not need to configure this parameter for Function Compute 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. The default resource group is used by default.
- Backend Persistent Connection: Enabled by default. When enabled, ALB maintains persistent TCP connections with backend servers. New requests reuse existing connections when possible, which reduces latency and lowers the load on backend servers.
  You do not need to configure this parameter for Function Compute server groups.
- Health Check: Enabled by default. Detects the availability of backend servers.
  Health checks are disabled by default for Function Compute 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 health check templates that are not associated with server groups or listeners for future use.
    A server group supports only one health check.

Delete 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 server group that you want to delete. In the Actions column, click the icon, select Delete, and then click OK.

API

Call the CreateServerGroup operation to create a server group.
Call the DeleteServerGroup operation to delete a specified server group.

Add and remove backend servers

Before you add a backend server, make sure that your application is deployed on the server.

Important

Ensure your backend servers do not block these addresses with security group rules, 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 IP addresses on the instance details page.
- Non-upgraded ALB instances use the 100.64.0.0/10 CIDR block to communicate with backend servers.
Make sure that the backend server configuration does not create a forwarding path that results in a loop.

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
  1. Set Server Type to ECS/ENI and turn on the Advanced Mode switch.
  2. Click the icon to the left of the target ECS instance ID and select the target ENI.
  To add an ENI, make sure that it is 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 service port on the backend server.
- Weight: The proportion of traffic distributed to the server. Valid values: 0 to 100. Default value: 100.
  For example, if a server group contains three servers that have weights of 100, 50, and 50, requests are distributed in a 2:1:1 ratio. The server with a weight of 100 receives 50% of the requests, and the other two servers each receive 25% of the requests.
  Note
  If session persistence is enabled, request distribution among backend servers may be uneven.
  If the weight of a server is set to 0, the server 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 Set Same Port, Set Same Weight, or Remove Backend Servers at the bottom of the list.
- Hover over the right side of a port or weight input box, and select Replicate to Below, Replicate to Above, or Replicate to All to quickly apply the current value to other servers.
- Click Reset to the right of the Port or Weight column header to clear all server ports or restore all weights to their default values.

Function Compute type

Both Function Compute 2.0 and 3.0 are supported. ALB communicates with Function Compute securely over the Alibaba Cloud internal network.

You must activate the Function Compute service before use. Alibaba Cloud accounts that are registered after August 27, 2024 and have completed identity verification can use the service directly without activation.

Limits

Regions that support adding Function Compute functions as backend servers.
The ALB instance and the function must be in the same region.
A server group of the Function Compute type can contain only one function.
For Function Compute 2.0, if Handler Type is set to Event Handler, 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 an existing function. If no functions are available, click Create Function. For more information, see Create a function.
  - Version or Alias: Select Specified Version or Specified Alias. By default, a newly created function has only the LATEST version.
- Configure by ARN
  - ARN: Enter the Alibaba Cloud Resource Name (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 disabled, you can add only IP addresses from the current VPC CIDR block. If remote IP is enabled, you can also add IP addresses from other VPCs or an on-premises data center.

Note

Starting from 00:00:00, February 25, 2025 (UTC+8), newly created instances will use the upgraded ALB version by default. Existing ALB instances are not affected, except for instances created through self-service applications. For more information, see Notice on the Upgrade of Application Load Balancer (ALB) Instances.

Limits

Warning

Non-upgraded ALB instances do not support adding ALB, Network Load Balancer (NLB), or Classic Load Balancer (CLB) instances from the same VPC to a server group of the IP type. If you need to add these resources from the same VPC, make sure that you are using an upgraded ALB instance to avoid potential service issues.

Upgraded

Backend server limits

Only private IP addresses are supported. Public IP addresses are not supported.
If you set IP Version to IPv4/IPv6 dual-stack, you can add only IPv6 addresses from the server group's VPC CIDR block. You cannot enable remote IP.

Forwarding configuration limits between ALB and backend servers

If you use an Enterprise Edition transit router, it creates an elastic network interface (ENI) on a vSwitch in your specified availability zone. This ENI acts as the traffic ingress from the VPC to the transit router. When you create a VPC, make sure that you create at least one vSwitch in the specified availability zone to connect the VPC to the transit router. For more information, see How transit routers work.
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.

Non-upgraded

Backend server limits

Regions that support adding remote IPs for non-upgraded ALB instances.
Cross-region backend servers are supported only for server groups of the IP type.
Only private IP addresses are supported. Public IP addresses are not supported.
You cannot add ALB, NLB, or CLB instances from the same VPC.

Forwarding configuration limits between ALB and backend servers

You can use an Enterprise Edition transit router or Express Connect for remote IP forwarding. Basic Edition transit routers are not supported.
If you use an Enterprise Edition transit router, it creates an elastic network interface (ENI) on a vSwitch in your specified availability zone. This ENI acts as the traffic ingress from the VPC to the transit router. When you create your VPC, make sure that you create at least one vSwitch in a supported availability zone to connect the VPC to the transit router. For more information, see Regions and zones that support Enterprise Edition transit routers.
Within a Cloud Enterprise Network (CEN) instance, only one VPC per region can contain one or more ALB instances that use cross-region backend servers.
- 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 enter only 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. Valid values: 0 to 100. Default value: 100.
  For example, if a server group contains three servers that have weights of 100, 50, and 50, requests are distributed in a 2:1:1 ratio. The server with a weight of 100 receives 50% of the requests, and the other two servers each receive 25% of the requests.
  Note
  - If session persistence is enabled, request distribution among backend servers may be uneven.
  - If the weight of a server is set to 0, the server 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 Set Same Port, Set Same Weight, or Remove Backend Servers at the bottom of the list.
- Hover over the right side of a port or weight input box, and select Replicate to Below, Replicate to Above, or Replicate to All to quickly apply the current value to other servers.
- Click Reset to the right of the Port or Weight column header to clear all server ports or restore all weights to their default values.

Remove backend servers

A removed server no longer handles forwarded requests.

Warning

Removing a server directly may cause service interruptions. We recommend that you set the weight of the server to 0 before you remove 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 backend server that you want to remove. In the Actions column, click Remove and then click OK.

API

Call the AddServersToServerGroup operation to add backend servers to a server group.
Call the RemoveServersFromServerGroup operation to remove backend servers from a server group.

Session persistence

Enable session persistence if multiple requests from the same client must be handled by the same backend server, such as for shopping cart or login state scenarios.

Session Persistence: Disabled by default. When enabled, ALB routes requests from the same client to the same backend server.

You do not need to configure this parameter for Function Compute server groups.

Session persistence is supported only for Server type and IP type server groups. Session persistence is not supported when cross-zone load balancing is disabled.

Console

When creating or editing a server group, enable session persistence and select a cookie handling method:

Cookie Option:
- Insert Cookie: ALB generates a cookie named SERVERID and adds it to the response. Requests that contain this cookie are forwarded to the same backend server. The Session Persistence Timeout Period ranges from 1 to 86,400 seconds.
- Rewrite Cookie: ALB rewrites the value of a user-defined cookie. You must specify the Cookie name.

API

When you call CreateServerGroup or UpdateServerGroupAttribute, use StickySessionConfig to configure session persistence.

For more information, see Configure session persistence.

Graceful server startup and shutdown

Slow start

A newly added backend server may not be able to immediately handle a full traffic load due to factors such as an unwarmed cache or unestablished connection pools. By enabling slow start, an ALB instance gradually increases the number of requests sent to the new server over a specified period. This prevents traffic spikes from overwhelming a server that is not fully ready.

This feature is supported only when the scheduling algorithm is set to 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 server groups of the Function Compute type.

Console

When creating or editing a server group, enable Slow Start. Set the Slow Start Duration to a value from 30 to 900 seconds. The default is 30 seconds. Normal traffic distribution resumes after the duration expires.

API

When you call CreateServerGroup or UpdateServerGroupAttribute, use the SlowStartConfig parameter to configure slow start.

Note

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 also does not enter slow start mode. A new backend server enters slow start mode only when added to a server group that has at least one healthy backend server not in slow start mode.
If a backend server in slow start mode is removed, it exits slow start mode. If the same backend server is added again, it re-enters slow start mode after it passes the health check.
A backend server in slow start mode exits slow start mode if its health check fails. It re-enters slow start mode after its health check status returns to normal.
When health checks are enabled, slow start takes effect after a backend server passes its health check. When health checks are disabled, slow start takes effect immediately.

For more information, see Configure slow start.

Connection draining

When a backend server is removed or fails a health check, existing connections are, by default, terminated only when the client actively disconnects or the session expires. Connection draining allows these connections to finish processing within a specified timeout before they are terminated, ensuring a graceful shutdown.

This feature is 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 Function Compute server groups.

Console

When you create or edit a server group, enable Connection Draining and set the Timeout Period. The timeout period can be from 0 to 900 seconds. A value of 0 means connections are immediately interrupted. The default is 300 seconds.

API

When calling CreateServerGroup or UpdateServerGroupAttribute, use ConnectionDrainConfig to configure connection draining.

For more information, see Configure connection draining.

Reduce cross-zone latency

By default, an ALB instance distributes traffic across backend servers in different availability zones within the same region. If your business is latency-sensitive and has sufficient backend server resources in each availability zone, you can disable cross-zone load balancing. This ensures that traffic is distributed only among backend servers within the same availability zone, which reduces cross-zone network latency.

You can disable this feature only for Standard and WAF-enabled ALB instances. Basic ALB instances do not support this feature.

For IP-based server groups with remote IP enabled, you cannot disable cross-zone load balancing.

Session persistence is not supported when cross-AZ load balancing is disabled.

You do not need to configure this parameter for server groups of the Function Compute type.

Console

When creating or editing a server group, turn off Cross-zone Load Balancing.

API

When calling CreateServerGroup or UpdateServerGroupAttribute, set CrossZoneEnabled to false to disable cross-zone load balancing (the default is true).

For more information, see Disable cross-AZ load balancing.

Add IPv6 backend servers

If you need to add IPv6 backend servers to a server group, set IP Version to IPv4/IPv6 dual-stack.

This feature is supported only for server groups of the Server and IP Address types.
The VPC to which the server group belongs must have IPv6 enabled.
You can add a server group with an IP Version of IPv4/IPv6 dual-stack only to the forwarding rules of a dual-stack ALB instance.
For an IP type server group, the ALB instance must be an upgraded instance. In this configuration, only IPv6 addresses from the current VPC are supported, and you cannot enable remote IP.

Console

When you create a server group, set IP Version to IPv4/IPv6 dual-stack.

API

When you call the CreateServerGroup operation, set Ipv6Enabled to true. This is equivalent to setting IP Version to IPv4/IPv6 dual-stack.

Edit health check settings

Modify the health check configuration of a server group.

Warning

If you disable health checks, ALB cannot detect backend server failures and will not automatically route traffic to healthy servers.
A longer health check interval increases the time it takes for ALB 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 enabled, click Modify to the right of Health Check Settings to change the parameters.

API

Call the UpdateServerGroupAttribute operation 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 added to the server group based on their respective billing rules.

Quotas

Quota name	Description	Default value	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	Yes
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 associated	50	100
alb_quota_server_groups_weight	Maximum weight of a single server group in a forwarding rule	100	10,000	Contact your business manager