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. 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.
|
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. |
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. You can set the Server Group Type parameter only to Server. If you disable IPv6, you can add only IPv4 backend servers to the server group. You can set the Server Group Type parameter to Server, IP, or Function Compute.
Note If IPv6 is disabled for the VPC of the server group, you cannot enable IPv6. This parameter is unavailable for server groups of the IP and Function Compute types. When you create a listener for an IPv4 ALB instance, you cannot add server groups for which IPv6 is enabled.
|
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. 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.
|
Resource Group | Select the resource group to which the ALB instance belongs. |
Tags | Configure the Tag Key and Tag Value parameters. |
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. |