Server Load Balancer:Create and manage server groups

Create a server group

1. Log on to the ALB console.

2. In the top navigation bar, select the region where you want to create a server group.

3. In the left-side navigation pane, choose ALB > Server Groups.

4. On the Server Groups page, click Create Server Group.

5. In the Create Server Group dialog box, configure the parameters and click Create. The following table describes the parameters.

Parameter	Description
Server Group Type	Specify how backend servers are added to a server group. Valid values: Server: Backend servers are added by specifying ECS instances, elastic network interfaces (ENIs), and Elastic Container Instances. IP: Backend servers are added by specifying IP addresses. Function Compute: Backend servers are added by specifying functions.
Server Group Name	The custom name of the server group.
VPC	Select a VPC from the VPC drop-down list. Only servers in the VPC can be added to the server group. Note This parameter is unavailable for server groups of the Function Compute type.
Backend Server Protocol	Select a backend protocol. Valid values: HTTP: This is the default value. If you select this option, you can associate the server group with HTTPS, HTTP, and QUIC listeners. HTTPS: If you select this option, you can associate the server group with HTTPS listeners. gRPC: If you select this option, you can associate the server group with HTTPS listeners. Note You can associate only server groups that use HTTPS or gRPC with HTTPS listeners of basic ALB instances. This parameter is unavailable for server groups of the Function Compute type.
Scheduling Algorithm	Select a scheduling algorithm. Valid values: Weighted Round-robin: Backend servers that have higher weights receive more requests than those that have lower weights. Weighted Least Connections: Requests are distributed based on the weights and number of connections to backend servers. If two backend servers have the same weight, requests are forwarded to the backend server that has fewer connections. Consistent Hash: Requests from the same source IP address are forwarded to the same backend server. Hash Factor: Select a hash factor. Source IP: Requests from the same source IP address are forwarded to the same backend server. URL Parameters: Requests for the same URL are forwarded to the same backend server. If you select this operation, configure the Specified URL parameter. Note This parameter is unavailable for server groups of the Function Compute type.
Tags and Resource Group	Specify tags and a resource group as needed. To add a tag, specify Tag Key and Tag Value. Resource Group: select a resource group to which you want the server group to belong.
IPv6	Specify whether to enable IPv6. IPv6 is disabled by default. If you enable IPv6, you can add IPv4 and IPv6 backend servers to the server group. If you disable IPv6, you can add only IPv4 backend servers to the server group. Note Server groups of the Server or IP type support this parameter while those of the Function Compute type do not. Only when IPv6 is enabled for the VPC where the server group is deployed, this parameter is available. A server group with IPv6 enabled can be associated with listeners and forwarding rules of only dual-stack ALB instances. For an IP-type server group with IPv6 enabled: It can be associated with listeners and forwarding rules of only upgraded dual-stack ALB instances, but not with non-upgraded ALB instances. Only IPv6 addresses in the CIDR block of the VPC where the server group is deployed can be added to the server group as backend servers. Remote IP addresses are not supported.
Session Persistence	Specify whether to enable session persistence. Session persistence is disabled by default. If session persistence is enabled, ALB forwards all requests from a client to the same backend server. Cookie Option: Select a method to handle cookies. Insert Cookie: ALB inserts a session cookie (SERVERID) into the first HTTP or HTTPS response that is sent to a client. If subsequent requests to ALB carry this cookie, ALB determines the destination servers of the requests based on the cookie. Rewrite Cookie: If ALB detects a user-defined cookie, ALB replaces the original cookie with the user-defined cookie. If subsequent requests to ALB carry this user-defined cookie, ALB determines the destination servers of the requests based on the cookie. Session Persistence Timeout Period: Specify the timeout period of session persistence. Valid values: 1 to 86400. Unit: seconds. Note This parameter is unavailable for server groups of the Function Compute type.
Cross-zone Load Balancing	Specify whether to enable cross-zone load balancing. Cross-zone load balancing is enabled by default. ALB distributes requests to backend services deployed in all zones within the same region. If cross-zone load balancing is disabled, ALB distributes requests to backend services deployed in a single zone. Note A server group with cross-zone load balancing disabled can be associated only with standard and WAF-enabled ALB instances. It cannot be associated with basic ALB instances. If cross-zone load balancing is disabled, Session Persistence cannot be enabled. For server groups of the IP type, if Remote IP is enabled, cross-zone load balancing cannot be disabled. This parameter is unavailable for server groups of the Function Compute type.
Backend Persistent Connection	Specify whether to enable the backend persistent connection feature. By default, this feature is enabled. If the backend persistent connection is enabled, a specific number of TCP connections are kept alive between ALB and the backend servers. When the ALB instance receives a new request and an idle persistent TCP connection exists, ALB preferentially uses the TCP connection to forward the request to the backend servers. This reduces the number of TCP handshakes and the loads of the backend servers. Note This parameter is unavailable for server groups of the Function Compute type.
Slow Start	Enable the slow start mode based on your business requirements. The slow start mode is disabled by default. To enable the slow start mode, configure the Slow Start Duration parameter. Valid values: 30 to 900. Default value: 30. Unit: seconds. After you enable the slow start mode, ALB gradually increases the number of requests forwarded to scaled out backend servers to prevent traffic spikes in scenarios such as resource preparation, caching, and prefetching. After the slow start duration ends, ALB forwards requests to backend servers based on their weights. Backend servers that are scaled out after the slow start duration ends do not enter the slow start mode. Note Only standard and WAF-enabled ALB instances support the slow start mode. Basic ALB instances do not support the slow start mode. This parameter is unavailable for server groups of the Function Compute type. The slow start mode is supported by server groups only if you set Scheduling Algorithm to Weighted Round-robin. After you enable the slow start mode, healthy backend servers do not automatically enter the slow start mode. When you enable the slow start mode for an empty server group: The first backend server added to the server group does not enter the slow start mode. New backend servers can enter the slow start mode only when at least one healthy backend server is in slow start mode. Backend servers that are removed before the slow start duration ends automatically exit the slow start mode. If you re-add a backend server to a server group, the backend server can enter the slow start mode only when the backend server passes health checks. If a backend server is declared unhealthy before the slow start duration ends, the backend server exits the slow start mode. The backend server re-enters the slow start mode when the backend server passes health checks. After you enable the slow start mode and health checks, only healthy backend servers enter the slow start mode. If you disable health checks, all backend servers immediately enter the slow start mode.
Connection Draining	Specify whether to enable connection draining. By default, connection draining is disabled. To enable connection draining, configure the Timeout Period parameter. Valid values: 0 to 900. Default value: 300. Unit: seconds. A value of 0 specifies immediate disconnection. When you remove a backend server or a backend server is declared unhealthy: By default, connection draining is disabled. Existing connections remain open until the clients proactively close the connections or the session persistence duration ends. After you enable connection draining, existing connections remain open for data transmission until the connection draining timeout period ends. Connection draining ensures smooth undeployment of services. Note Only standard and WAF-enabled ALB instances support connection draining. Basic ALB instances do not support connection draining. This parameter is unavailable for server groups of the Function Compute type.
Health Check	Specify whether to enable health checks.
Health Check Settings	If you enable health checks, you can click Modify on the right side of Health Check Settings to show more health check settings.
Select and Load Health Check	Select and load a health check. Note When you create a health check, you do not need to specify a server group or a listener. You can associate the health check with a server group or a listener after the health check is created. You can configure only one health check for each backend server.
Health Check Protocol	Select a protocol for health checks. For more information about the limits on HTTPS health checks, see . HTTP: To perform HTTP health checks, ALB sends HEAD or GET requests to a backend server to check whether the backend server is healthy. HTTPS: ALB performs HTTPS health checks by sending HEAD or GET requests to a backend server to check whether the backend server is healthy. For more information, see the Limits on HTTPS health checks section of this topic. TCP: ALB performs TCP health checks by sending SYN packets to a backend server to check whether the port of the backend server is available to receive requests. gRPC: ALB performs gRPC health checks by sending POST or GET requests to a backend server to check whether the backend server is healthy.
Health Check Method	Specify a health check method. Valid values: HEAD: By default, HTTP health checks use the HEAD method. Make sure that your backend servers support HEAD requests. If your backend servers do not support the HEAD method or the HEAD method is disabled, the health check may fail. In this case, you can use the GET method. POST: By default, gRPC health checks use the POST method. Make sure that your backend servers support POST requests. If your backend server does not support the POST method or the POST method is disabled, the health check may fail. In this case, you can use the GET method. GET: If the size of a response exceeds 8 KB, the response is truncated. The results of the health check are not affected. Note This parameter takes effect only if you set the Health Check Protocol parameter to HTTP, HTTPS, or gRPC. HTTP and HTTPS health checks support the HEAD and GET health check methods. gRPC health checks support the POST and GET health check methods.
Health Check Protocol Version	Select an HTTP version. Valid values: HTTP1.0 and HTTP1.1. Note This parameter takes effect only if HTTP or HTTPS is specified as the health check protocol.
Health Check Port	Specify the ports on which you want to perform health checks. Backend Server Port: ALB uses the ports of backend servers to perform health checks. This is the default value. Custom Port: ALB uses a specified port to perform health checks. Valid values: 1 to 65535.
Health Check Path	Enter the URL of the health check page. The URL must be 1 to 80 characters in length, and can contain letters, digits, hyphens (-), forward slashes (/), periods (.), percent signs (%), question marks (?), number signs (#), and ampersands (&). The URL can also contain the following extended characters: _ ; ~ ! ( ) * [ ] @ $ ^ : ' , +. The URL must start with a forward slash (/).
Health Check Domain Name	Enter the domain name that is used for health checks. Backend Server Internal IP: The private IP addresses of backend servers are used for health checks. This is the default value. Custom Domain Name: Enter a domain name. The domain name must be 1 to 80 characters in length, and can contain only lowercase letters, digits, periods (.), and hyphens (-). The domain name must contain at least one period (.), but cannot start or end with a period (.).
Health Check Status Codes	Select one or more HTTP status codes. The specified HTTP status codes are used to indicate that a backend server passes a health check. If the health check protocol is set to HTTP or HTTPS, you can select http_2xx, http_3xx, http_4xx, and http_5xx. http_2xx and http_3xx are selected by default. If you set the Health Check Protocol parameter to gRPC, the valid values are 0 to 99. Value ranges are supported. You can enter up to 20 value ranges. Separate multiple value ranges with commas (,). Note This parameter takes effect only if HTTP, HTTPS, or gRPC is specified as the health check protocol.
Response Timeout Period	Specify the timeout period of a health check response. If a backend server does not respond within the specified timeout period, the server fails the health check.
Health Check Interval	Specify the interval between two consecutive health checks.
Healthy Threshold	Specify the number of times that an unhealthy backend server must consecutively pass health checks before it is declared healthy.
Unhealthy Threshold	Specify the number of times that a healthy backend server must consecutively fail health checks before it is declared unhealthy.
Save the health check configurations as a template, which can facilitate health check creation and configurations	You can select the check box to save the health check template. If you select this option, you must enter a name for the template. Note This parameter takes effect only if you set the Select and Load Health Check parameter to Custom Health Check.

Add backend servers

After you create a server group, you must add one or more backend servers to the server group. This way, the specified backend servers can receive requests distributed by ALB.

Add backend servers of the Server type

If you set the server group type to Server, you must add backend servers by specifying ECS instances, ENIs, or elastic container instances.

1. Log on to the ALB console.

2. In the left-side navigation pane, choose ALB > Server Groups.

3. On the Server Groups page, find the server group that you want to manage and click Modify Backend Server in the Actions column.

4. On the Backend Servers tab, click Add Backend Server.

5. In the Add Backend Server panel, select a type of cloud service and click Next.

   • ECS instances

     Select ECS/ENI for Server Type and then select the ECS instances that you want to add.

     If no ECS instance is available, click Buy ECS in the upper-right corner of the instance list.

   • ENIs

     1. Select ECS/ENI for Server Type and turn on Advanced Mode.

     2. Click the icon next to the ID of an ECS instance and select an ENI.

        • Make sure that the ENI is associated with the ECS instance. For more information about how to associate a secondary ENI with an ECS instance, see Bind a secondary ENI.

        • If no ECS instance is available, click Purchase ECS Instance in the upper-right corner of the instance list.

   • Elastic container instances

     Select ECI for Server Type and select an elastic container instance.

     If no elastic container instance is available, click Purchase Elastic Container Instance in the upper-right corner of the instance list.

6. In the Ports/Weights step, specify the ports and weights of the backend servers and click OK.

   • Port: Specify the port of a backend server that provides services,

   • Weight: The weights of backend servers refer to the proportion of traffic distributed to each of them. The default weight is 100. A server with a higher weight receives more requests.

     For example, if a server group has three backend servers with weights of 100, 50, and 50, respectively, requests are distributed to the servers in a 2:1:1 proportion. The server with a weight of 100 receives 50% of the requests, while the other two servers each receive 25%.

     Note

     • If session persistence is enabled for a server group, requests may not be evenly distributed among its backend servers.

     • A server with a weight of 0 receives no requests.

     • If a server group has only one backend server, and its weight is not 0, all requests forwarded to the server group go to that backend server.

     • If a server group has more than one backend server, traffic is distributed based on their weights, following these principles:

       • When the health check result of one of the backend servers is unhealthy, requests are not forwarded to that server. ALB distributes traffic to all healthy servers based on their weights. When the backend server recovers, it fails back for traffic processing.

       • If all servers are declared unhealthy, ALB continues to distribute traffic based on the weights of all servers despite of their unhealthy state. This is to minimize business losses as much as possible.

   You can batch change the weights or ports of multiple servers by moving the pointer over the icon.

   • If you click Replicate to Below, the weights of all servers listed below the current server are set to the same weight as the current server.

   • If you click Replicate to Above, the weights of all servers listed above the current server are set to the same weight as the current server.

   • If you click Replicate to All, the weights of all servers in the server group are set to the same weight as the current server.

   • Reset:

     • If you click Reset next to Port, the ports of all servers in the server group are cleared.

     • If you click Reset next to Weight, the weights of all servers in the server group are reset to the default value.

Remove a backend server

1. Log on to the ALB console.

2. In the left-side navigation pane, choose ALB > Server Groups.

3. On the Server Groups page, find the server group that you want to manage and click its ID.

4. Click the Backend Servers tab, find the backend server that you want to remove, and then click Remove in the Actions column.

5. In the message that appears, click OK.

Modify health checks

You can modify the health check configurations of a server group based on your business requirements.

1. Log on to the ALB console.

2. In the left-side navigation pane, choose ALB > Server Groups.

3. On the Server Groups page, find the server group that you want to manage and click Modify Health Check in the Actions column.

4. In the Modify Health Check dialog box, turn on or off Health Check. You can also click Modify next to Health Check Settings to modify the health check parameters.

   Warning

   • After health checks are disabled, ALB no longer checks the health status of the backend servers. If a backend server is down, network traffic cannot be automatically switched to healthy backend servers.

   • If you specify a longer health check interval, more time is required for ALB to detect unhealthy backend servers.

Delete a server group

If a server group is not specified in the forwarding rules used by listeners, you can delete the server group. For more information about how to delete a forwarding rule, see Delete a forwarding rule.

After you delete a server group, the backend servers in the server group are not affected. If you no longer use an ECS instance, you can stop or release the ECS instance. For more information, see Stop an instance or Release an instance.

1. Log on to the ALB console.

2. In the left-side navigation pane, choose ALB > Server Groups.

3. On the Server Groups page, find the server group that you want to delete and choose > Delete in the Actions column.

4. In the message that appears, click OK.

References

• CreateServerGroup: creates a server group for ALB instances.

• AddServersToServerGroup: adds backend servers to a server group.

• UpdateServerGroupAttribute: updates the configurations of a server group, including the health check, session persistence, name, scheduling algorithm, and protocol configurations.

• UpdateServerGroupServersAttribute: updates the weights and descriptions of backend servers in a server group.

• ReplaceServersInServerGroup: replaces backend servers in a server group.

• RemoveServersFromServerGroup: removes backend servers from a server group.

• DeleteServerGroup: deletes a server group.