Application Load Balancer (ALB) distributes client requests to one or more backend servers in server groups. ALB checks the availability of backend servers by performing health checks. You must specify a server group when you add a listener to ALB. After you create a listener, the listener uses the protocol and the port that you specify to check for connection requests and forward the requests to the associated server group.
ALB server group types
For more information about how to create an ALB server group and add backend servers, see Create and manage a server group.
Server group type | Backend server type | Description | References |
Server | Allows you to specify Elastic Compute Service (ECS) instances, elastic network interfaces (ENIs), and elastic container instances as backend servers. | The backend servers and the server group must belong to the same virtual private cloud (VPC). The backend servers are used to receive requests distributed by ALB. | For more information about how to specify ECS instances as backend servers, see the following topics: |
IP | Allows you to specify IP addresses as backend servers. |
| For more information about how to add backend servers across regions, see the following topics: |
Function Compute | Allows you to specify functions of Function Compute as backend servers. | You must activate Function Compute. The functions that you want to add must belong to the same region as the ALB instance. | Specify a function from Function Compute as a backend server of ALB |
After a backend server of an ALB instance is released or after the private IP address of a backend server is modified, ALB does not update the status of the backend server. When you release or modify an ALB backend server, we recommend that you remove the backend server from the ALB server group to ensure that your business is not affected.
Scheduling algorithms
This section describes the scheduling algorithms that are supported by ALB. For more information, see SLB scheduling algorithms.
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 Parameter: Requests for the same URL are forwarded to the same backend server. If you select this operation, configure the Specified URL parameter.
Backend protocols and health check protocols
The following table describes the server groups and the health check protocols that are supported by different ALB listeners.
Listener protocol | Backend protocol of server group | Server group type | Health check protocol |
HTTP | HTTP and HTTPS | Server type, IP type, and Function Compute type Note If the backend server group type is Function Compute, you do not need to specify a backend or health check protocol. | HTTP, HTTPS, TCP, and gRPC Note Standard and Web Application Firewall (WAF)-enabled ALB instances support HTTPS health checks. Basic ALB instances do not support HTTPS health checks. |
HTTPS | HTTP, HTTPS, and gRPC Note
| ||
QUIC | HTTP |
Health checks
You can configure health checks to monitor the conditions of server groups. This helps you evaluate the availability of backend servers in server groups.
ALB allows you to configure health checks for server groups. By default, health checks are enabled for all server groups.
When health checks are enabled, ALB automatically routes requests to healthy backend servers and probes the availability of all backend servers at a specified interval. A backend server must pass health checks for a specific number of times (N times) before the backend server is declared healthy. You can specify N based on your business requirements. This prevents health check errors caused by network jitter.
If a backend server fails health checks for a specific number of times, the backend server is declared unhealthy. In this case, ALB automatically stops distributing requests to the backend server.
After the backend server recovers, ALB automatically distributes requests to the backend server.
Health checks use non-persistent connections. The connections are closed after health checks are completed.
Health checks are not performed on backend servers whose weights are 0.
If all the backend servers in a server group are unhealthy, ALB continues distributing requests to the server group based on the scheduling algorithm to prevent service interruptions. For more information, see How can an ALB instance forward requests if all the backend servers in the same backend server are unhealthy?
For more information, see Health checks.
Session persistence
By default, ALB distributes requests to different backend servers. After you enable the session persistence feature, requests from the same client are forwarded to the same backend server. This allows the backend server to maintain status information and provide continuous service to the client.
Session persistence disabled: Requests from the same client may be distributed to different backend servers of ALB. In some scenarios, such as scenarios in which you log on to a backend server to obtain interaction information, you may need to log on to the backend server multiple times.
Session persistence enabled: Requests from the same client are distributed to the same backend server of ALB. In some scenarios, such as scenarios in which you log on to a backend server to obtain interaction information, you do not need to log on to the backend server multiple times.
Server groups of the Function Compute type do not support session persistence.
For more information, see Configure session persistence.
Persistent connections on backend servers
If persistent connections are enabled, ALB maintains a certain number of connections to backend servers. Requests are preferentially distributed to idle TCP persistent connections to reduce the number of TCP handshakes. This reduces the loads on backend servers.
Server groups of the Function Compute type do not support persistent connections.
For more information, see Create a server group.
Cross-zone load balancing
By default, cross-zone load balancing is enabled for ALB instances. Incoming requests are distributed to backend services deployed in all zones within the same region. If you disable cross-zone load balancing for the backend server group associated with your ALB instance, requests are distributed to backend services deployed in a single zone.
A server group with cross-zone load balancing disabled can be associated only with standard and WAF-enabled ALB instances and 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.