Unit 3.3: Load Balancing - Layer 7 (Application)

Introduction

A Layer 7 balancer is the point where the network stops moving packets and starts reading requests. That is the decision this unit governs: whether your edge needs to understand HTTP (hosts, paths, headers, methods) well enough to route on them, or whether it only needs to spread TCP connections across a pool. The IONOS Managed Application Load Balancer (ALB) is the content-aware option, and it is also where the platform substitutes for a product it does not sell, a managed API gateway, by exposing routing rules instead. This unit opens at that routing decision and its certificate and cost consequences, then ends by building the public ALB that fronts FinCorp's application tier in the Data Center Designer, sitting on the public edge LAN established in Unit 3.1.

1. When Layer 7 Earns Its Place

The Managed Application Load Balancer distributes incoming application-layer traffic to targets based on user-defined policies, operating at Layer 7 of the OSI model. The Network Load Balancer (NLB), covered in Unit 3.4, operates at Layer 4. The official guidance draws the line cleanly: if your balancing logic needs to process HTTP requests and their attributes, use the ALB; if routing performance is critical and the logic can stay at Layer 4, route TCP traffic with the NLB.

The ALB earns its place when you route on the content of the request rather than the connection. Its forwarding rules support path-based, hostname-based, query-string, header-based, method-based, cookie-based, source-IP-based, URL-redirection, and static or fixed-response routing. One public entry point can therefore send /api to one target group and /static to another, serve two hostnames from one IP, or return a fixed 503 during maintenance, all decisions a Layer 4 balancer is blind to. The trade-off is that every request is parsed and matched, which is why the NLB is reserved for cases where that work is wasted: end-to-end encrypted traffic the balancer should not decrypt, or any non-HTTP protocol. FinCorp's regulated application is HTTP-fronted, with a customer portal and an API surface sharing one hostname and certificate, so Layer 7 is the correct edge; the private database tier stays at Layer 4. This is the layered public-L7-to-private-L4 shape from Unit 1.2.

Three platform boundaries shape how you secure and size the ALB, and all three are design inputs rather than defects:

• The ALB has no IP allowlisting and no Network Security Group. As established in Unit 3.2, NSGs and NIC firewalls bind to server NICs at the VDC level only and do not apply to the managed balancers. Filtering therefore belongs on the targets: firewall rules on the backend NICs plus application logic, with the data tier kept unreachable by topology.
• The ALB does not provide source NAT for target connections, so it is not an egress path. Private workloads reach the internet through the NAT Gateway in Unit 3.6.
• IPv6 has documented limitations on the ALB, so treat the public listener as an IPv4 endpoint on a reserved public IPv4 address and plan any IPv6 exposure separately.

There is no IONOS API Gateway product. The platform's substitute is exactly the mechanism this unit builds: ALB forwarding rules carry coarse content routing (path and host rules, redirects, fixed responses) at the edge, and an in-cluster ingress controller carries finer-grained, application-aware routing inside a Kubernetes cluster behind it. You compose the API-gateway behaviour from a managed balancer plus in-cluster ingress rather than provisioning a single gateway product.

2. The Three Required Components and the Cost of Rules

Every ALB requires at least one listener, a forwarding rule, and a target group. Understanding what each does, and what each costs, is what keeps a Layer 7 design lean.

The following table summarises the three components and their roles.

The default balancing algorithm is Round Robin; the available algorithms are Round Robin, Least Connections, Random, and Source IP. Per-target weighting (a weight in the range 1 to 256) lets you bias distribution, which is the mechanism for a weighted canary at Layer 7.

The components compose hierarchically, and that hierarchy is where rule discipline matters. A listener holds forwarding rules; a forwarding rule holds an ordered set of HTTP rules; the request matches rules in order and falls through to a default action when none matches. So you place the most specific rules first and the catch-all last, with one clear default action per listener (often a forward to the primary target group, or a fixed response).

Keep the rule set lean for a reason beyond clarity: rules and listeners are the managed surface of the ALB, and a sprawling set is an operational liability. An ALB caps at 10 listeners and a contract at 5 ALBs, so the resource is deliberately bounded. The discipline is to express routing with the fewest correct rules, push fine-grained routing into in-cluster ingress where it belongs, and reuse target groups across rules rather than duplicating them.

3. TLS Termination and Certificate Sourcing

The ALB performs TLS offloading: it terminates TLS at the listener so the backend connection can be plaintext HTTP. This is the normal Layer 7 pattern and it is why the certificate lives on the ALB, not on the targets. The ALB also supports SNI, so one listener can present the right certificate for multiple hostnames. (When the backend must keep the certificate and the balancer must not decrypt, that is the Layer 4 case in Unit 3.4, not an ALB configuration.)

The certificate constraints are specific and are the part most likely to fail a first provisioning attempt, so source the certificate deliberately. The ALB requires exactly one leaf (end-entity) certificate and the key must be RSA. As of the 2026-06 documentation, intermediate and root CA certificates may be included alongside the leaf in the same file, so a full chain is now permitted; what is rejected is providing only CA certificates, or more than one leaf. The leaf's public key must match the supplied private key, and the private key must be a single RSA key in PKCS#1 (RSA PRIVATE KEY) or PKCS#8 (PRIVATE KEY) format.

The Certificate Manager offers two paths, and only one feeds the ALB. The ALB consumes only imported certificates: you upload the certificate, chain, and private key as PEM, and attach the resulting resource to the listener. The Auto Certificate (ACME) path, which renews automatically through a provider such as Let's Encrypt and requires the domain's DNS zone to be hosted in IONOS Cloud DNS, lists CDN as its downstream consumer, not the ALB. So you cannot lean on managed ACME renewal for an ALB listener; you import a PEM certificate and own its rotation. One constraint follows: on an imported certificate the private key is set at creation and cannot be edited, so rotation means creating a new certificate resource and re-pointing the listener, not editing the key in place. Build that into the renewal runbook. For FinCorp, the portal and API share one hostname and one imported RSA-leaf PEM certificate terminated at the ALB, and renewal is a calendar-driven swap.

DCD Implementation Walkthrough

You will build the public Layer 7 entry point for FinCorp's application tier: a public ALB on the edge LAN from Unit 3.1, with an HTTPS listener terminating TLS, a target group pointing at the application servers, a path-based forwarding rule, and an HTTP health check. This realises the public end of the layered architecture and gives the API-gateway substitution its edge half.

Build goal: Build a public Layer 7 balancer with an HTTPS listener, target group, path rule, and health check.

Prerequisites: A reserved public IPv4 address from IP Management (a public ALB requires at least one listener IP), the three-LAN topology and application servers from Unit 3.1, and an imported PEM certificate in the Certificate Manager (single RSA leaf, optional chain, matching RSA private key) for the HTTPS listener.

Steps (in the Data Center Designer):

1. Create the target group first. Go to Menu > Network Services > Target Groups and select Create. Give it a name and choose an algorithm (Round Robin is the default; Least Connections, Random, and Source IP are the alternatives).
2. In the target group, add targets in the Targets tab: for each application server enter its IP and the backend port the service listens on (the backend can be plaintext HTTP because the ALB terminates TLS). Set a per-target weight (1 to 256) if you want to bias distribution, for example for a weighted canary.
3. Add the health check in the target group's Connection tab. For an HTTP check set the Path (default /), the Method, and the Match Type (Status Code, or Response Body with an optional regular expression or negation). Note that an HTTP health check must not be configured if you intend to use gRPC or WebSocket support on this group.
4. Place the ALB: in the data center workspace, drag a Load Balancer of type Application onto the canvas.
5. Connect its interfaces: attach the northern interface to Internet Access (the public edge) and the southern interface to the application-tier LAN holding the targets. Only public load balancers require a public IP and internet-facing connectivity; a private ALB needs no public IP.
6. Configure the listener as HTTPS: assign the reserved public IP as the listener IP, set the listener port (443 for HTTPS), and associate the imported PEM certificate from the Certificate Manager so the ALB terminates TLS at this listener.
7. Add the forwarding rule in the Forwarding rules tab: name it, confirm the protocol, set the listener IP and port, and review the client timeout (the documented default is 50000 ms).
8. Add the HTTP rules under the forwarding rule. Add a Forward rule that matches the specific path (for example /api) and points to the target group from step 1; order the most specific rules first. Then set a default action (a forward to the primary target group, or a Static fixed response) for traffic that matches no specific rule.
9. Provision the changes. The ALB validates the certificate during provisioning, so a certificate that is not a single matching RSA leaf will fail here rather than silently.

Common mistakes:

• Not reserving the public IP first. A public ALB needs at least one listener IP from IP Management before you can configure the listener; reserve it ahead of the build.
• Expecting managed ACME renewal on the ALB. The ALB consumes only imported PEM certificates; the Auto Certificate (ACME) path feeds CDN, not the ALB, so plan certificate rotation as a manual, calendar-driven task.
• Forgetting that the imported private key is immutable. Rotation means a new certificate resource and re-pointing the listener, never an in-place key edit.
• Trying to lock down the ALB with an allowlist or NSG. The ALB has neither; put firewall rules on the target NICs and rely on topology to keep the data tier unreachable.
• Leaving rule order to chance. HTTP rules match in order with a fall-through default; put specific rules above the catch-all, and set exactly one clear default action.
• Configuring an HTTP health check on a group meant for gRPC or WebSocket. The docs explicitly forbid combining them; choose the health check to match the group's protocol.
• Treating the ALB as an egress path. It does not provide source NAT for targets; private egress goes through the NAT Gateway in Unit 3.6.

Summary

The Managed Application Load Balancer is the content-aware edge: choose it when routing must read HTTP hosts, paths, headers, or methods, and leave pure connection spreading to the Layer 4 NLB. Its three components (listener, forwarding rule, target group) compose into an ordered, default-backed routing tree that you keep deliberately lean, because rules and listeners are the bounded, managed surface of the resource. TLS terminates at the listener on an imported RSA-leaf PEM certificate (managed ACME does not apply here), filtering belongs on the targets rather than on a balancer that has no NSG or allowlist, and the ALB plus in-cluster ingress together stand in for the API gateway the platform does not sell.

Key Points:

• Use the ALB when balancing logic must process HTTP attributes; use the NLB when the work can stay at Layer 4 or when end-to-end encryption must reach the backend.
• Every ALB needs at least one listener (1 to 10 per ALB), a forwarding rule, and a target group; a contract is capped at 5 ALBs.
• The ALB terminates TLS (TLS offloading) and supports SNI; the backend connection can be plaintext HTTP.
• Certificates must be a single RSA leaf in PEM (a full chain is now permitted, CA-only or multi-leaf is rejected), imported via the Certificate Manager; the ALB does not consume the managed ACME Auto Certificate path, and the imported private key cannot be edited after creation.
• The ALB has no IP allowlisting and no NSG, and provides no source NAT; filtering belongs on the targets and egress goes through the NAT Gateway.
• The API-gateway substitution is ALB path and host rules at the edge plus in-cluster ingress inside the cluster, kept lean to control the rule and listener surface.

Important Terminology:

• TLS offloading (termination): the ALB decrypts TLS at the listener so it can read and route on the HTTP request, forwarding to backends over plaintext HTTP; this is why the certificate lives on the ALB.
• Forwarding rule and HTTP rule: a forwarding rule bound to a listener holds an ordered set of HTTP rules (Forward, Redirect, Static); requests match in order and fall through to a default action.
• Target group: a reusable group of registered targets (IP plus port) with an algorithm, per-target weights, and a health check the ALB performs once the group is bound to a forwarding rule.

Further Reading

• Unit 3.1: VDC Topology and Segmentation (the edge LAN and reserved public IP this build depends on)
• Unit 3.2: Network Security: Firewall and Security Groups (why filtering binds to target NICs, not the ALB)
• Unit 3.4: Load Balancing - Layer 4 (Network) (the private balancer that completes the layered shape)
• Unit 6.2: Provisioning a Public Cluster (the in-cluster ingress half of the API-gateway substitution)