LB is designed for layer-7 (application layer) load balancing scenarios. While providing high-performance traffic distribution, it supports content-based advanced routing, flexible protocol adaptation, and deep integration with the cloud-native ecosystem. It is widely applicable to diverse business scenarios such as Web services, microservices, and containerized applications.
Traffic Distribution and Intelligent Scheduling for High-Concurrency Web Services
For business scenarios with sudden traffic surges, such as flash sales on e-commerce platforms, peak enrollment periods for online education, and new season launches for interactive entertainment, a single ALB instance can handle millions of queries per second (QPS) and tens of millions of concurrent connections. It evenly distributes client requests to multiple real servers, avoiding response delays caused by single-point overload. If a real server becomes abnormal, ALB automatically identifies and quickly isolates the faulty node by using the health check feature, and redirects its traffic to other healthy instances. This process requires no manual intervention and helps ensure business continuity. If your business is deployed across multiple availability zones (AZs), we recommend that you bind the ALB instance to real server groups that can be used across AZs. This enables AZ-level disaster recovery at the backend layer and further improves service stability.
Unified Traffic Entry for a Microservices Architecture
In a microservices architecture, multiple services often need to expose independent access endpoints for external use. In most cases, the traditional solution allows you to configure a separate load balancing instance for each service, resulting in scattered resources and high Ops costs. ALB implements fine-grained forwarding rules based on multi-dimensional conditions such as the domain name, URL path, HTTP Header, Query String, and Cookie. A single ALB instance can handle the traffic entry requirements of dozens or even hundreds of microservices. For example, you can configure api.example.com/user to forward traffic to the user service and api.example.com/order to forward traffic to the order service. You may also route traffic to service instances of different versions based on the version number contained in the request header. Compared with provisioning a separate load balancing instance for each service, this solution reduces the number of instances, helping you simplify the architecture while lowering Ops complexity.
Full-Site HTTPS Security Transformation and Protocol Upgrade
As security compliance requirements become increasingly stringent, more and more web services need to be migrated from HTTP to HTTPS to ensure data transmission security. ALB allows you to configure redirect rules on listeners to automatically redirect HTTP requests to the corresponding HTTPS listener to complete full‑site encryption transformation without the need to modify backend application code. You can choose different status codes such as 301 (permanent redirect) and 302 (temporary redirect) based on your business requirements. ALB also supports differentiated redirect policies based on conditions such as the path and HTTP Header. For example, you can enforce HTTPS only for sensitive paths such as /login and /payment and keep HTTP access for other paths. In addition, ALB supports the TLS 1.3 encryption protocol and SNI‑based multi‑domain certificate management across the full link. A single listener can be associated with multiple SSL certificates, easily meeting deployment requirements for large‑scale multi‑domain HTTPS services.
Auto Scaling for Cloud-Native Containerized Services
For containerized applications orchestrated by Kubernetes, ALB serves as an Ingress gateway and can be deeply integrated with Tencent Kubernetes Engine (TKE). It supports declarative routing rule definition by using Ingress resources, providing unified layer-7 traffic entry control for containerized applications. When the number of replicas is dynamically adjusted for your business via Auto Scaling (AS) or Horizontal Pod Autoscalers (HPA), ALB automatically detects backend Pod changes and updates forwarding policies in real time. Newly started Pods are automatically added to the load balancing pool, while Pods reclaimed during scale‑in are automatically removed. The entire process is largely unaware to frontend requests. Canary Release and Seamless Transition for New Versions
For businesses that are highly sensitive to release risks, such as financial systems and payment cores, full rollout of a new version may cause unpredictable impacts. ALB supports precise control over the traffic ratio between new and earlier versions based on the server group weight allocation or forwarding rules of Header/Cookie, implementing canary releases. For example, you can use ALB to first route 5% of traffic to the new version for validation and observation based on the X-Version: canary in the request header. After confirming that the new version is stable, you can gradually increase the ratio until all traffic is switched. If an exception is detected, quickly roll back to the earlier version by adjusting the rules. End users remain largely unaware throughout the entire process. This progressive release mechanism significantly reduces version iteration risks and is suitable for production environments that require frequent updates and continuous business availability.