Overview
Summary
An application delivery network is used to release applications, implement disaster recovery, and provide protection. Server Load Balancer (SLB) is a key component in an application delivery network. The SLB family includes the Layer 4 load balancer Network Load Balancer (NLB), the Layer 7 load balancer Application Load Balancer (ALB), and Classic Load Balancer (CLB). As a cloud-native gateway of Alibaba Cloud, SLB is one of the most important component in an application delivery network. This topic describes how to select, deploy, and use SLB to build a high-efficiency application delivery network.
Terms
Virtual Private Cloud (VPC): A VPC is a custom private network that you can create on Alibaba Cloud. VPCs are logically isolated from each other at Layer 2. You can create and manage cloud service instances in your VPC, such as Elastic Compute Service (ECS), Server Load Balancer (SLB), and ApsaraDB RDS.
Virtual IP address (VIP): A VIP is an IP address that is not assigned to a specific computer or network interface. VIPs can be dynamically allocated to different physical servers or devices to balance loads and implement high availability and redundancy.
DNS cutover: During network migration or switchover, DNS cutover allows network traffic to migrate from the existing server to a new server or service based on the updated DNS record. DNS cutover is used to ensure service continuity during migration.
CNAME: A CNAME record is a type of DNS record, which maps a domain name to another domain name. After a CNAME record is configured, the DNS server redirects requests to the destination domain name (CNAME) of an alias domain name, and then returns the IP address of the destination domain name configured in the A record.
Application Load Balancer (ALB): ALB is an Alibaba Cloud service that runs at the application layer and is optimized to balance traffic over HTTP, HTTPS, and Quick UDP Internet Connections (QUIC). ALB is highly elastic and can process large volumes of Layer 7 traffic on demand. ALB supports complex routing. ALB is deeply integrated with other cloud-native services and is designed to serve as a cloud-native Ingress gateway of Alibaba Cloud.
Network Load Balancer (NLB): NLB is a Layer 4 load balancing service intended for the Internet of Everything (IoE) era. NLB offers ultra-high performance and can automatically scale on demand. An NLB instance supports up to 100 million concurrent connections, which is ideal for services that require high concurrency.
Classic Load Balancer (CLB): CLB distributes inbound network traffic across multiple backend servers based on forwarding rules. CLB helps improve the performance and availability of your applications.
Network Intelligence Service (NIS): NIS provides a set of AIOps tools for you to manage the entire lifecycle of cloud networks from network planning to network O&M. For example, you can use NIS to perform traffic analysis, network inspections, network performance monitoring, network diagnostics, path analysis, and topology creation. NIS helps you optimize your network architecture, improve network O&M efficiency, and reduce network operations costs.
CloudMonitor: CloudMonitor is a service that monitors resources and Internet applications.
Internet Shared Bandwidth: Internet Shared Bandwidth supports bandwidth sharing and multiplexing within a region. After you create an Internet Shared Bandwidth instance in a region, you can add elastic IP addresses (EIPs) in the region to the Internet Shared Bandwidth instance. The EIPs can share the Internet Shared Bandwidth instance. This reduces Internet bandwidth costs.
Design principles
To ensure fast, reliable, and secure application releases, we recommend that you take into consideration the following principles when you design an application delivery network:
Performance: Make sure that the performance of the application delivery network can withstand the throughput, number of new connections, number of concurrent connections, and number of queries per second (QPS) during peak hours.
Scalability: Make sure that the application delivery network can automatically scale in or scale out based on the business volume, and design an appropriate pricing model.
Stability: Make sure that the application delivery network is equipped with a robust architecture and a strong disaster recovery mechanism to ensure stable application releases.
Security: Make sure that the application delivery network supports protection at the application, transmission, and network layers.
Observability: Make sure that the application delivery network supports full dimensional metrics and logging, which help you monitor your network in real time and perform analytics and troubleshooting.
We recommend that you combine the preceding design principles with the SLB performance and features required by your application system and the business scenario to select appropriate services and deployment solutions.
Key design
Select an SLB service
When you select an SLB service, focus on the following key capabilities: performance (capacities and features), stability, scalability, and security.
Prerequisites
Determine the type of load balancer required by your application system, such as Layer 4 load balancers or Layer 7 load balancers.
Comparison item | ALB | NLB | CLB |
Service positioning |
|
|
|
If your application system requires load balancing at Layer 4, select NLB or CLB.
If your application system requires load balancing at Layer 7, select ALB or CLB.
Key performance metrics
Determine the performance metrics required by your application system and select an appropriate SLB service.
Comparison item | ALB | NLB | CLB |
Architecture and performance |
|
|
|
Forwarding capabilities |
|
|
|
Backend server type |
|
|
|
O&M capabilities |
|
|
|
Cloud-native integration |
| Supports integration with Container Service for Kubernetes (ACK) and ACK Serverless (1.24 and later versions) | Must be used in combination with container services such as Container Service for Kubernetes (ACK) and Serverless Kubernetes (ASK) |
Common scenarios |
|
|
|
Capacity
If your application system requires Layer 4 load balancing, high scalability, and a high number of new connections or concurrent connections, we recommend that you select NLB.
If your application system requires Layer 7 load balancing, high scalability, and a high number of QPS, we recommend that you select ALB.
If your application system requires moderate load balancing performance at Layer 4 or Layer 7, we recommend that you select CLB.
Supported features
If your application system has high requirements for SSL offloading for TCP traffic at Layer 4, throttling in case of traffic spikes, and cloud-native support, we recommend that you select NLB.
If your application system has high requirements for routing and cloud-native ingress gateways at Layer 7, we recommend that you select ALB.
If your application system has moderate requirements for Layer 4 or Layer 7 features, we recommend that you select CLB.
Key stability metrics
ALB, NLB, and CLB use different disaster recovery architectures and mechanisms. Before you select an SLB service, we recommend that you determine the disaster recovery capabilities required by your application system.
Multiple active zones
ALB and NLB support multi-zone deployment. If the region of your application system supports two or more zones, we recommend that you select at least two zones to ensure service high availability. ALB and NLB provide services by using domain names. The alias domain names are mapped to the NLB or ALB domain name based on the CNAME record. Business traffic is scheduled to the VIPs of the ALB or NLB instance in the selected zones. If a zone fails, DNS cutover is triggered in the zone to migrate traffic to another zone to implement disaster recovery. This mechanism ensures that traffic can be automatically switched to a healthy zone if one of the zones fails. Disaster recovery ensures service continuity and high availability.
Primary/secondary zones
CLB dual-zone deployment is supported in most regions. Such CLB instances are deployed across two zones. By default, the primary zone is enabled. If the primary zone fails, CLB can switch to the secondary zone within 30 seconds to restore services. When the primary zone recovers, CLB automatically switches back to the primary zone.
NoteZone-disaster recovery for CLB is implemented between primary and secondary zones. CLB switches to the secondary zone only when the entire CLB cluster within the primary zone is completely unavailable due to factors such as power outages or connectivity failures in the primary zone. A switchover is not triggered if only a single instance in the primary zone fails.
To conclude, NLB and ALB are deployed across multiple zones to support higher disaster recovery capabilities than CLB, which is deployed across two zones. A single SLB instance can be deployed in at least two zones to improve system high availability and disaster recovery capabilities. In addition, faster switchover is supported. You can remove the DNS record of the faulty zone to quickly respond to failures and handle issues. We recommend that you select an SLB service based on the performance and stability required by your application system. If your application system has high requirements for high availability, NLB and ALB are more suitable because they support multi-zone deployment.
Key scalability metrics
The most direct benefit of scalability is quick scale-outs during peak hours. You are charged for the actual amount of consumed resources, which prevents high costs caused by resource waste. Suggestions:
ALB and NLB support high capacity and high performance. If you select ALB or NLB for your application system, we recommend that you use the pay-by-LCU metering method to pay for the resources that you actually use.
CLB supports the pay-by-specification and pay-by-LCU metering methods. If you select CLB for your application system, we recommend that you use the pay-by-LCU metering method to pay for the resources that you actually use.
Key security metrics
ALB, NLB, and CLB support different features. We recommend that you determine the security requirements of your application system before you select an SLB service.
Layer 7 load balancing: protection against web attacks
To protect your application system against web attacks, we recommend that you select ALB. WAF-enabled ALB instances are integrated with Web Application Firewall (WAF) 3.0 at the service level.
WAF 3.0 is integrated with ALB through SDK modules, and uses the SDKs to extract traffic for detection and protection. This integration methods offers the following benefits:
Forwarding: WAF does not forward traffic, in case incompatibility or instability issues arise due to an additional forwarding layer, or network latency is increased.
Deployment: You do not need to modify the DNS settings, certificates, ports, or back-to-origin algorithms. The process to integrate with WAF is simple.
Layer 4 load balancing: encryption at the transmission layer
If your application system requires Layer 4 load balancing and encryption for SSL over TCP traffic, we recommend that you select NLB.
NLB supports TCP/SSL listeners that can perform SSL offloading over TCP traffic. Encrypted traffic is decrypted into plaintexts and forwarded to backend servers. This simplifies backend server configuration, reduces workloads, and increases the work efficiency.
Deploy the SLB service
After you select an SLB service, you need to focus on the performance, stability, and security when you deploy the SLB service.
Key performance metrics
Instance capacity
ALB and NLB instances support high performance and scalability. If your application system needs to withstand expected traffic spikes, such as promotional activities, we recommend that you contact your account manager in advance to assess whether the performance and scalability of your instance can withstand the traffic spikes.
A CLB instance supports the same specifications as the S3.large instance type, which supports a maximum of 1,000,000 connections, 100,000 new connections, and 50,000 QPS, no matter you use the pay-by-specification or pay-by-LCU metering method. We recommend that you select a metering method, an instance type, and the number of instances based on the traffic pattern and business scale of your application system.
Internet bandwidth
Internet-facing ALB and NLB instances use EIPs to provide Internet services.
If the traffic pattern of your application system is relatively stable, we recommend that you use pay-by-bandwidth Internet Shared Bandwidth instances, and specify a maximum bandwidth value.
If your application system experiences large traffic fluctuations, we recommend that you use pay-by-dominant-traffic Internet Shared Bandwidth instances and specify a maximum bandwidth value. The pay-by-dominant-traffic metering method bills only the data transfers in the dominant direction within a billing cycle.
NoteThe maximum bandwidth of pay-by-data-transfer EIPs is 200 Mbit/s. To ensure sufficient bandwidth resources for your application system, we recommend that you add your SLB instance to an Internet Shared Bandwidth instance.
If you use CLB, you can associate an EIP with your internal-facing CLB instance, or use an Internet-facing CLB instance. However, if you want to enable bandwidth multiplexing for multiple SLB instances and retain an exclusive IP address for each SLB instance, we recommend that you create an internal-facing CLB instance and associate it with an EIP. Then, add the CLB instance to an Internet Shared Bandwidth instance.
Key stability metrics
Instance zones
If you use ALB, select at least two zones, and deploy backend servers in the same zones as the ALB instance. However, ALB does not support disabling cross-zone forwarding. After the VIPs of an ALB instance receive client requests, the ALB instance forwards the requests to backend servers in all zones, instead of the zone of the VIP.
If you use NLB, select at least two zones and deploy backend servers in the same zones as the NLB instance. You can disable cross-zone forwarding for your NLB instance. After the VIPs of your NLB instance receive client requests, the NLB instance forwards the requests to backend servers in the zones of the NLB instance.
If you use CLB, deploy the CLB instance and backend servers in the same primary zone to prevent cross-zone forwarding.
Health checks on backend servers
We recommend that you enable health checks for your SLB instance to monitor the availability of the backend servers. If a backend server is declared unhealthy, SLB stops forwarding requests to the backend server and distributes subsequent requests to healthy backend servers. After the unhealthy backend server recovers, ALB distributes requests to the backend server. The health check feature prevents single points of failure (SPOFs) caused by unhealthy backend servers and improves the availability of services. ALB, NLB, and CLB support TCP and HTTP health checks.
Traffic throttling on listeners
To prevent avalanche effect caused by unexpected traffic spikes that exceed the backend server capacity, we recommend that you enable traffic throttling on SLB listeners. In cases of traffic spikes, traffic throttling allows only requests that do not exceed the backend server capacity.
ALB QPS throttling
You can throttle the total QPS or per-client QPS for an ALB listener. Per-client QPS throttling limits queries based on source client IP addresses. You can enable both throttling methods or one of the throttling methods.
NLB new connections per second (CPS) throttling
You can throttle the maximum number of new CPS in each zone (VIP) for an NLB listener.
Key security metrics
Access control based on whitelists or blacklists
ALB and NLB can be added to security groups. You can enable access control for ALB or NLB instances by adding them to security groups. For more information, see Add an ALB instance to a security group and Add an NLB instance to a security group.
CLB supports access control lists (ACLs) for listeners. ACLs can work as whitelists or blacklists. You can configure whitelists or blacklists for different listeners:
Whitelist: Only requests from the IP addresses or CIDR blocks in the ACL are forwarded. Whitelists apply to scenarios in which you want to allow requests only from specific IP addresses.
Blacklist: All requests from the IP addresses or CIDR blocks on the blacklist are denied. Blacklists apply to scenarios in which you want to block access from specific IP addresses.
Custom TLS security policies
For Layer 7 load balancing, ALB provides some commonly used TLS security policies to enhance the security of services that use HTTPS. ALB also allows you to configure custom TLS security policies. For example, you can specify the TLS versions that you want to use, or disable certain TLS cipher suites.
For Layer 4 load balancing scenarios that require SSL offloading for TCP traffic, NLB provides some commonly used TLS security policies to enhance the security of services. You can select system TLS security policies or configure custom TLS security policies to protect your application system.
NoteCLB does not support custom TLS security policies.
Mutual authentication
In HTTPS scenarios, standard and WAF-enabled ALB instances, NLB instances, and CLB instances support mutual authentication, which helps your application system meet security compliance requirements. In SSL offloading for TCP traffic scenarios, NLB supports mutual authentication to improve communication security. For more information, see Configure mutual authentication on an HTTPS listener, Use NLB to enable SSL offloading over TCP (mutual authentication), and Configure mutual authentication on an HTTPS listener.
Work with the SLB service
When you work with the SLB service, pay attention to the key observability metrics.
Key observability metrics
Monitoring
If your application system encounters network connectivity issues, such as requests timeouts and traffic throttling, or you need to learn about the workloads on your SLB instance, you can view the monitoring metrics of your SLB instance. For more information, see NLB monitoring metrics, ALB monitoring metrics, and CLB monitoring metrics.
Logging
SLB supports operation and access logs. For more information, see ALB logs, NLB logs, Access logs, and View operation logs.
The operation log records operations performed on the SLB instance.
The access log records the detailed information about requests sent to the Layer 7 SLB instance, including the request time, client IP address, latency, request path, and server response time. You can analyze the access log to learn about the behaviors and geographical distribution of clients and perform troubleshooting.
NIS
In addition to the monitoring and logging features of NLB, ALB, and CLB, we recommend that you enable NIS to improve the observability of your application delivery network.
Best practices
As described in the preceding section, ALB and NLB supports higher performance, stability, scalability, security, and observability. Among CLB, ALB, and NLB, we recommend that you use ALB or NLB to build an application delivery network. The following best practices describe some solutions to building an application delivery network in four different scenarios.
Intra-region application delivery network
In an intra-region application delivery network, the SLB instance and backend servers are in the same region.
Layer 4 SLB
Key design:
Stability
Select at least two zones for your NLB instance and deploy the NLB instance and backend servers in the same zones.
You can disable cross-zone forwarding for the NLB instance.
Determine whether you need to enable throttling on new connections based on your business requirements. Throttling on new connections can prevent avalanche effect caused by unexpected traffic spikes.
We recommend that you enable health checks for backend servers.
Performance
We recommend that you associate Internet-facing NLB instances with Internet Shared Bandwidth instances and select a proper metering method between pay-by-dominant-traffic and pay-by-bandwidth based on your traffic pattern.
Security
Determine whether you need to add your NLB instance to a security group based on the security requirements of your application system. If you use a TCP/SSL listener, determine whether you need to use a custom TLS security policy and whether you need to enable mutual authentication.
Layer 7 SLB
key design:
Stability
Select at least two zones for your ALB instance and deploy the ALB instance and backend servers in the same zones.
Determine whether you need to enable QPS throttling to prevent avalanche effect caused by unexpected traffic spikes.
We recommend that you enable health checks for backend servers.
Performance
We recommend that you associate Internet-facing ALB instances with Internet Shared Bandwidth instances and select a proper metering method between pay-by-dominant-traffic and pay-by-bandwidth based on your traffic pattern.
Security
Determine whether you need to add your NLB instance to a security group, configure a custom TLS security policy, and enable mutual authentication based on the security requirements of your application system.
Inter-region application delivery network
In an inter-region application delivery network, the SLB instance and backend servers are in different regions.
As shown in the following figure, the inter-region application delivery network is built based on NLB or ALB. The application delivery network supports nearby access and cross-region disaster recovery. For more information about how to deploy an inter-region application delivery network, see Specify an ECS instance in a VPC as a backend server of ALB in a different region and Add backend servers in VPCs to NLB across regions.
IPv6 application delivery network
Select an SLB service
If you want to use SLB to build an IPv6 application delivery network, we recommend that you select an SLB service based on the scenario, such as end-to-end communication over IPv6 and IPv6-to-IPv4 conversion.
Scenario 1: End-to-end communication over IPv6
NLB and ALB support IPv6 backend servers. IPv6 requests are forwarded to backend servers over IPv6 to enable end-to-end IPv6 communication. CLB does not support IPv6 backend servers.
Scenario 2: IPv6-to-IPv4 conversion
NLB, ALB, and CLB support IPv6-to-IPv4 conversion. IPv6 requests are forwarded to backend servers over IPv4. This way, the application system supports access from IPv6 requests.
Because NLB and ALB support both end-to-end communication over IPv6 and IPv6-to-IPv4 conversion, we recommend that you select NLB or ALB to build an IPv6 application delivery network.
In addition, NLB and ALB provide dual-stack instances that support both IPv4 and IPv6 addresses. You can such dual-stack NLB or ALB instances to build an application delivery network that supports both IPv4 and IPv6. CLB does not support dual-stack instances. If you want your application delivery network to support both IPv4 and IPv6, you need to create an IPv4 instance and an IPv6 instance. We recommend that you select NLB or ALB, which supports simplified architectures for application delivery networks.
Deploy the SLB service
When you deploy an IPv6 application delivery network, we recommend that you focus on stability, security, scalability, observability, and self-service capabilities.
End-to-end communication over IPv6
Step 1: Enable IPv6 for the VPC of the NLB or ALB instance.
Step 2: Create a dual-stack NLB or ALB instance.
Step 3: If you want the IPv6 address of your NLB or ALB instance to have Internet access, enable Internet bandwidth for the IPv6 address on the IPv6 gateway of the VPC in which the NLB or ALB instance is deployed.
Step 4: Create a server group for the NLB or ALB instance and enable IPv6.
IPv6-to-IPv4 conversion
Deploy the NLB or ALB instance
Step 1: Enable IPv6 for the VPC of the NLB or ALB instance.
Step 2: Create a dual-stack NLB or ALB instance.
Step 3: If you want the IPv6 address of your NLB or ALB instance to have Internet access, enable Internet bandwidth for the IPv6 address on the IPv6 gateway of the VPC in which the NLB or ALB instance is deployed.
Step 4: Create a server group for the NLB or ALB instance. You do not need to enable IPv6.
Deploy the CLB instance
Create an IPv6 CLB instance. Only Internet-facing CLB instances support IPv6. Complete the configurations of the CLB instance.