Advanced traffic management

Max connections

Use the max connections configuration to limit the maximum number of concurrent connections for a given front-end virtual port. If you do not configure a value, the system uses a default of 2000 concurrent connections. The maximum concurrent connections for a given front-end virtual port, or system-wide across all front-end virtual ports, is 15000.

Session persistence

By default, an ALB forwards received requests to a back-end server based on the configured load-balancing method. You can enable session persistence to ensure that a client remains connected to the same back-end server throughout a session.

HTTP keep alive

Application Load Balancer for VPC supports HTTP keep alive when it is enabled on both the client and back-end servers. The load balancer attempts to reuse the server-side HTTP connections to increase connection efficiency and reduce latency.

TCP keep alive

Application Load Balancer for VPC supports TCP keep alive. With this setting, the load balancer sends TCP-keep-alive packets to both client and back-end servers every 5 seconds.

This is a socket-level packet with no data that is sent to the peer to notify it that the host is alive. As such, it is seen only at the network layer, and not at the application level. This setting also helps to prevent the disconnection of TCP connections by an intermediate proxy or firewall that might have policies that discard connections after a certain period of inactivity.

Connection timeouts

The following timeout values are used by an ALB. Currently, only the client-side and server-side idle timeout values in the following table are custommizable.

Preserving end-client IP address (HTTP/HTTPS only)

Application Load Balancer for VPC works as a reverse proxy, which terminates incoming traffic from the client. The load balancer establishes a separate connection to the back-end server instance by using its own IP address. For HTTP connections with the back-end servers (against front-end HTTP or HTTPS connections), the load balancer preserves the original client IP address by including it inside the X-Forwarded-For HTTP header. For TCP connections, the original client IP information is not preserved.

Preserving end-client protocol (HTTP/HTTPS only)

An ALB preserves the original protocol that is used by the client for front-end HTTP and HTTPS connections by including it inside the X-Forwarded-Proto HTTP header. This does not apply to TCP protocol since an ALB does not look at Layer-7 traffic when TCP protocol is used.

Enabling private load balancer enforcement

Private load balancer enforcement prevents public load balancers from being created. This ensures only non-internet clients, or clients from within your network environment, can access your load balancers. When enabled, a restriction is placed on your account to prevent the creation of floating IPs on all ALBs.

To implement private load balancer enforcement, open an IBM Support case and reference your need to alter your account to restrict the creation of floating IPs. After IBM processes the change, you will no longer be able to create public load balancers.

Private load balancer enforcement applies for all regions when enabled.

HTTP/2 support for clients connecting to HTTPS listeners

Application Load Balancer for VPC uses Application-Layer Protocol Negotiation (ALPN) to negotiate with clients connecting to HTTPS listeners, and supports both HTTP/1.1 and HTTP/2. If the client connecting to the ALB is using HTTP/2, then the ALB also uses HTTP/2 as its preferred protocol, and processes the request to the back-end pool. Otherwise, HTTP/1.1 is chosen by default.

The HTTP/2 protocol is not yet supported for back-end pools. However, HTTP and HTTPS protocols are supported.

Compression (HTTP/HTTPS only)

HTTP/HTTPS compression allows you to compress the data being transmitted to your users using gzip.

To compress transmitted data with an ALB, the request header must contain Accept-Encoding: gzip and its MIME type must be either text/html, text/plain or text/xml.

Enabling proxy protocol

You can enable proxy protocol for TCP, HTTP, and HTTPS listeners and back-end pools. Use cases are as follows.

Use case 1: Client connects to load balancer directly

If the ALB is receiving traffic from a client directly, enabling the proxy protocol for the back-end pool of that listener configures the load balancer to attach the proxy protocol header to the TCP packets being sent to that back-end pool.

All back-end members of that pool must support proxy protocol for the data path to work. You can choose the version of proxy protocol header (version 1 or version 2) when enabling this setting. This setting is disabled by default if not specified. With this setting, the back-end servers can get the client IP and port information that the load balancer sets in the proxy protocol header.

Use case 2: Client connects to a proxy or proxy chain, which then connects to the load balancer using proxy protocol

If the Application Load Balancer for VPC is receiving traffic from a proxy (or a proxy chain) that uses proxy protocol, the listener must have proxy protocol that is enabled so that it can parse the origin client information that is contained in the proxy protocol headers. This setting is disabled by default, if not specified. Because the load balancer can detect the version of the proxy protocol header and parse it correctly, you don't have to specify which version of proxy protocol is being used to send traffic to the ALB.

When proxy protocol is enabled for a front-end listener, all traffic coming to that front-end port is expected to be proxy protocol traffic. If any of the connections do not contain the proper proxy protocol headers, they won't be established. To forward this client information to the back-end server pool, you must enable proxy protocol for the pool. Similar to use case 1, you must select version 1 or version 2 depending on what version of proxy protocol the back-end servers are configured to use. You can also choose to not forward this client information to the back-end servers if they are not capable of processing this information, and this information is dropped at the load balancer.