About application load balancers
Use IBM Cloud® Application Load Balancer for VPC (ALB) to distribute traffic among multiple server instances within the same region of your VPC.
If you have public and private workloads and layer 7 traffic, use an application load balancer.
Types of application load balancers
As discussed in the Load balancers for VPC overview, you can create a public or private ALB. Table 1 shows a comparison of public versus private features.
| Feature | Public load balancer | Private load balancer |
|---|---|---|
| Accessible on internet? | Yes, with a fully qualified domain name (FQDN) | No, internal clients only, on same region and VPC |
| Accepts all traffic? | Yes | Yes (The restriction to accept traffic only from the RFC-1918 address space has been removed) |
| How is domain name registered? | Public IP addresses | Private IP addresses |
Public application load balancer
A public application load balancer service instance is assigned a publicly accessible fully qualified domain name (FQDN), which you must use to access your applications that are hosted behind the load balancer. This domain name can be registered with one or more public IP addresses.
Over time, the number and value of these public IP addresses might change due to maintenance and scaling activities. The back-end virtual server instances hosting your application must run in the same region and under the same VPC.
Use the assigned FQDN to send traffic to the public application load balancer to avoid connectivity problems to your applications during system maintenance or scaling down activities.
Private application load balancer
A private application load balancer is accessible through your private subnets that you configured to create the load balancer.
Similar to a public application load balancer, your private application load balancer service instance is assigned an FQDN. However, this domain name is registered with one or more private IP addresses.
IBM Cloud operations might change the number and value of your assigned private IP addresses over time, based on maintenance and scaling activities. The back-end virtual server instances hosting your application must run in the same region, and under the same VPC.
Use the assigned FQDN to send traffic to the private application load balancer to avoid connectivity problems to your applications during system maintenance or scaling down activities.
Load-balancing methods
Three load-balancing methods are available for distributing traffic across the back-end application servers:
Round-robin
Round-robin is the default load-balancing method. With this method, an application load balancer forwards incoming client connections in round-robin fashion to the back-end servers. As a result, all back-end servers receive roughly an equal number of client connections.
Weighted round-robin
With this method, an application load balancer forwards incoming client connections to the back-end servers in proportion to the weight assigned to these servers. Each server is assigned a default weight of 50, which can be customized
to any value in the range 0 - 100.
For example, if application servers A, B and C have the weights 60, 60, and 30, then servers A and B receive an equal number of connections, while server C receives half that number of connections.
Setting a server weight to 0 means that no new connections are forwarded to that server, but any existing traffic continues to flow. Using a weight of 0 can help bring down a server gracefully and remove it from service
rotation.
The server weight values are applicable only with the weighted round-robin method. They are ignored with round-robin and least-connections load-balancing methods.
Least connections
With this method, the back-end server instance that serves the least number of connections at a given time receives the next client connection.
Front-end listeners and back-end pools
Front-end listeners are load balancer application ports for receiving incoming requests, while back-end pools are the application servers behind the load balancers.
Guidelines for using listeners
Review the following guidelines for front-end listeners:
- You can define up to 10 front-end listeners and map them to back-end pools on your back-end application servers.
- The FQDN assigned to your load balancer and the front-end listener ports are exposed to the public internet. Incoming user requests are received on these ports.
- The supported front-end listener and back-end pool protocols are HTTP, HTTPS, and TCP.
- You can configure an HTTP/HTTPS front-end listener with an HTTP/HTTPS back-end pool.
- HTTP/2 is supported for listeners only.
- HTTP and HTTPS listeners and pools are interchangeable.
- You can only configure a TCP front-end listener with a TCP back-end pool.
- You can attach up to 50 virtual server instances to a back-end pool. Traffic is sent to each instance on its specified data port. This data port does not need to be the same one as the front-end listener port.
- "Private only" endpoints for Secrets Manager are not supported with HTTPS listeners. To configure an HTTPS listener in an ALB, you must upload your TLS certificates to a "Public and private" endpoint.
HTTPS redirect listener
HTTPS redirect listeners redirect the traffic from an HTTP listener to an HTTPS listener. This action does not require any rules applied on the listener.
For instance, if a service listens on port 443 with HTTPS and a user tries to access the service on port 80 using HTTP, then the request automatically redirects to port 443 with HTTPS.
If policies are present on the HTTPS redirect listener, then the policies are evaluated first. If there are no policy matches, then the request redirects to a configured HTTPS listener.
HTTPS redirect listener properties
| Property | Description |
|---|---|
| Listener | The HTTPS listener to which a request redirects. |
| HTTP status code | Status code of the response returned by the application load balancer. The acceptable values are: 301, 302, 303, 307, or 308. |
| URI | The relative URI to which a request redirects. This is an optional property. |
Elasticity
The application load balancer scales out by adding compute resources when load increases.
SSL offloading and required authorizations
Secure Sockets Layer (SSL) offloading allows the application load balancer service to terminate all incoming HTTPS connections.
When an HTTPS listener is configured with an HTTP pool, the HTTPS request is terminated at the front-end and the load balancer establishes a plain-text HTTP communication with the back-end server instance. With this technique, CPU-intensive SSL handshakes and encryption or decryption tasks are shifted away from the back-end server instances, allowing them to use all their CPU cycles for processing application traffic.
SSL offloading requires you to provide an SSL certificate for the application load balancer to perform SSL offloading tasks. You can manage the SSL certificates through the IBM Cloud Secrets Manager.
You can create an authorization through IAM Authorizations. Make sure to choose VPC Infrastructure Services as the Source service, then select Specific resources. Click Select an attribute and choose Resource type from the list. Select Load Balancer for VPC as the resource type and click Next. For the Target service, select Secrets Manager. Set the Target service instance access to All instances or to your specific IBM Cloud Secrets Manager instance. Assign the Writer service access role. For more information, see Granting access between services.
To prevent errors, you must establish the required authorization between your load balancer and IBM Cloud Secrets Manager. In addition, updating certificates in Secrets Manager does not automatically update your ALB. For your load balancer to reflect any changes in the certificate, make a small update (such as changing the health check interval or timeout value) to cause a refresh. This action will update the certificate on your load balancer to match the certificate in Secrets Manager. You can then revert any changes that you made back to their original values.
Transport Layer Security (TLS) 1.2 and 1.3 are supported. However, TLS 1.3 is used by default unless you specifically configure the client side to utilize 1.2. Application load balancers honor all supported TLS 1.3 ciphers sent by the client-side request.
The following lists the supported ciphers (in order of precedence):
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Locating the certificate CRN
When configuring authentication for an application load balancer during provisioning in the UI, you can choose to specify the Secrets Manager and SSL certificate, or the certificate's CRN. You might want to do this if you cannot view the Secrets Manager in the drop-down menu, which means you don't have access to the Secrets Manager instance. Keep in mind that you must enter the CRN if using the API to create an ALB.
To obtain the CRN, you must have permission to access the Secrets Manager instance.
To find a certificate's CRN, follow these steps:
- In the IBM Cloud console, go to Navigation Menu icon
> Resource list. - Click to expand Services and software, then select the Secrets Manager that you want to find the CRN for.
- Select anywhere in the table row of the certificate to open the Certificate details side panel. The certificate CRN is listed.
End-to-end SSL encryption
Configuring an HTTPS listener with an HTTPS pool enables end-to-end SSL encryption. The application load balancer service terminates the incoming HTTPS request at the front-end listener and establishes an HTTPS connection with the back-end instances. End-to-end encryption allows all traffic going through the load balancer to the back-end members to be encrypted over HTTPS.
To configure end-to-end SSL encryption:
- Configure an HTTPS front-end listener with your SSL certificate as you would when configuring SSL offloading.
- Configure an HTTPS back-end pool.
- Add your back-end member instance to the HTTPS back-end pool. Ensure that your back-end member instances are configured to handle HTTPS traffic.
- Configure health check with type HTTPS to perform encrypted health checks with your back-end members.
An application load balancer does not verify the SSL certificates of the back-end member instances.
Horizontal scaling
An application load balancer adjusts its capacity automatically according to the load. When this adjustment occurs, you might see a change in the number of IP addresses associated with the load balancer's DNS name.
MZR support
IBM Cloud Application Load Balancer for VPC supports Multi-Zone-Regions (MZRs). You can achieve high availability and redundancy by deploying an application load balancer with subnets from different zones. When subnets from multiple zones are used to provision an application load balancer, the load balancer appliances get deployed to multiple zones.
Integration with instance groups
IBM Cloud Application Load Balancer for VPC integrates with instance groups, which can auto scale your back-end members. Pool members are dynamically added and deleted based on your usage and requirements.
Datapath log forwarding
With datapath logging enabled, load balancer logs are forwarded to the IBM Log Analysis service, where you can view your datapath logs.
HTTP2 support
Application load balancers support end-to-end HTTP2 traffic, and works with listener protocols set as either HTTPS or TCP.
WebSocket support
WebSocket provides full-duplex communication channels over a single TCP connection. Application load balancers support WebSocket with every type of listener protocol (HTTP/HTTPS/TCP).
Architecture
Figure 1 illustrates the deployment architecture for the ALB.
In this diagram, "Client Resources" represents the resources (VPCs and subnets, for instance) that belong to the client ecosystem.
High Availability and Application Load Balancers
To ensure that High Availability (HA) works with your ALB, you should attach three subnets from different zones to the ALB and deploy appliances across these zones. To do this, you will choose your subnets during the ALB creation process. You
may select two subnets in different zones (such as, us-south-1 and us-south-2). Doing so creates the ALB's IPs (such as the appliance IPs) in two different subnets.
You can also do this with already existing ALBs. Go to the Attached Resources section on your load balancer details page. From the Subnet section, click Edit subnets. You can now attach additional subnets. Once you do, the ALB will go into the “Migrating” state. When the migration completes, you will get a new IP for the appliance from the subnet you just attached. You now have two IPs from different subnets in different Zones.