Certificate Manager allows importing, managing, and deploying self-managed Secure Sockets Layer (SSL) or Transport Layer Security (TLS) certificates so that they can be used with Application Load Balancers (ALBs).
Go to Management > SSL Certificate Manager under Security.
Click + Create to import a new Secure Sockets Layer (SSL) or Transport Layer Security (TLS) Certificate.
To import an SSL Certificate, enter the following details:
Name: Enter a name for the SSL certificate.
Certificate: Either paste in your PEM-encoded certificate or click Choose file to navigate to your certificate file.
Certificate Chain: To include the Certificate Authority (CA) certificate chain, click Choose file to navigate to your certificate file. It is essential to note that IONOS does not automatically validate the certificate chain on your behalf. We recommend that you validate the certificate chain for proper security and authentication.
Private Key: Either paste in your private key or click Choose file to navigate to your private key file.
4. Click Create to add the Certificate.
5. Click Create to save all the configurations and to create a Certificate.
Result: Your Certificate is added to the Certificates list.
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 can also configure Health Checks for the group.
In the DCD, go to Menu > Management > Target Groups.
Select + Create to create a new target group.
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.
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.
Note: This step is optional. For more information, see Health Checks.
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.
You need to register targets with the group so the ALB can forward traffic to the targets.
In the Targets tab, select + Add to add a new target to the group.
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.
Click Create to add the target.
Note: From the Targets list, select the edit icon to edit an existing target or select the delete icon to delete a target.
Select Create to save all the configurations and to create the target group.
Result Your target group is added to the Target Groups list.
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 Application Load Balancer (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 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.
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.
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.
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. To add a new target, select +Add. An Add Target window will open up. 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.
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 +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.
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 can provision the ALB by selecting PROVISION CHANGES. A Provision Data Center pop-up will appear. Select Provision Now.
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 select Delete. You can always use backspace/Delete button on your keyboard.
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).
Note: From the Certificates list, click to edit an existing Certificate or click to delete a certificate.
Learn how to create target groups before setting up an ALB
Learn how to add private SSL/TLS certificates before setting up an ALB
Learn how to configure initial ALB settings
Learn how to create and configure flow logs
Learn how to set up an Application Load Balancer inside of the DCD.
Learn how to add nodes to the load balancer Target Group.
Learn how to add private SSL/TLS certificates before setting up an ALB
Send regular traffic logs to your storage bucket.
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 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.
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.
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.
Note: Public IP addresses must be reserved in advance. For more information, see Reserve an IPv4 Address
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.
Note: Listeners can be configured from the Forwarding rules tab. For more information, see Adding Forwarding rules.
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.
Note: Listeners can be configured from the Target Groups. For more information, see Create 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.
Note: All health check-related metrics are configurable from the Target Group manager.
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 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.
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.
