Network Load Balancer (NLB) instances receive requests from clients and distribute requests to backend servers based on the forwarding rules that you configure on listeners. To use the NLB service, you must create an NLB instance and add listeners and backend servers to the NLB instance.
Instance status
Instance status | Status description | Why the NLB instance is locked | Whether the NLB instance can be deleted | Whether configurations can be changed |
Running | The NLB instance is running as expected. | N/A | Based on whether delete protection is enabled.
| Based on whether the configuration read-only mode is enabled.
|
Creating | The NLB instance is being created. | N/A | No | No |
Updating Configuration | The configuration of the NLB instance is being updated. | N/A | No | |
Creation Failed | The NLB instance fails to be created. | N/A | Yes | |
Stopped | The NLB instance is stopped. | Locked (Overdue Payment): The NLB instance is locked due to overdue payments. Renew your NLB instance at the earliest opportunity. The NLB instance resumes after it is unlocked. | No | |
Locked (Associated Resources in Abnormal State): The elastic IP addresses (EIPs) or Internet Shared Bandwidth instances that are associated with the NLB instance are locked due to overdue payments. Renew the EIPs or Internet Shared Bandwidth instances at the earliest opportunity. The NLB instance resumes after the associated resources are unlocked. | No | |||
Locked (Associated Resources Overdue and Released): The EIPs or Internet Shared Bandwidth instances that are associated with the NLB instance are released due to overdue payments and the NLB instance is unavailable. We recommend that you release the NLB instance. | Yes | |||
Locked (Security Risks): The NLB instance is locked due to security risks. You can go to the Penalties List page in the Security Control console to apply to unlock the instance. | No |
Network types
Alibaba Cloud provides Internet-facing and internal-facing NLB instances.
You can switch the network type of an NLB instance between Internet-facing and internal-facing. For more information, see Change the network type of an NLB instance.
Internet-facing NLB instances
When you create an Internet-facing NLB instance, it is assigned a public IP address and a private IP address.
Internet-facing NLB instances receive requests from the Internet. By default, an Internet-facing NLB instance uses an elastic IP address (EIP) to provide Internet-facing services and forward requests from the Internet to backend servers based on forwarding rules.
Internet-facing NLB instances are also assigned private IP addresses, which allow the NLB instances to access Elastic Compute Service (ECS) instances in virtual private clouds (VPCs).
Internal-facing NLB instances
When you create an internal-facing NLB instance, it is assigned a private IP address.
Internal-facing NLB instances receive requests from VPCs in which the NLB instances are created, and forward the requests to backend servers based on forwarding rules.
Internal-facing NLB instances do not support Internet access.
IP versions
IPv4 and dual-stack
NLB supports IPv4 and dual-stack.
IP version | Default value | Description |
IPv4 |
| Clients can access IPv4 NLB instances only by using IPv4 addresses, such as 192.168.0.1. |
Dual-stack |
| Clients can access dual-stack NLB instances by using IPv4 addresses such as 192.168.0.1, or IPv6 addresses such as 2001:db8:1:1:1:1:1:1. |
The network type of a dual-stack NLB instance is determined by the network type of the IPv4 address. If the IPv4 address is a private IP address, the NLB instance is internal-facing. If the IPv4 IP address is a public IP address, the NLB instance is Internet-facing.
Regions that support dual-stack
Area | Region |
China | China (Hangzhou), China (Beijing), China (Shenzhen), China (Shanghai), China (Qingdao), China (Zhangjiakou), China (Chengdu), China (Guangzhou), China (Hong Kong), China (Heyuan), China (Ulanqab), China (Nanjing - Local Region), China (Wuhan - Local Region), and China (Fuzhou - Local Region) |
Asia Pacific | Thailand (Bangkok), Philippines (Manila), Singapore, Japan (Tokyo), South Korea (Seoul), Malaysia (Kuala Lumpur), and Indonesia (Jakarta) |
Europe and Americas | Germany (Frankfurt), UK (London), US (Virginia), and US (Silicon Valley). |
Middle East | SAU (Riyadh - Partner Region) |
Usage notes on dual-stack NLB instances
You cannot upgrade existing IPv4 NLB instances to dual-stack NLB instances. You can only create dual-stack ALB instances.
Cross-zone load balancing
If cross-zone load balancing is enabled, each NLB instance distributes requests to backend servers in all zones of the region by default. If cross-zone load balancing is disabled, each NLB instance distributes requests to backend servers only in the zones that are specified for the NLB instance.
The following example shows how cross-zone load balancing works. In this example, the round-robin scheduling algorithm is used. In the following figure, an NLB instance with two ECS instances is created in Zone A and another NLB instance with eight ECS instances is created in Zone B. When requests are sent to the NLB instances, the round-robin scheduling algorithm specifies that the requests are evenly distributed to the NLB instances. Each NLB instance distributes requests to the ECS instances in the zone.
If cross-zone load balancing is enabled, each ECS instance in the zones receives 10% of the network traffic. That is because each NLB instance receives 50% of the requests, which are evenly distributed to all 10 ECS instances.
If cross-zone load balancing is disabled, each ECS instance in Zone A receives 25% of the requests, and each of the eight ECS instances in Zone B receives 6.25% of the requests.
Domain names
Each NLB instance has a domain name, which is used by the NLB instance to provide services.
You can use a CNAME record to map a custom domain name to the domain name of an NLB instance. This facilitates access to network resources. When a client accesses the custom domain that is mapped to the domain name of the NLB instance, the custom domain name is resolved to the domain name of the NLB instance.