All Products
Search
Document Center

Server Load Balancer:Disable cross-zone load balancing to reduce access latency

Last Updated:Dec 11, 2024

Application Load Balancer (ALB) supports cross-zone load balancing to prevent resource bottlenecks caused by single-zone load balancing. However, in latency-sensitive business scenarios, such as quantitative trading in finance and real-time communications, cross-zone load balancing may cause unwanted network latency. In such cases, you can disable cross-zone load balancing to configure ALB to distribute requests within a single zone of a region, thus increasing the request access speed for your business.

Overview

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.

Warning

Before you disable cross-zone load balancing for your ALB service, ensure that at least one backend server with adequate resources is available in each zone. To avoid any undesired impact on your business, make sure you understand how this feature works before disabling it.

Benefits

Reducing latency: Distributing requests within a single zone eliminates the network latency caused by cross-zone data transfer, improving the request access speed for your business.

Use scenarios

Latency-sensitive scenarios:

  • Financial trading: Intensive quantitative trading requires low latency to enable fast transaction processing. This reduces the risk of transaction failure or timeout.

  • Real-time communications: Video conferencing and instant messaging require low latency for a seamless and smooth user experience.

  • Internet of Things (IoT): Real-time data collection requires low latency to enable prompt data analysis and quick response to requests. This improves the overall efficiency and accuracy of the data collection system.

Limits

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

Sample scenario

A company has deployed a high-availability business in the China (Hangzhou) region, with cross-zone load balancing enabled by default. Due to business transformation, the company now has higher requirements on the latency.

In this case, the company can disable cross-zone load balancing, allowing ALB to distribute requests only to backend services deployed in a single zone of a region. In this way, the network latency can be reduced and the request access speed can be increased for the business of the company.

image

Prerequisites

  • A standard ALB instance is created in multiple zones of the China (Hangzhou) region. In this example, an ALB instance is created in Zone H and Zone K. For more information, see Create an ALB instance.

  • A server group is created. For more information, see Create and manage server groups.

  • Elastic Compute Service (ECS) instances ECS01 and ECS02 are added to the server group associated with the ALB instance. ECS01 is deployed in Zone H and ECS02 in Zone K. Both instances have application services deployed on them.

    Click to view sample code for deploying services on ECS instances

    Sample code for deploying a service on ECS01:

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

    Sample code for deploying a service on ECS02:

    yum install -y nginx
    systemctl start nginx.service
    cd /usr/share/nginx/html/
    echo "Hello World ! This is ECS02." > index.html
  • Listeners are configured for the ALB instance and the created server group is associated with the ALB instance. For more information, see Add an HTTP listener, Add an HTTPS listener, and Add a QUIC listener.

  • A domain name is registered, an Internet Content Provider (ICP) number is obtained for the domain name, and a CNAME record is configured to map the custom domain name to the domain name of the ALB instance. For more information, see Register a generic domain name, ICP filing process, and Add a CNAME record to an ALB instance.

Procedure

Step 1: Disable cross-zone load balancing

This step describes how to modify the configuration of a server group to disable cross-zone load balancing under the condition that a server group has been created. If you have not created a server group, you can disable cross-zone load balancing for one when creating it.

  1. Log on to the ALB console.

  2. On the Server Groups page, find the server group that you want to manage and click the server group 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 Cross-zone Load Balancing, then click Save.

(Optional) Step 2: Verify that cross-zone load balancing is disabled

Note

This step only verifies whether the configuration modification is effective. Step 3 tests the actual network latency after the configuration modification.

On the Instance Details page of the ALB instance, on the Zone tab, copy the Elastic IP Addresses (EIPs) of Zone H and Zone K, respectively.

  1. Use a browser to access the EIP of Zone H, such as http://<EIP of Zone H>. Refresh the browser multiple times. Only the backend server ECS01 deployed in Zone H can be accessed.

    image

  2. Use a browser to access the EIP of Zone K, such as http://<EIP of Zone K>. Refresh the browser multiple times. Only the backend server ECS02 deployed in Zone K can be accessed.

    image

Step 3: Test the network latency

Note

The test results may vary depending on the region and zone. The actual test results of your business shall prevail. In this example, packet delay is checked.

  1. Create an Internet-facing instance ECS03 in the Germany (Frankfurt) region as a testing client. If you have existing servers that can be used for testing, you do not need to create one.

  2. Log on to the testing client ECS03 and run the following command to test the access latency:

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

    Involved parameters are described as follows:

    • time_connect: Connection time. The amount of time that is consumed to establish a TCP connection. Unit: seconds.

    • time_starttransfer: Data transfer time. The amount of time from when the client sends a request to the backend server to when the first byte is sent to the client. Unit: seconds.

    • time_total: Total connection time. The amount of time from when the client sends a request to the backend server to when the client receives the last byte from the backend server. Unit: seconds.

    Response time with cross-zone load balancing enabled:

    image

    Response time with cross-zone load balancing disabled:

    image

    The test results indicate that after cross-zone load balancing is disabled, the connection time, data transfer time, and total connection time are all shortened.

FAQs

Why do I receive a 503 status code after disabling cross-zone load balancing?

A possible reason is that for the server group associated with your ALB instance, no backend server is available in a certain zone where your ALB instance is deployed. Since your ALB instance has no backend server to forward requests, a 503 status code is returned.

Why am I unable to enable the session persistence feature after disabling cross-zone load balancing?

With session persistence enabled, the requests an ALB instance receives from one zone may be constantly forwarded to the backend servers in another zone. After cross-zone load balancing is disabled, session persistence cannot be implemented.

What is the health check status of a backend server that is not deployed in any zones of an ALB service?

After cross-zone load balancing is disabled for an ALB instance, a backend server that is not deployed in any zones of the ALB service is declared as Unused.

References