Network Load Balancer (NLB) automatically scales VIP performance as traffic grows. This page lists per-VIP performance metrics, per-account resource quotas, and behavioral constraints to consider when designing your deployment.
Instance performance metrics
Each VIP provides the following maximum performance. Total instance performance scales linearly with the number of zones:
Instance performance = Number of zones x Per-VIP performance
|
Metric |
Per-VIP maximum |
|
New connection rate |
200,000/s |
|
Concurrent connections |
5,000,000 |
|
Private network throughput (inbound + outbound) |
50 Gbps |
|
Packets per second (PPS) |
8,000,000 pps |
Performance scales automatically within minutes as traffic grows. For higher performance or faster scaling, contact your account manager.
Internet-facing NLB instances use Elastic IP Address (EIP) for Internet access by default. For Internet performance limits, see EIP performance limits.
To ensure performance and stability, NLB uses a distributed, highly reliable cluster architecture in which all traffic is evenly distributed across multiple system servers in the cluster for forwarding. Therefore, the automatic elastic scaling described above can only reach the maximum elastic upper limit in multi-session scenarios. In single-session scenarios, throughput and packet processing rate are limited by the performance of a single system server. We recommend that you conduct business stress tests to understand the instance performance and configure appropriate monitoring.
Quota limits
The tables below list default quotas per region per Alibaba Cloud account. Adjustable indicates whether you can request a quota increase. To increase an adjustable quota, go to the SLB console Quota Center (select the NLB tab) or Quota Center. For steps, see Manage NLB quotas.
NLB instances
|
Resource |
Default limit |
Adjustable |
|
NLB instances per region per account |
60 |
Yes ( |
|
Backend servers per NLB instance — Elastic Container Instance (ECI) type |
1,600 |
No |
|
Backend servers per NLB instance — Elastic Compute Service (ECS) / Elastic Network Interface (ENI) / IP type |
400 |
Yes ( |
|
Listeners per NLB instance |
50 |
Yes ( |
|
Additional certificates per NLB instance (excluding the default certificate) |
25 |
Yes ( |
Server groups
|
Resource |
Default limit |
Adjustable |
|
NLB server groups per region per account |
3,000 |
No |
|
Backend servers per server group — ECI type |
1,600 |
No |
|
Backend servers per server group — ECS/ENI/IP type |
400 |
Yes ( |
|
Times a backend server (including IP type) can be added to NLB server groups |
200 |
Yes ( |
|
Listener associations per NLB server group |
50 |
Yes ( |
Security policies
|
Resource |
Default limit |
Adjustable |
|
Custom NLB security policies per region per account |
50 |
No |
Security groups
The number of security groups and security group rules that an NLB instance can be associated with is derived from the ECS security group quota for ENIs:
-
Security groups: ECS ENI security group quota − 1 (reserved for the managed security group)
-
Security group rules: ECS ENI security group rule quota − number of rules in the managed security group
To raise these limits, increase the corresponding ECS ENI quotas.
Usage notes
5-tuple conflicts
5-tuple conflicts on backend servers can occur in either of these situations:
-
The number of backend servers is small and a single client accesses the NLB instance domain name with client IP preservation enabled in the associated server group.
-
A client simultaneously accesses the VIP or EIP of both an NLB instance and a CLB instance that share the same backend servers.
To avoid 5-tuple conflicts, enable client IP preservation or add more backend servers (including IP type) to distribute connections.
ICMP availability probes
NLB domain names have built-in availability probes for private VIPs. If ICMP traffic is blocked by a cloud firewall or network ACL, the availability probe fails and the VIP may be removed from DNS. Allow ICMP traffic in your firewall and ACL rules to prevent this.
UDP listeners and stateful protocols
When a UDP listener uses a server group with a non-QUIC ID hash scheduling algorithm (such as round robin or weighted round robin), avoid running stateful protocols (such as QUIC) on backend UDP services. If your backend UDP services are stateful, configure the server group to use the QUIC ID hash scheduling algorithm.
Concurrent connections with client IP preservation disabled
When client IP preservation is disabled, each zone supports up to 60,000 concurrent connections between the NLB instance and a single backend server (including IP type). When this limit is reached, NLB automatically allocates new local IPs to avoid port exhaustion. Each zone supports up to 8 local IPs, allowing up to 250,000 concurrent connections between the NLB instance and a single backend server per zone.
Make sure the vSwitch has enough available IP addresses to support this scaling.
To avoid hitting the per-zone connection limit, enable client IP preservation or add more backend servers (including IP type) to distribute connections.