Create and manage server groups-Server Load Balancer(SLB)-阿里云帮助中心

Configuration planning

Before creating a server group, plan its key configurations based on your business requirements. You cannot change the server group type after creation, so select a type that matches your backend service deployment.

Select a server group type

Server group type	Backend service types	Description	References
Server	ECS, ENI, and ECI instances	The backend servers must be in the same VPC as the server group.	Quickly implement IPv4 load balancing using ALB Quickly implement IPv6 load balancing using ALB
IP	IP addresses	Remote IP enabled: Use this option when the backend servers are outside the server group's VPC, such as IP addresses in another VPC or an on-premises data center. 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 CIDR block of the server group's VPC are supported.	Attach servers in a cross-region VPC using ALB Attach on-premises servers in the same region using ALB
Function Compute	Function Compute	You must activate Function Compute in the same region as the ALB instance.	Use Function Compute as a backend service for an ALB instance

Important

If you release a backend server in an ALB server group or change its private IP address, ALB does not automatically update the server's status. To prevent service disruptions, remove the backend server from the ALB server group before you release it or change its IP address.

Backend protocol and scheduling algorithm

Backend protocol	Use cases
HTTP (Default)	Ideal for most web applications. This protocol is compatible with HTTP, HTTPS, and QUIC listeners.
HTTPS	Encrypts communication between ALB and backend servers. This protocol is compatible with HTTPS and HTTP listeners.
gRPC	Required for backend services that use gRPC. This protocol requires an HTTPS listener with HTTP/2 enabled.

Scheduling algorithm	Use cases
Weighted round-robin	Ideal for general-purpose use cases. Requests are distributed to backend servers according to their assigned weights. This algorithm distributes requests on a per-request basis, not on a per-user basis.
Weighted least connections	Ideal for persistent connections or requests with varying processing times. This algorithm considers both weights and active connections, and routes requests to the server with the lightest load.
Consistent hash	Ideal for use cases that require request affinity. This algorithm consistently routes requests with the same characteristic (such as a source IP or a URL) to the same backend server.

For details on how these algorithms work, see Introduction to load balancing scheduling algorithms.

The following table describes the compatibility among 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 Function Compute server groups do not require backend protocol or health check protocol configuration.	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. For Basic ALB instances, HTTPS listeners support only HTTP and gRPC backend protocols.
QUIC	HTTP

Create and delete server groups

Create group

Navigate 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: Add ECS, ENI, or ECI instances as backend servers. The instances must be in the same VPC as the server group.
  - IP Address: Add IP addresses as backend servers. This type 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: Add Function Compute functions as backend services. Function Compute must be activated, and the functions must be in the same region as the ALB instance.
- Server Group Name: Enter a name for the server group.
- VPC: The VPC that contains the server group. You can add only backend servers from this VPC to this server group.
  
  If you enable remote IP for an IP server group, backend servers are not limited to this VPC but must be reachable from the VPC.
  
  You do not need to configure this parameter for Function Compute server groups.
- Backend Server Protocol: Select the protocol that ALB uses to communicate with backend servers.
  - HTTP (Default): Suitable for HTTP, HTTPS, and QUIC listeners. ALB uses HTTP to communicate with backend servers.
  - HTTPS: Suitable for HTTPS and HTTP listeners. ALB uses HTTPS to encrypt communication with backend servers.
  - gRPC: Suitable for HTTPS listeners. ALB uses gRPC to communicate with backend servers.
  HTTPS listeners of 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 weights. 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 active 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 requests 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 in the request URL, such as userid or sessionid. ALB performs a hash calculation based on the value of the parameter and dispatches requests that have the same parameter value to the same backend server.
      
      For example, if you enter userid for Specified URL, requests that contain ?userid=123 in the URL are always scheduled to the same backend server. This method is suitable for scenarios that require session persistence, such as shopping cart session binding or cache hit rate optimization.
      
      We recommend adding 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. For categorizing and managing server groups.
  - Tag Key and Tag Value: Tag the server group with a key-value pair.
  - Resource Group: The resource group that contains the server group. Default: default resource group.
- Backend Persistent Connection: Enabled by default. When enabled, ALB maintains persistent TCP connections with backend servers. New requests reuse existing connections to reduce latency and 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 count as Function Compute requests and incur fees.
  - Health Check Settings: Click Modify on the right to expand the settings. For parameter descriptions, see ALB health checks.
  - Select and Load Health Check: Select an existing health check template to load its configurations.
    
    You can create health checks that are not associated with server groups or listeners for later reuse.
    
    Each server group supports only one health check.

Delete 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. Find the server group to delete, and in the Actions column, choose > Delete. Then, click OK.

API

Call CreateServerGroup to create a server group.
Call DeleteServerGroup to delete a server group.

Add and remove backend servers

Before you add a backend server, ensure that business applications are deployed on the server.

Important

ALB uses specific IP addresses for communication and 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 from the CIDR block of their vSwitches 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.
Ensure that the backend server configuration does not create a forwarding path that results in a loop.

Add backend servers

Server type

In the ALB console, go to the Server Groups page, 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 enable Advanced Mode.
  2. Click the icon to the left of the target ECS instance ID and select the target ENI.
  Before you add an ENI, ensure 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 click OK.
- Port: The service port of 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 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%.
  Note
  
  If 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 you can use it. This requirement does not apply to Alibaba Cloud accounts that are registered and have completed identity verification after 00:00:00 on August 27, 2024 (UTC+8).

Limitations

Regions that support adding Function Compute functions as backend servers.
The ALB instance and the function must be in the same region.
A Function Compute server group can contain 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.

In the ALB console, go to the Server Groups page, 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 click OK.
- Service
  - Function Name: Select an existing 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.
- By Configuring 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 add only 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 data centers.

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.

Limitations

Warning

Non-upgraded ALB instances do not support adding ALB, NLB, or CLB instances from the same VPC to an IP-type server group. To add these resources from the same VPC, you must use an upgraded ALB instance to prevent service issues.

Upgraded instances

Backend server limitations

Only private IP addresses are supported.
If you enable IPv6, you can add only IPv6 addresses from the server group's VPC CIDR block. The remote IP feature is not supported.

Forwarding configuration limitations

An Enterprise Edition transit router creates an ENI on a vSwitch in your specified zone, which serves as the traffic ingress from the VPC to the transit router. Therefore, you must create at least one vSwitch in that 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 VPC route tables 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 supported only for IP-type server groups.
Only private IP addresses are 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, ensure that you create at least one vSwitch in a supported zone to connect the VPC to the transit router. For more information, see Supported regions and zones for Enterprise Edition transit routers.
Within a single CEN instance, only one VPC in each region can contain 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 VPC route tables are not supported.

In the ALB console, go to the Server Groups page, 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 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 add 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 click OK.
- Port: The service port of 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 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%.
  Note
  - If 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.

Warning

To prevent service interruptions, we recommend setting the weight of the server to 0 before you remove it.

In the ALB console, go to the Server Groups page, find the target server group, and click Modify Backend Server in the Actions column.
On the Backend Servers tab, find the target backend server. In the Actions column, click Remove and 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 to route requests from the same client to the same backend server, such as for shopping carts or login sessions.

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

This parameter is not required for Function Compute server groups.

This feature applies only to server type and IP type server groups. Session persistence requires cross-zone load balancing to be enabled.

Console

When you create or edit a server group, enable session persistence and then choose a cookie option:

Cookie Option:
- Insert Cookie: 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 value for Session Persistence Timeout Period must be between 1 and 86,400 seconds.
- Rewrite Cookie: ALB rewrites the value of a user-defined cookie. Enter the Cookie name.

API

To configure session persistence, set the StickySessionConfig parameter in your CreateServerGroup or UpdateServerGroupAttribute API call.

For more information, see Configure session persistence.

Graceful backend server registration and deregistration

Slow start

A newly added backend server may not be able to immediately handle a full traffic load due to factors such as a cold cache or unestablished connection pools. When slow start is enabled, the ALB instance gradually increases the number of requests routed to the new server over a specified period. This prevents traffic spikes from overwhelming a server that is still warming up.

This feature is available only with the weighted round-robin scheduling algorithm.

Standard and WAF-enabled ALB instances support this feature, but Basic ALB instances do not.

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 a Slow Start Duration. The duration can range from 30 to 900 seconds, with a default of 30 seconds. Normal request distribution resumes after this period expires.

API

When you call CreateServerGroup or UpdateServerGroupAttribute, use SlowStartConfig 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 if the server group contains at least one healthy backend server that is not in slow start mode.
A server exits slow start mode when it is removed. If the same server is added again, it re-enters slow start mode after passing its health check.
A server exits slow start mode if it fails a health check and re-enters this mode after passing a subsequent health check.
If a health check is enabled, slow start takes effect after a backend server passes the health check. If a health check is disabled, slow start takes effect immediately.

For more information, see Configure slow start.

Connection draining

By default, when a backend server is removed or fails a health check, its connections persist until the client disconnects or the session expires. Enabling connection draining allows in-flight requests to complete within a specified timeout period before the connections are closed, which ensures graceful service deregistration.

Standard and WAF-enabled ALB instances support this feature, but Basic ALB instances do not.

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 a Timeout Period from 0 to 900 seconds. The default is 300 seconds. A value of 0 terminates connections immediately.

API

When you call 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 application is latency-sensitive and has sufficient backend server resources in each availability zone, you can disable cross-zone load balancing. This distributes traffic only among backend servers within the same availability zone, reducing 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 server groups with remote IP enabled, you cannot disable cross-zone load balancing.

You cannot use session persistence if cross-zone 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, disable Cross-zone Load Balancing.

API

When you call CreateServerGroup or UpdateServerGroupAttribute, set CrossZoneEnabled to false to disable cross-zone load balancing. The default is true.

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

Add IPv6 backend servers

Enable IPv6 for a server group to add IPv6 backend servers.

This feature is supported only for server groups of the server type and ip type.
The server group's VPC must have IPv6 enabled.
You can add an IPv6-enabled server group only to the forwarding rules of a listener on a dual-stack ALB instance.
For an ip type server group, the ALB instance must also be an upgraded instance, and the server group supports only IPv6 addresses from its VPC and does not support the remote IP feature.

Console

When you create a server group, enable IPv6.

API

To enable IPv6, call CreateServerGroup and set the Ipv6Enabled parameter to true.

Modify a health check

Modify the health check configuration of a server group.

Warning

If you disable health checks, the 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 the ALB to detect a failed server.

Console

Navigate 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 according to their respective billing rules.

Quotas

Parameter	Description	Default	Maximum value	Adjustable
alb_quota_loadbalancer_servers_num_basic_edition	The maximum number of backend servers for a Basic ALB instance.	200	400	Yes
alb_quota_loadbalancer_servers_num_standard_edition	The maximum number of backend servers for a Standard ALB instance.	1,000	1,500
alb_quota_loadbalancer_servers_num_standardwithwaf_edition	The maximum number of backend servers for a WAF-enabled ALB instance.	1,000	1,500
alb_quota_server_added_num	The maximum number of server groups on an ALB instance that a single backend server (identified by its IP address) can be added to.	200	300
alb_quota_servergroup_attached_num	The maximum number of listener forwarding rules that can use a single server group.	50	100
alb_quota_server_groups_weight	The maximum configurable weight for a server group in a forwarding rule.	100	10,000	Contact your account manager.