Disable cross-zone load balancing

How it works

By default, cross-zone load balancing is enabled for ALB instances. Incoming requests are distributed to backend services deployed in all selected zones within the specified region. If you disable this feature for a server group, loads are balanced across each single zone.

Key feature

Reduced latency: Distributing traffic within the same availability zone reduces data transfer latency between zones and improves application response speed.

Use cases

This feature is ideal for low-latency scenarios:

• Financial trading: In high-frequency quantitative trading, low latency enables fast transaction processing and reduces the risk of failures or timeouts.

• Real-time communications: In applications such as video conferencing and instant messaging, low latency ensures a smooth user experience.

• Internet of Things (IoT): In scenarios such as real-time data collection, low latency ensures timely data analysis and response, improving overall system efficiency and accuracy.

Limitations

• Only standard and WAF-enabled ALB instances support disabling cross-zone load balancing. This feature is not available for basic ALB instances.

• When cross-zone load balancing is disabled, you cannot enable session persistence.

• You cannot disable cross-zone load balancing for IP-based server groups that have Remote IP enabled.

• This setting does not apply to server groups of the Function Compute type.

Example scenario

An enterprise has a highly available application deployed in the China (Hangzhou) region with cross-zone load balancing enabled by default. Due to a change in business requirements, the application now requires lower latency.

To meet this new requirement, the enterprise disables cross-zone load balancing. This configures the ALB instance to route traffic only to backend servers within the same availability zone, which reduces latency and improves application speed.

Prerequisites

• You have created a standard ALB instance in the China (Hangzhou) region and selected multiple availability zones during creation, for example, Zone H and Zone K. For more information, see Create and manage an ALB instance.

• You have created a server group.

• You have added ECS instances ECS01 and ECS02 to the server group. ECS01 is in Availability Zone H and ECS02 is in Availability Zone K, and an application service is deployed on both instances.

  Sample commands to deploy a test service on an ECS instance

  Sample commands for ECS01:

  yum install -y nginx
  systemctl start nginx.service
  cd /usr/share/nginx/html/
  echo "Hello World ! This is ECS01." > index.html

  Sample commands for ECS02:

  yum install -y nginx
  systemctl start nginx.service
  cd /usr/share/nginx/html/
  echo "Hello World ! This is ECS02." > index.html

• You have configured listeners for the instance and associated the created server group. For more information, see Add an HTTP listener, Add an HTTPS listener, or Add a QUIC listener.

• You have registered a domain name, completed the ICP filing, and configured a CNAME record for the domain name to point to the ALB instance.

Procedure

Step 1: Disable cross-zone load balancing

This topic demonstrates how to disable cross-zone load balancing for an existing server group. You can also disable this feature during server group creation.

1. Log on to the Application Load Balancer (ALB) console.

2. On the Server Groups page, find the target server group and click its ID.

3. On the Details page, in the Basic Information section, click Modify Basic Information.

4. In the Modify Basic Information dialog box, click Advanced Settings, turn off the Cross-zone Load Balancing switch, and then click Save.

(Optional) Step 2: Verify traffic routing

On the Instance Details page of the target instance, in the Zone section, copy the elastic IP addresses (EIPs) for Zone H and Zone K.

1. Use a browser to access the EIP of Availability Zone H, for example, http://<elastic IP address>. Refresh the browser multiple times. You can only access the backend server ECS01 in Availability Zone H.

   The page displays Hello World ! This is ECS01.

2. Use a browser to access the EIP of Availability Zone K, for example, http://<elastic IP address>. Refresh the browser multiple times. You can only access the backend server ECS02 in Availability Zone K.

   Hello World ! This is ECS02.

Step 3: Test the latency

1. Create an internet-facing ECS instance (ECS03) in the Germany (Frankfurt) region to use as a test client. If you already have a test server, you can skip this step.

2. Log on to the test client (ECS03) and run the following command to test latency.

   curl http://www.example.com  -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" 

   Parameter description:

   • time_connect: The connection time. Time, in seconds, from the start of the request until the TCP connection is established.

   • time_starttransfer: The time to first byte (TTFB). Time, in seconds, from when the client sends a request until it receives the first response byte from the backend server.

   • time_total: The total time. This is the time, in seconds, from when the client sends a request until the backend server completes the response.

   Response time with cross-zone load balancing enabled:

   [ecs-assist-user@xxx ~]$ curl http://xxx -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n"
   Hello World ! This is ECS02.
   time_connect: 0.170654
   time_starttransfer: 0.347200
   time_total: 0.347234
   [ecs-assist-user@xxx ~]$ curl http://xxx -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n"
   Hello World ! This is ECS01.
   time_connect: 0.178056
   time_starttransfer: 0.357358
   time_total: 0.357397

   Response time with cross-zone load balancing disabled:

   [ecs-assist-user@xxx ~]$ curl http://xxx -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n"
   Hello World ! This is ECS01.
   time_connect: 0.152544
   time_starttransfer: 0.307768
   time_total: 0.307797

   The test results show that disabling cross-zone load balancing reduces the connection time, TTFB, and total time.

FAQ

Why are 503 errors returned?

This error occurs when the availability zone that receives a request has no available backend servers in its associated server group. Unable to forward the request, the ALB instance returns a 503 error.

Why is session persistence not supported?

Session persistence requires routing requests across availability zones, for example, from zone A to a specific server in zone B. Disabling cross-zone load balancing prevents this routing, making the two features incompatible.

What is the health status of cross-zone servers?

When cross-zone load balancing is disabled, health checks are performed only within the same availability zone. A backend server in a different availability zone will therefore have a health check status of Unused.

References

• For information about the regions and zones that ALB supports, see Regions and zones.

• If you encounter issues during configuration, see FAQ about ALB.

• If you encounter health check issues, see Troubleshoot ALB health check issues.

• CreateServerGroup: Create a server group.

• UpdateServerGroupServersAttribute: Update backend server configurations.

• ListServerGroups: Query server groups.

• GetListenerHealthStatus: Query health check status.