Note: To manage SSL certificates for your ALB, see Manage SSL Certificates.
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).
Prerequisites: A public load balancer can be created by providing at least one listener IP address. Please make sure you have previously . 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 .
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.
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.
Note: This feature is only available for newly created ALBS in non-US datacenters and requires central logging to be enabled as a prerequisite.
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.
Note: The Grafana URL where the logs will be available will follow the pattern as in this example: https://grafana.d6b7a2374abe.dev.logging.de-txl.ionos.com/ where d6b7a2374abe is a hash of the contract number.
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:
Note: Replace datacenterId and TOKEN with your actual data center ID and authorization token.
Note:
Enabling or disabling central logging is also possible via PUT requests.
Enabling central logging incurs additional costs.
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.
Learn how to configure ALB for WebSocket support.
Learn how configure ALB for gRPC traffic.
Learn how to enable Access Logging for ALB.
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:
ALB Setup. You can either set up the ALB using the ALB Setup or the following POST request.
Create a Target Group.
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.
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.
You can either create target group using the Create a Target Group or the following POST request.
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:
Note: Web Socket traffic is not normal HTTP traffic, so ensure that your HTTP rules or conditions are accurate. Only the initial protocol upgrade to enable Web Socket tunneling can be targeted by the HTTP rule conditions. An example of this would be:
Result: This should result in an ALB that is able to handle HTTP protocol upgrade requests to switch to Web Socket tunneling.
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:
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.
Follow Initial ALB Setup guide to complete configuring the load balancer for gRPC traffic.
Result: ALB will now support gRPC traffic by handling HTTP/2 requests and enabling efficient gRPC communication.
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 > Network > 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.
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.
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. HTTP health check must not be configured if gRPC or WebSocket support is intended.
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.
