All Products
Search
Document Center

Server Load Balancer:ALB instances

Last Updated:Feb 10, 2026

An Application Load Balancer (ALB) instance receives client requests and forwards them to backend servers based on listener forwarding rules.

DNS name

ALB instances use DNS names to provide services. To access an ALB instance through a custom domain name, create a CNAME record to resolve your domain name to the DNS name of the ALB instance.

After the load balancer domain name upgrade, newly created ALB instances no longer support direct access by their DNS names.

Instance status

The following table describes the possible statuses of an ALB instance.

Status

Description

Lock type

Deletion allowed

Modification allowed

Running

The instance is running properly.

Not applicable

  • Yes, if deletion protection is disabled.

  • No, if deletion protection is enabled.

  • Yes, if modification protection is disabled.

  • No, if modification protection is enabled.

Creating

The instance is being created.

No

No

Updating Configuration

The instance configuration is being modified.

No

Creation Failed

The instance failed to be created.

Yes

Stopped

When an instance is locked for a specific reason, its status changes to Stopped and the service becomes unavailable.

Locked (Overdue Payment): The instance is locked due to an overdue payment. Renew the instance to unlock it.

No

Locked (Associated Resources Anomaly): The Elastic IP Address (EIP) or Internet Shared Bandwidth instance associated with the instance is locked due to an overdue payment. Renew the associated resource to unlock it.

No

Locked (Associated Resources Overdue): The EIP or Internet Shared Bandwidth instance associated with the instance has been released due to an overdue payment. The instance is no longer usable. Release the instance.

Yes

Locked (Security Risks): The instance is locked due to a security risk. Go to the Security Management console to request an unblock.

No

Instance network type

ALB instances support two network types. You can change the network type to switch between them.

Item

Internet-facing ALB instance

Internal ALB instance

Use case

Backend services must be accessible from the Internet.

Backend services only need to be accessible from within an Alibaba Cloud VPC.

IP address allocation

Assigns an EIP and a private IP address. You can also use an Anycast EIP to provide nearby access for multi-region services.

Assigns only a private IP address.

Access method

Accessible from both the Internet and private networks.

Accessible from private networks only.

Diagram

imageimage

Billing

Instance fee, Load Balancer Capacity Unit (LCU) fee, and Internet data transfer fees (charged by EIP).

Instance fee and LCU fee only.

IP version

ALB supports two IP versions: IPv4 and dual-stack.

IP version

Default IP addresses per zone

Details

IPv4

  • Internet-facing: 1 public IPv4 address + 1 private IPv4 address.

  • Internal: 1 private IPv4 address.

Supports only IPv4 client access (for example, 192.0.2.1). Forwards IPv4 client traffic to IPv4 backend services only.

Dual-stack

  • Internet-facing: 1 public IPv4 address + 1 private IPv4 address + 1 IPv6 address.

  • Internal: 1 private IPv4 address + 1 IPv6 address.

Supports both IPv4 (for example, 192.168.0.1) and IPv6 (for example, 2001:db8:1:1:1:1:1:1) client access. Forwards both IPv4 and IPv6 client traffic to IPv4 or IPv6 backend services.

If the server group type of a dual-stack ALB instance is IP, and you need to add IPv6 backend servers, use an upgraded ALB instance.

Dual-stack usage notes:

  • Dual-stack is available only in supported regions.

  • The network type of a dual-stack ALB instance is determined by its IPv4 address. If the instance has a public IPv4 address, it is Internet-facing. If it has only a private IPv4 address, it is internal.

  • You can only create new dual-stack instances. Upgrading an existing IPv4 instance to dual-stack is not supported.

  • Access control list (ACL) entries support only IPv4 addresses.

WAF integration

  • We recommend enabling Website Application Firewall (WAF) 3.0 protection for ALB instances (service-based integration), which creates WAF-enabled ALB instances.

    • Supported regions:

      Area

      Region

      China

      China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), and China (Hong Kong)

      Asia Pacific

      Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok), and South Korea (Seoul)

      Europe and Americas

      Germany (Frankfurt), US (Virginia), US (Silicon Valley), and Mexico

      Middle East

      SAU (Riyadh - Partner Region)

    • WAF version: You must use WAF 3.0. If you have a WAF 2.0 instance in your account, you must first release the WAF 2.0 instance or migrate it to WAF 3.0.

      By default, ALB does not enable the X-Forwarded-Proto header in requests forwarded to the backend server group. After you terminate a WAF 2.0 instance, accessing the ALB directly may cause service exceptions, such as infinite loop redirection, because the backend service cannot properly identify the protocol (HTTP/HTTPS). To prevent this issue, you must manually enable the X-Forwarded-Proto request header in the ALB listener configuration.

    • Feature availability: WAF for ALB instances does not support the following features: the data leakage prevention module and the automatic Web SDK integration feature for anti-crawler rules for websites in the bot management module.

  • If you want to use an existing WAF 2.0 instance (transparent integration), Internet-facing Basic and Standard ALB instances support WAF 2.0 integration. Supported regions: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing), and China (Zhangjiakou). Internal ALB instances do not support WAF 2.0 integration.

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 selected zones within the specified region. If you disable this feature for a server group, loads are balanced across each single zone.