The IONOS Managed Application Load Balancer routes incoming application layer traffic to targets based on user-defined rules.

Developer Tools

Product Overview

How-To's

API Reference

Create a flow log

1. In the Inspector pane, open the Settings tab.

2. To activate flow logs, open the Flowlog drop-down and fill in the following fields:

• Name: Enter a name for the flow log rule. The name will also be the first part of the objects' name prefix.

• Direction: Choose Ingress to create flow logs for incoming traffic, Egress for outgoing traffic, or Bidirectional to create flow logs for all traffic.

• Action: Choose Rejected to capture only traffic blocked by the firewall, Accepted to capture only traffic allowed by the firewall, or Any for all traffic.

• Target S3 bucket: Enter a valid existing IONOS S3 Object Storage bucket name and an optional object name prefix where flow log records should be written.

• Add flow log: To complete the configuration of the flow log. It becomes applied once you provision your changes.

As a result, an activated flow log rule is indicated by a green light in the properties of the NIC. A green light indicates that the configuration has been validated and is valid for provisioning.

3. Select PROVISION CHANGES. After provisioning is complete, the network interface flow logs are activated.

Delete a flow log

1. In the Inspector pane, open the Settings tab.

2. Open the Flowlog drop-down.

3. Select the trash bin icon to delete the flow log.

4. In the confirmation message, select OK.

Select PROVISION CHANGES. After provisioning is complete, the network interface's flow logs are deleted and no longer captured.

The Managed Application Load Balancer (ALB) distributes incoming application layer traffic to targets based on user-defined policies. Each load balancer is defined by a Listener, which processes forwarding rules and routes traffic to targets. Targets are selected via the round-robin method.

Unlike Network Load Balancer (NLB), which operates at Layer 4 of the OSI model, ALB operates at Layer 7. If your balancing logic needs to process HTTP requests and their attributes, use ALB. If routing performance is critical, limit the logic to Level 4 and route TCP traffic using NLB.

ALB can be used in two ways:

• Public load balancing: The Listener is open and accepts client connections directly from the Internet. ALB serves as an edge device that handles north-south traffic in and out of the data center.

• Private load balancing: The Listener is on a private network and handles east-west traffic inside the data center.

Features

• Advanced Routing: ALB supports a wide range of advanced routing options when it comes to configuring Forwarding Rules. Routing for incoming requests can be based on the HTTP method, HTTP header, hostname, path, or a query string parameter. This is not limited to request forwarding based on a load balancing algorithm.

• Supported protocols: HTTP

• Available ports: 1 - 65,535

• Fixed Response: It is also not always unavoidable to forward traffic only to preconfigured targets. ALB can be configured to return a fixed response or redirect to another host. This is a very convenient option for customers who wish to avoid setting up a separate machine to perform such trivial tasks.

• Health Checks: ALB also carries out periodic checks that monitor registered targets before redirecting traffic to them. This feature is optional, but it improves the overall performance and makes the entire architecture redundant and highly available.

• Flow Logs: This feature allows you to capture data related to IPv4 network traffic flows. They can help with monitoring, debugging, and logging data. Flow logs are stored in an IONOS S3 Object Storage bucket.

• High Availability: This feature refers to the ability of the application load balancer to handle increased traffic and provide reliable and consistent performance, even in the event of a single component failure. It ensures that the service is always available, even in the case of component failures or maintenance.

Architecture

Each ALB requires at least one Listener, a Forwarding Rule, and a Target Group. A Listener is a process that checks for connection requests using the protocol and port that you configure. Each Listener is defined by Forwarding Rules, which determine how ALB routes requests to its registered targets inside the Target Groups.

Listener

The Listener accepts connections from clients through a public IP address (primary IPv4) and a configured port. This process can also listen for additional IP addresses. Listener IP addresses can be private (for the local network) or public (available on the Internet).

• Public IP Listener: A public IP address is required for an ALB connected to the Internet.

• Private IP Listener: No input is required to assign the first (primary) listener IP address. The listener's private primary IP address will be assigned automatically during provisioning.

You can configure each Listener by defining specific Forwarding Rules. The rules you set determine how ALB routes requests to its registered targets. Each rule consists of a priority, one or more actions, and one or more conditions. There must be a default rule action, so if none of the other conditions of the rule are met, the action for the default rule is executed. The default rule is evaluated last.

Target Group

A target group is a set of one or more registered targets. For each target, you must specify an IP address, port number and weight. Any object with an IP address in your VDC can be a target, such as a VM, another load balancer, etc.

You may create multiple target groups for convenience and reuse them to configure different ALB forwarding rules. You can register the same target with multiple target groups. You can also enable Proxy Protocol to preserve and send the client IP details.

Health Checks

A Health Check is a periodical query to a registered target to test its current status. Checks are performed to ensure that traffic is only forwarded to active and healthy targets.

• TCP Health Check: This check attempts to establish a TCP connection on the configured backend port. Targets are polled at regular intervals. If the target does not respond, the health check fails, and the target is removed from the balancing rotation. If the target resumes responding, it is included in the rotation again.

• HTTP Health Check: ALB periodically sends HTTP requests to registered targets to check their status.

Health Check properties

You can set up Health Checks for each registered Target Group. Although Health Check settings are properties of Target Groups, it is the ALB that performs them once the Target Group is bound to the Forwarding Rule. Health Checks have three parameters that are configurable by users: Retries, Check Timeout, and Check Interval.

Check Timeout is the amount of time the ALB waits for a TCP connection to open. This value depends on the type of health checks used. The Check Timeout for the ALB HTTP health check actually sets two timeouts: the timeout to open a TCP connection to the target, and the timeout to receive an HTTP response from the target after the TCP connection is established.

Check Interval is the time in ms that the ALB waits after a health check is completed and before sending the next one. If the check interval is less than the check timeout, then the check timeout is equal to the check interval.

How are Health Checks conducted?

Health Checks are synchronous; the next check only starts after the previous ones have been completed. This means that the time between the start of two checks can be divided into two consecutive phases: Check Duration and Check Interval. The Check Interval phase always starts only after the end of the Check Duration phase. The Check Duration phase ends if either the expected response is received from the target within the check timeout period, or if the Check Timeout is reached.

Thus, the check duration depends on the performance of the target and may vary over time. This means that depending on the target state, the frequency of checks may change over time.

For ALB, the check duration is limited by the Check Timeout parameter. For TCP health checks, the maximum check duration is equal to the check timeout. For HTTP health checks, the maximum possible check duration is twice the check timeout - one timeout to open a TCP connection and one timeout to receive an HTTP response from the target.

Maintenance Window

The managed ALB will be regularly maintained by IONOS and updated with the latest software versions and new features. IONOS reserves a weekly maintenance window, which it can use for regular updates. It is scheduled every Monday between 02:00 and 04:00 am local time of the data center in which the Managed Application Load Balancer service is deployed. During maintenance, a service interruption of up to 5 seconds may occur. Aside from that service interruption, no further service impact is anticipated, and the Managed Application Load Balancer will continue to operate within its service description and configuration.

Additional update deployments may be possible and carried out outside the maintenance window, for example, in the case of urgent security patches.

Limitations

Each Application Load Balancer must have at least one Listener and supports up to 10 Listeners.

ALB is not configured to support Source NAT (SNAT). Therefore, targets cannot initiate network connections through the load balancer.

Configure ALB settings

1. Add an ALB element by dragging it to the workspace.

2. Connect the northern interface to Internet Access and the southern interface to a target Server.

3. To configure the ALB Settings, select the Settings tab from the right side and provide the following information:

   • Name: Enter a name for the ALB.

   • Primary IPv4: Use a public IP you have previously reserved for public load balancing. For private load balancing, a private IP address will be assigned automatically upon provisioning. Otherwise, you may always enter a separate private IP.

   • Add IP: Add additional public or private IP addresses. It is an optional field.

Add Forwarding rules

Forwarding rules define how client traffic is distributed to the targets. More than one rule can be created for the same load balancer. In the Inspector pane on the right side, select the Forwarding rules tab. To add Forwarding rules, select +Add forwarding rule option and fill in the following fields:

• Name: Enter a unique name for the forwarding rule.

• Protocol: This field is preset and defines how data is transmitted between devices. The default value is set to HTTP.

• Listener IP: Assign an IP address to the listener interface.

• Listener port: Select the HTTP port on which the listener will accept client requests.

• Client timeout: The default value is set to 50000 milliseconds(ms). This idle timeout is applied when the client is expected to acknowledge or send data. Client time is the duration in which the ALB will not break the TCP connection established with the client, after which the connection is terminated, provided that the client does not send any subsequent requests during this interval.

Set up HTTP rules

Setting up HTTP rules in ALB configuration is essential for properly routing incoming traffic to the appropriate targets, load balancing between multiple targets, and improving security by filtering out unwanted traffic.

HTTP rules include Forward, Redirect, and Static rules. To create an HTTP rule, select + Add HTTP Rule on the right side.

Select an appropriate option for the incoming traffic to activate HTTP Rules in the workspace.

In addition, you can set Conditions for the rule. Select the +Add Condition option to define rules to determine how the load balancer should route incoming traffic. A New Condition window will open up. Provide the following information:

• Type: Select the Type of the condition from the drop-down list.

  • Header: Used when you want to customize the routing of incoming requests based on specific information found in the HTTP headers of those requests.

  • Path: Used when you want to customize the routing or handling of incoming requests based on the path of the URL.

  • Query: Used when you want to customize the routing or handling of incoming requests based on parameters in the query string of the URL.

  • Method: Used when you want to customize the routing or handling of incoming requests based on the HTTP method used in the request.

  • Host: Used when you want to customize the routing or handling of incoming requests based on the host or domain name present in the HTTP headers.

  • Cookie: Used when you want to customize the routing or handling of incoming requests based on the presence or value of specific cookies.

  • Source IP: Used when you want to customize the routing or handling of incoming requests based on the IP address of the client or the source of the request.

• not: Select not to specify conditions for routing rules.

• Condition: Select an option from the drop-down list to specify conditions for routing rules.

• Key: Enter the attribute of an incoming request that the condition is evaluating.

Select Add Condition to save the newly created condition.

You can delete a condition by selecting the Remove option on the right.

Private IP options

The backend of the ALB exposes the private IP addresses of the target as the source of client traffic. A backend IP address is configurable and defaults to x.x.x.225. Backend IPs are listed in the ALB Inspector under the Private IPs tab.

Provision an ALB

Once you have entered the mandatory Settings and Forwarding Rules, you can provision the ALB by selecting PROVISION CHANGES. A Provision Data Center pop-up will appear. Select Provision Now.

Delete an ALB

Anytime you need to delete the ALB, right-click the element and select Delete. You can always use backspace/Delete button on your keyboard.

This section highlights the observability features of the Application Load Balancer (ALB) access logging. The ALB supports comprehensive logging that offer visibility into the application traffic. When enabled, all logs are transmitted to our observability system, where they can be queried and analyzed for valuable insights. Central logging must be enabled for this functionality, ensuring effective monitoring and troubleshooting of application traffic. This allows for proactive identification and resolution of potential issues, enhancing overall application performance and reliability.

Access Logs

Once central logging is enabled, logs from your ALB will be sent to the logging service. You can access and analyze these logs using a dedicated Grafana instance.

Enable Central Logging

• Requirement: Enabling central logging is mandatory for the ALB to send logs.

• Configuration: Send a POST request to the ALB endpoint to enable central logging. Here's an example using curl:

You can configure an ALB to support WebSockets, a communication protocol that provides full-duplex communication channels over a single TCP connection.

To configure WebSocket support follow these steps:

1. ALB Setup. You can either set up the ALB using the ALB Setup or the following POST request.

curl -X POST -H ‘application/json’ -H ‘Authorization: Bearer ...’  https://api.ionos.com/cloudapi/v6/datacenters/{datacenterId}/applicationloadbalancers -d’
{
  “properties”: {
    “name”: “alb-websocket”,
    “listenerLan”: 1,
    “targetLan”: 2,
    “ips”: [“1.1.1.1”],
    “lbPrivateIps”: [“10.20.30.40/24”]
}

1. Create a Target Group.

   1. Before setting up an ALB, predefine a target group to distribute the incoming traffic to the correct target. An IP address and a port are used to register a target.

   2. Ensure that no HTTP health check is configured for the target group for WebSocket support. Otherwise the ALB targets will be unavailable for load balancing. TCP health checks, i.e. healthCheckEnabled, are allowed.

   3. You can either create target group using the Create a Target Group or the following POST request.

curl -X POST -H ‘application/json’ -H ‘Authorization: Bearer ...’  https://api.ionos.com/cloudapi/v6/targetgroups
{
  “properties”: {
    “name”: “websocket-target-group”,
    “algorithm”: “ROUND_ROBIN”,
    “protocol”: “HTTP”,
    “targets”: [
      {
        “ip”: “10.20.30.100”,
        “port”: 8080,
        “weight”: 10,
        “healthCheckEnabled”: true
      }
    ]
}

1. Create a Forwarding Rule.

Forwarding rules define how client traffic is distributed to the targets. More than one rule can be created for the same load balancer.

You can add forwarding rules using Add Forwarding rules guide.

Forwarding rule example:

{
  “properties”: {
    “name”: “websocket-rule”,
    “protocol”: “HTTP”,
    “listenerIp”: “1.2.3.4”,
    “listenerPort”: 80,
    “httpRules”: [
      {
        “name”: “forward”,
        “type”: “FORWARD”,
        “targetGroup”: “<target group id>”
      }
    ]
}

{
 “httpRules”: [
      {
        “name”: “forward”,
        “type”: “FORWARD”,
        “targetGroup”: “<target group ID>“,
        “conditions”: [
          {
            “type”: “HEADER”,
            “condition”: “EQUALS”,
            “key”: “Connection”,
            “value”: “upgrade”
          },
          {
            “type”: “HEADER”,
            “condition”: “EQUALS”,
            “key”: “Upgrade”,
            “value”: “websocket”
          }
        ]
      }
    ]
}

You can configure an ALB to support gRPC, a high-performance RPC framework using HTTP/2 for transport. The gRPC enables users to define service methods and messages in a language-agnostic way, making it easy to create APIs that work seamlessly across different platforms. Additionally, it supports advanced features like load balancing, retries, and deadlines, enhancing the reliability and efficiency of your applications.

To configure gRPC follow these steps:

1. Create a Target Group. Follow the steps outlined in the Create Target Group guide.

Ensure you select HTTP as the protocol and HTTP2 as the protocol version for gRPC support. It is recommended not to set any HTTP health checks for gRPC support.

Example Target group request for gRPC support

{
  “properties”: {
    “name”: “grpc-target-group”,
    “protocol”: “HTTP”,
    "protocolVersion": "HTTP2",
    “algorithm”: “ROUND_ROBIN”,
    “targets”: [
      {
        “ip”: “10.10.10.10”,
        “port”: 8000,
        “weight”: 1
      }
    ]
  }
}

1. Follow Initial ALB Setup guide to complete configuring the load balancer for gRPC traffic.

Before setting up an Application Load Balancer (ALB), predefine a target group to distribute the incoming traffic to the correct target. An IP address and a port are used to register a target.

A target group is a set of one or more registered targets, and you can predefine targets in the Target Groups. You can create multiple target groups and reuse them to set up different ALB forwarding rules.

Create a Target Group

A Target Group is a set of registered targets to which ALB distributes traffic. For each new group, set Connection details and add Targets. You can also configure Health Checks for the group.

1. In the DCD, go to Menu > Network > Target Groups.

2. Select + Create to create a new target group.

1. To create a target group, fill in the following fields:

   • Name: Enter the name of the target group.

   • Algorithm: Select an algorithm from the drop-down list. The algorithm involves defining the conditions that determine how incoming traffic is distributed among the targets in the target group.

     • Round Robin: Allows equal distribution of requests among the servers with time. It distributes incoming network traffic or requests across servers in a circular, sequential order based on their weights.

     • Least connections: Allows the distribution of incoming network traffic or requests among a group of servers based on the current number of active connections. The server with the fewest active connections receives the next request.

     • Random: Allows the distribution of incoming requests randomly among the available servers.

     • Source IP: Allows IP address of incoming network requests to determine how to distribute the traffic among the available servers. This ensures that the same client IP address will always reach the same target.

   • Protocol: This field is preset and defines how data is transmitted between devices. The default value is set to HTTP.

   • Protocol Version: Select the protocol version from the drop-down list. Possible values for the field are HTTP1 and HTTP2. The default value is set to HTTP1. Select HTTP2 for gRPC support.

Configure Connection Settings

1. In the Connection tab, provide the following information:

   • Check Timeout: Enter the maximum wait time in milliseconds (ms) for a target in the group to respond to a check.

   • Check Interval: Enter the time in milliseconds (ms) between the end of the previous connection attempt and the start of the next. The default value is set to 2000 milliseconds (ms).

   • Retries: Enter the maximum number of attempts to reconnect to a target after a connection failure. The default value is set to 3.

Add Health Check

1. In the Connection tab, click Add Health Check to define the settings for a target group:

   • Path: Enter the destination URL for the HTTP health check request. The default value is set to /.

   • Method: Select a method from the list of available health checks.

   • Match Type: Select Status Code to indicate if the request was successful or not, or choose Response Body if you need to evaluate the content of the response body. You can further select the following:

     • Regular Expression: To provide flexibility in matching the expected response from a healthy server.

     • Negation: To negate an individual entry.

Add Targets

You need to register targets with the group so the ALB can forward traffic to the targets.

1. In the Targets tab, select + Add to add a new target to the group.

1. In Add Target, provide the following information:

   • IP: Enter the target IP directly or choose one from the drop-down list.

   • Port: Enter the target port directly or choose one from the drop-down list.

   • Weight: Assign a target weight from 1 to 256. A target with a higher weight gets a larger share of traffic. The default weight value is set to 1.

   • Proxy Protocol: Select a value for the Proxy Protocol from the drop-down list to enable it. You can preserve and send the connection information to your backend instances, such as Apache, NGINX, or an ingress controller inside Kubernetes. Ensure your backend instances are up and running and have Proxy Protocol enabled. The backend instances may return errors or empty responses if the servers are not configured. The following options are available for the Proxy Protocol:

     • none: for disabling the Proxy Protocol

     • v1: for plain text format

     • v2: for binary format

     • v2ssl: for encrypted binary format

   • Options: For changing the target-specific health check configuration, select the following:

     • Health Check Enabled: Upon selection, the target becomes available only for TCP or HTTP connection attempts.

     • Maintenance Enabled: Upon selection, the target does not receive balanced traffic and affects the health of the target.

1. Click Create to add the target.

1. Select Create to save all the configurations and to create the target group.