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

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. Lingjun ENIs can be added.	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
DNS	Domain names	Only ALB Extensible Edition instances support this type of server group. ALB resolves the domain name and forwards requests. You must ensure network connectivity between ALB and the resolved address. Alibaba Cloud internal DNS, custom DNS servers, and PrivateZone resolution are supported.	Host a static website on OSS with ALB Extensible Edition
AI service	Large language model (LLM) services	Only ALB Extensible Edition instances support this type of server group. A server group of the AI service type supports only one AI service. ALB communicates with the LLM service by using the API key in an identity credential. You must create the identity credential in advance.	Use ALB Extensible Edition to call multiple LLM services in a unified manner AI service fallback
MCP service	MCP servers, Function Compute, and REST APIs	Only ALB Extensible Edition instances support this type of server group. Requires a service extension that includes the MCP proxy component. Supports MCP direct proxy (MCP to MCP) and protocol conversion (MCP to OpenAPI) to provide a unified backend service endpoint for agents. This is a whitelist feature. To use it, contact your account manager.	Use ALB Extensible Edition to manage MCP services
IP address range	IP address ranges and port ranges	Only ALB Extensible Edition instances support this type of server group. Requires a service extension that includes the dynamic forwarding component. You do not need to register backend servers one by one. You only configure the allowed destination IP address ranges and port ranges. ALB extracts the destination address from the request content, verifies it against these ranges, and then forwards the request.	Use ALB Extensible Edition to implement dynamic forwarding

ALB Extensible Edition is in public preview. For more information, see public preview notes.

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. Requires an HTTPS listener with HTTP/2 enabled.

ALB Extensible Edition instances do not support the gRPC backend protocol.

You do not need to select a backend protocol for AI service or MCP service server groups. IP address range server groups currently support only the HTTP backend protocol.

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 and HTTPS	Server, IP, Function Compute, DNS, AI service, MCP service, and IP address range	HTTP, HTTPS, TCP, and gRPC
HTTPS	HTTP, HTTPS, and gRPC	Server, IP, Function Compute, DNS, AI service, MCP service, and IP address range
QUIC	HTTP	Server, IP, and Function Compute

You do not need to configure the backend protocol or health check protocol for Function Compute, AI service, or MCP service types. You do not need to configure the health check protocol for the DNS or IP address range types.

HTTPS listeners of Basic ALB instances do not support the HTTPS backend protocol. Basic ALB instances do not support the HTTPS health check protocol.

ALB Extensible Edition instances do not support QUIC listeners or the gRPC backend protocol.

To use the gRPC backend protocol, you must enable HTTP/2 in the listener.

Important

The backend protocol must match the protocol that the backend server actually provides. For example, if a backend ECS instance provides HTTP services, select HTTP as the backend protocol. If the backend protocol is set to HTTPS but the backend server only provides HTTP services, the TLS handshake between the ALB instance and the backend server fails, causing requests to return 502 Bad Gateway. To resolve this issue, change the backend protocol to 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.
  - FQDN: Uses a domain name as a backend service. ALB resolves the domain name and forwards requests. Only ALB Extensible Edition instances are supported.
  - AI Service: Uses an LLM service as a backend service. Only ALB Extensible Edition instances are supported.
  - MCP Service Type: Uses MCP servers, Function Compute, or REST APIs as backend services to provide a unified MCP service endpoint for agents. Only ALB Extensible Edition instances are supported, and a service extension that includes the MCP proxy component is required.
    
    This is a whitelist feature. To use it, contact your account manager.
  - IP Address Range: Does not register specific backend servers. You only configure the allowed destination IP address ranges and port ranges. ALB dynamically extracts the destination address from the request content and then forwards the request. Only ALB Extensible Edition instances are supported, and a service extension that includes the dynamic forwarding component is required.
- For Extensible instances: Optional. When you create a server group of the Server, IP, or Function Compute type, select this option if you want to attach it to a listener or forwarding rule of an ALB Extensible Edition 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 need to configure this parameter only for Server and IP type 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. HTTP/2 must be enabled. The ALB instance uses the gRPC protocol to communicate with backend servers.
  You do not need to configure this parameter for Function Compute, AI service, or MCP service server groups. IP address range server groups support only the HTTP backend protocol.
  
  HTTPS listeners of Basic ALB instances do not support the HTTPS backend protocol.
  
  ALB Extensible Edition instances do not support the gRPC backend protocol.
- DNS Server Configuration: Required only for DNS and AI service server groups. Specifies the DNS server used to resolve backend domain names. Click Auto-fill with Private DNS Address to automatically enter the Alibaba Cloud internal DNS address.
  
  The DNS server address is an IPv4 address plus a port, such as 100.100.2.136:53. The 22.0.0.0/8 and 33.0.0.0/8 CIDR blocks are not supported.
  
  By default, a server group supports up to 5 DNS server addresses.
- Associate Service Extension:
  - IP Address Range server groups: A service extension must be associated. It is enabled by default and cannot be disabled. This type of server group relies on the dynamic forwarding component to extract the destination address from the request content. You cannot create the server group without associating a service extension that includes this component.
  - Server and IP Address server groups: Configurable only after you select For Extensible instances. After it is enabled, you can associate only a service extension that includes the load-aware routing component, which enables intelligent traffic scheduling by sensing the real-time load of backend servers.
  You can associate a service extension in one of the following two ways:
  - Quick Create from Template: Select a template for the corresponding component to create a service extension and associate it with the current server group. You can modify the component configuration before creation.
  - Use Existing Service Extension: Select an existing service extension that includes the corresponding component.
- 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 need to configure this parameter only for Server and IP type 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 need to configure this parameter only for Server and IP type server groups.
- Health Check: Enabled by default. Detects the availability of backend servers.
  
  You need to configure this parameter only for Server, IP, and Function Compute type server groups. 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.
  
  ALB Extensible Edition instances currently support only the HTTP and TCP health check protocols.
  - Advanced Health Check Settings: Click 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, select More 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

Lingjun ENIs can be added.
When For Extensible instances is selected, you can associate a service extension that includes the load-aware routing component to enable intelligent traffic scheduling by sensing the real-time load of backend servers.

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, set Server Type to ECS, Elastic Network Interface (ENI), or ECI, select the target backend servers, and then click Next.
- If no backend servers are available, click the button in the upper-right corner of the server list to purchase or create one.
- To add an ENI, make sure that it is bound to an ECS instance. For more information, see Bind a secondary ENI.
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.

ALB Extensible Edition instances support only Function Compute 3.0.

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.
When For Extensible instances is selected, you can associate a service extension that includes the load-aware routing component to enable intelligent traffic scheduling by sensing the real-time load of backend servers.

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 Protocol 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.

DNS

Add a domain name as a backend service. ALB resolves the domain name and forwards requests to the resolved address. For a detailed tutorial, see Host a static website on OSS with ALB Extensible Edition.

Only ALB Extensible Edition instances support DNS type server groups.

Limits

By default, a DNS type server group supports up to 10 domain names. To increase this limit, contact your account manager.
You must ensure network connectivity between ALB and the resolved address of the backend domain name.
Alibaba Cloud internal DNS, custom DNS servers, and PrivateZone resolution are supported. Specify the DNS server in the DNS Server Configuration of the server group.
Backend services of the DNS type do not support weight configuration. The weight is fixed at 100.

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 DNS Name. Configure the following parameters and click OK.
- DNS name: Enter the domain name of the backend service, such as static.example.com.
- Port: The port on which the backend service provides services.

AI service

Add an LLM service as a backend service. When ALB forwards requests, it automatically includes the API key from the identity credential to complete authentication. For a detailed tutorial, see Use ALB Extensible Edition to call multiple LLM services in a unified manner.

Only ALB Extensible Edition instances support AI service type server groups.

Limits

A server group of the AI service type supports only one AI service.
Before you add the service, you must create an identity credential for the API key of the LLM service.
By default, an AI service can be associated with up to 10 identity credentials.
Backend services of the AI service type do not require port or weight configuration.

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 AI Service. Configure the following parameters and click OK.
- Model provider: Select the provider of the LLM service.
- Endpoint: Automatically populated after you select the LLM provider. You can modify it manually.
- Identity Credential: Select one or more existing identity credentials. ALB selects an API key from the selected identity credentials to communicate with the LLM service. Configuring multiple credentials distributes the call quota of a single API key and improves service availability.
- API Key Health Check: We recommend that you enable this option. After it is enabled, when the backend returns a 401 or 429 status code, ALB automatically removes the corresponding API key, and requests are handled by other available API keys.
The credential location of the API key is fixed to HTTP Header. The parameter name and prefix are preset values that cannot be modified.

MCP service

Add MCP servers, Function Compute, or REST APIs as backend services. ALB performs MCP direct proxy or MCP-to-OpenAPI protocol conversion to provide a unified service endpoint for agents. For a detailed tutorial, see Use ALB Extensible Edition to manage MCP services.

Only ALB Extensible Edition instances support MCP service type server groups, and a service extension that includes the MCP proxy component is required. This is a whitelist feature. To use it, contact your account manager.

Limits

A single MCP service type server group supports a mix of MCP servers, Function Compute, and REST APIs.
Within the same server group, service names must be unique, the access endpoints resolved from MCP servers and REST APIs must be unique, and Function Compute ARNs must be unique.
The MCP service node must be a domain-name address that starts with http:// or https://. IP addresses are not supported, and localhost and 127.0.0.1 are not supported.
A mix of the Streamable HTTP and SSE access methods is supported, but protocol conversion between them is not. ALB and the backend must use the same access method.
OpenAPI configuration supports OpenAPI 3.0 and Alibaba Cloud OpenAPI, and the schema supports only one access endpoint. You can enter the schema directly in the editor or import a local OpenAPI file. The maximum file size is 1 MB.
The Forward to action of a forwarding rule supports selecting only one MCP service type server group, which cannot be selected together with server groups of other types. The default forwarding rule of a listener does not support forwarding to MCP service type server groups.

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 MCP Service. Configure the following parameters and click OK.
- Service Name: Enter the name of the MCP service. It must be unique within the server group.
- Service Type: Select the form of the backend service.
  - MCP Server: ALB directly proxies the backend MCP service. You must enter the MCP Service Endpoint and select the Access Method (Streamable HTTP or SSE).
  - Function Compute: ALB converts the MCP protocol to OpenAPI to communicate with Function Compute. You must enter the Function Compute ARN and complete the OpenAPI Configuration.
  - REST API: ALB converts the MCP protocol to OpenAPI to communicate with the backend REST API. You must complete the OpenAPI Configuration.
- Outbound Authentication: Set the authentication method that ALB uses to access the backend service. MCP Server supports No Authentication. Function Compute supports RAM Role without additional configuration. REST API supports API Key and allows you to specify the Credential Location. When you use an API key, you must first create an API key identity credential.
When the access endpoint of a backend MCP service remains unchanged but its tool list changes, find the target service in the backend server list and click Sync in the Actions column to make ALB retrieve the latest tool list.

IP address range

This type of server group does not require you to register specific backend servers. You only configure the allowed destination IP address ranges and port ranges. ALB extracts the destination address from the request content, verifies whether it is within the allowed range, and then forwards the request. For a detailed tutorial, see Use ALB Extensible Edition to implement dynamic forwarding.

Only ALB Extensible Edition instances support IP address range server groups, and a service extension that includes the dynamic forwarding component is required.

Limits

A default-deny policy is used. A request is forwarded only when its destination address matches both the IP address range and the port range of an entry. Requests that do not match return 403.
The IP address range supports the CIDR format for both IPv4 and IPv6. To specify a single address, use the /32 mask for IPv4 and the /128 mask for IPv6.
Reserved CIDR blocks such as 22.0.0.0/8, 33.0.0.0/8, 100.0.0.0/8, and 127.0.0.0/8 are not supported.
The port range supports a single port or a continuous range, such as 80 or 8080-8090. Valid values: 1 to 65535. The start port cannot be greater than the end port.
By default, an IP address range server group supports up to 200 IP address range entries.
IP address range entries do not support weight configuration.

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 Segment. Configure the following parameters and click OK.
- IP Address Range: Enter the allowed destination IP address range, such as 192.168.1.0/24.
- Port Range: Enter the allowed destination port range for this address range, such as 6000-6010.

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.

Supported only for Server type and IP type server groups. ALB Extensible Edition instances are not supported.

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-enabled ALB instances are supported. Basic and Extensible Edition 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 (graceful launch).

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 and Extensible Edition 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 and Extensible Edition ALB instances do not support this feature.

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

Session persistence is not supported when cross-zone 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-zone load balancing.

Add IPv6 backend servers

If you need to add IPv6 backend servers to a server group, set IP Protocol Version to IPv4/IPv6 Dual Stack.

This feature is supported only for server groups of the Server and IP Address types. ALB Extensible Edition instances are not supported.
The VPC to which the server group belongs must have IPv6 enabled.
You can add a server group with an IP Protocol 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 Protocol Version to IPv4/IPv6 Dual Stack.

API

When you call the CreateServerGroup operation, set Ipv6Enabled to true. This is equivalent to setting IP Protocol 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 account manager
alb_quota_loadbalancer_servers_num_extensible_edition	Number of backend servers that can be added to an ALB Extensible Edition instance	1,000	-	-
alb_quota_fqdn_servergroup_servers_num	Number of backend servers that can be added to a DNS type server group	10	-	-
alb_quota_dns_servers_num	Number of DNS server addresses that can be configured for a server group	5	-	-