Learn how to create target groups before setting up an ALB
Learn how to configure initial ALB settings
Learn how to create and configure flow logs
Prerequisites: You should have write access permissions to an IONOS S3 Object Storage bucket. You have an IONOS S3 Object Storage instance with a bucket that exists for your flow logs. To create an IONOS S3 Object Storage bucket, see the IONOS S3 Object Storage page.
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.
In the Inspector pane, open the Settings tab.
Open the Flowlog drop-down.
Select the trash bin icon to delete the flow log.
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.
Note: Deleting a flow log does not delete the existing log streams from your bucket. Existing flow log data must be deleted using the respective service's console. In addition, deleting the flow log that is published to IONOS S3 Object Storage does not remove the bucket policies and log file access control lists (ACLs).
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.
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 may also configure Health Checks for the group.
Go to Management > Target Groups under Load Balancing.
Click + Create to create a new target group.
To create a target group, fill in the following fields:
Name: Enter a name for the target group.
Algorithm: Select an algorithm to determine how network traffic is distributed among targets.
Protocol: The default value is HTTP.
4. In the Connection tab, fill in the following fields for the connection settings:
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.
Retries: Enter the maximum number of attempts to reconnect to a target after a connection failure.
5. In the Connections 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: Choose a method from the list of available health checks.
Match Type: Choose 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 checkboxes:
Regular Expression: To provide flexibility in matching the expected response from a healthy server.
Negation: To negate an individual entry.
You must register targets with the group so the ALB can forward traffic to the targets.
6. In the Targets tab, click + Add to add a new target to the group and fill in the following fields:
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 0 to 256. A target with a higher weight gets a larger share of traffic. The default weight value is set to 1.
For changing the target-specific health check configuration, use the following checkboxes:
Health Check Enabled: On selecting, the target becomes available only for TCP or HTTP connection attempts.
Maintenance Enabled: On selecting, the target does not receive balanced traffic and affects the health of the target.
7. Click Create to add the target.
8. Click Create to save all the configurations and to create the target group.
Result Your target group is added to the Target Groups list.
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.
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 periodical checks which 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.
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 of Target Groups.
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.
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.
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.
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.
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.
The Managed Application Load Balancer 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 - 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.
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.
Note: This step is optional. For more information, see .
Info: From the Targets list, click to edit an existing target or click to delete a target.
Note: Public IP addresses must be reserved in advance.
Tutorial: Listeners can be configured from the in the Inspector.
Tutorial: Targets can be configured from the
Note: All health check-related metrics are configurable from the .
Learn how to set up an Application Load Balancer inside of the DCD.
Learn how to add nodes to the load balancer Target Group.
Send regular traffic logs to your storage bucket.
Prerequisites: A public load balancer can be created by providing at least one listener IP address. Please make sure you have previously reserved public IP addresses via the IP Manager. You may always create a private load balancer without specifying any IP addresses.
Additionally, you will need at least one Target Group to which ALB will forward traffic. You can create one in the Target Group Manager.
Add an ALB element by dragging it to the workspace.
Connect the northern interface to Internet Access and the southern interface to a target Server.
To Configure ALB Settings, open the Settings tab from the right Inspector pane and fill in the following fields:
Name: Enter a name for the Application Load Balancer.
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.
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, open the Forwarding Rules tab. To add forwarding rules, select +Add Forwarding Rule and fill in the following fields:
Name: Enter a unique name for the forwarding rule.
Protocol: 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.
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 in the Inspector pane.
Select the appropriate option for the incoming traffic to activate HTTP Rules in the workspace.
To forward a request to a pre-made Target Group, select the Forward option from the drop-down menu and fill in the following fields:
Name: Enter a unique name for the HTTP rule.
Target Group: Select a target group for forwarding traffic based on the protocol and port specified in the listener configuration.
Targets: The value is automatically populated based on the target group selection.
To request redirection at the HTTP level, select the Redirect option from the drop-down menu and fill in the following fields:
Name: Enter a unique name for the HTTP rule.
Redirect URL: Select a target URL for the redirect.
Status Code: Select a status response code from the list.
Query string: Specify whether you want to keep or drop the query string.
To return a static response message, select the Static option from the drop-down menu and fill in the following fields:
Name: Enter a unique name for the HTTP rule.
Status Code: Select a status response code from the list.
Response Message: Select an appropriate content type from the list.
Response Content type: Enter the content to be displayed in the browser upon the rule trigger.
In addition, you can set Conditions for the rule. Select the Type of the condition in New Condition section and define the rules to determine how incoming traffic is routed and handled by the load balancer. The action is performed only when all conditions are met. If no conditions are specified, the rule will always be performed.
If you make a mistake, you can always delete a rule by selecting the Remove icon on the right.
Note: This step is optional. A private IP will be assigned automatically during provisioning. You may also add a private IP manually if you select + Add IP.
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.
Once you have entered the mandatory Settings and Forwarding Rules, you may provision the ALB by clicking PROVISION CHANGES. A Provision Data Center window will appear. Select the Provision Now option.
Note: The provisioning process cannot be canceled. However, an existing ALB can be modified at any time. Your password may be required to edit some elements as an additional security measure.
Anytime you need to delete the ALB, right-click the element and choose Delete. You can always use the Backspace/Delete button on your keyboard.
