Load balancers for VPC overview
IBM Cloud® provides two families of load balancers for VPC, Application Load Balancer for VPC (ALB) and Network Load Balancer for VPC (NLB).
Types of load balancers
Several differences exist between the various types of load balancers.
Application load balancers
IBM Cloud provides public- and private-facing ALBs that support Secure Sockets Layer (SSL) offloading. An ALB provides layer 7 and layer 4 load balancing on IBM Cloud, but ALBs are primarily intended for layer 7, web-based workloads. ALBs support virtual server instances, bare metal server instances, and Power Systems Virtual Server instances connected over IBM Cloud Direct Link as back-end pool members. For more information, see About application load balancers.
Network load balancers (public and private)
In contrast to ALBs, an NLB provides only layer 4 load balancing on IBM Cloud, and does not support SSL offloading. The client sends public network traffic to the NLB, which forwards it to target virtual servers. Then, these virtual servers respond directly to the client by using Direct Server Return (DSR). NLBs are primarily intended for workloads that require low latency and high data throughput.
This gives network load balancers an advantage over ALBs by enhancing performance in the following ways:
- The return traffic from the target server bypasses the NLB and responds directly to the client.
- The NLB processes incoming traffic, which allows it to be a fast distributor of traffic/load.
- Public and Private NLBs have a single, highly available virtual IP (VIP) that can be used directly, instead of through an assigned fully qualified domain name (FQDN). This VIP helps clients that must use an IP to access the application or service that is served by the load balancer. It also allows for faster failure recovery compared to the DNS-based availability of application load balancers.
Network Load Balancer for VPC supports these load-balancer configurations: public, private, Private Path, and private-type with routing mode enabled. For more information, see About network load balancers.
Use Figure 1 to help you (the User) choose the right load balancer for your requirements.
Private Path network load balancers
The beta release of IBM Cloud Private Path services is only available to allowlisted users. Contact your IBM Support representative if you are interested in getting early access to this beta offering.
Private Path NLBs are required when service consumer and service provider reside an different VPCs and there is a need to keep network traffic on a private path that never intersects with the public internet. These load balancers offer a high level of fault tolerance including resilience to a zone failure, and are highly scalable (millions of requests/second) and performant.
A consumer's ability to access a Private Path NLB requires creation of a VPE which is gated by the provider's approval in a Private Path service. So provider has granular control over who may access their service.
For more information, see the Private Path solution guide.
Load balancer comparison chart
The following table provides a comparison of the types of load balancers.
| Feature | Application load balancer (Public/Private) |
Network load balancer (Public/Private) |
Network load balancer (Private Path) |
|---|---|---|---|
| HA mode | Active-Active (with multiple virtual IPs (VIPs) assigned to a DNS name) | Active-Standby (with single VIP) | Active-Active (Regional HA) |
| Instance group support | Yes (see Integrating an ALB for VPC with instance groups) | No | No |
| Monitoring metrics | Yes | Yes | No |
| Multi-zone support | Yes | Limited [1] (see Multi-zone support) | Yes |
| Security group support | Yes (see Integrating an ALB for VPC with security groups) | Yes (see Integrating a network load balancer with security groups | No. Access control is through a Private Path service |
| Source IP address is preserved | Yes, with proxy protocol | Yes | No |
| SSL offloading | Yes | No | No |
| Supported protocols | HTTPS, HTTP, TCP | TCP, UDP | TCP |
| Transport layer | Layer 4, Layer 7 | Layer 4 | Layer 4 |
| Virtual IP address (VIP) | Multiple | Single | N/A |
| Routing mode for VNFs | No | Yes (see About virtual network functions over VPC) | No |
| Virtual servers on VPC | Yes | Yes | Yes |
| Member type | Virtual server instances, Bare Metal, Power Systems Virtual Server | Virtual server instances | Virtual server instances |
| Power Systems Virtual Server instances connected over Direct Link | Yes (No support for instance groups) | No | No |
| Port range | No | Public only [2] | Yes |
| Scalable to many machines | Yes | No | Yes |
For more information, such as load balancer architecture, methods, and use cases, see About application load balancers and About network load balancers.
High Availability mode
The application load balancer is configured in active-active mode. All compute resources of the load balancer are actively involved in forwarding traffic.
High Availability (HA) is achieved by using a Domain Name Service (DNS). The VIP of each compute resource is registered to the assigned DNS. If any of the compute resources go down, the other resources continue to forward traffic.
An NLB is configured in active-standby mode. A single VIP is registered with DNS, and traffic is forwarded through that compute resource. If an active compute resource goes down, the standby takes over and the VIP is transferred to the standby.
A Private Path NLB instance runs in all zones where members are configured and can serve traffic as long as there are healthy members in any of the zones.
Multi-zone support
Public and Private: Public and Private Network load balancers can accept members across all three availability zones, but the NLB itself resides in one specific zone. A zone is identified by the subnet that is selected when a load balancer is created. Cloud Internet Services (CIS) Global Load Balancer or Private DNS can be used with multiple zonal network load balancers for multi-zone availability.
The application load balancer can also be configured to span multiple zones. The back-end servers can be in any zone within a region.
A Private Path NLB can accept members in all three zones and can serve traffic as long as there are healthy members (no matter in which zone). Even if the zone holding the subnet defined for the Private Path NLB is down, the load balancer remains up and able to serve traffic to members in other zones.
Integration with private catalogs
ALBs and NLBs both integrate with private catalogs to centrally manage access to products in the IBM Cloud catalog and your own catalogs. You can customize your private catalogs to allow or disallow load balancer provisioning to specific users in your account. For more information, see Customizing what's available in your private catalogs.
Pricing metrics
ALB's and NLB's determine their pricing based on the following metrics.
Instance hours per month: Measures the number of hours ALB or NLB is used per calendar month.
Data processed: Measures how much data, in gigabytes (GB), that is processed by ALB or NLB in a calendar month.