Managed Application Load Balancer

What Is It?

Managed Application Load Balancer (ALB) distributes HTTP/HTTPS traffic across multiple targets at OSI Layer 7 (application layer). ALB inspects full HTTP requests including method, headers, host, path, query strings, cookies, and source IP to make intelligent routing decisions. The service performs TLS termination at the listener, supports path-based routing, and provides health checks to ensure traffic only reaches healthy targets.

Quick Facts

What You Can Do

Layer 7 Routing

Route traffic based on HTTP request attributes including host, path, method, headers, query strings, cookies, and source IP. Create complex routing logic with multiple conditions per forwarding rule.

TLS Termination

Attach SSL certificates to listeners for HTTPS termination at the ALB. Inbound HTTPS traffic is decrypted at the ALB and forwarded as plain HTTP to backend targets. Backend targets do not support TLS certificates; therefore, end-to-end encryption is not available.

Path-Based Routing

Direct requests to different target groups based on URL paths. Route /api/ to API servers, /static/ to content servers, and other paths to application servers.

Host-Based Routing

Route different hostnames to different target groups. Serve app.example.com and admin.example.com from the same ALB using different backends.

HTTP Redirects

Configure redirect rules to force HTTP to HTTPS, redirect old URLs to new locations, or implement custom redirect logic based on request attributes.

Fixed Response Rules

Return static HTTP responses for specific requests. Useful for health check endpoints, maintenance pages, or simple responses without backend targets.

Forwarding Rules with Priority

Create multiple forwarding rules per listener with priority ordering. Rules are evaluated in priority order with a default rule as fallback for unmatched requests.

Health Checks

Configure HTTP or TCP health checks per target group. ALB periodically sends requests to registered targets and removes unhealthy instances from rotation automatically.

Public and Private Listeners

Create public listeners using reserved IPv4 addresses for external traffic, or private listeners with automatic private IPs for internal traffic.

WebSocket and gRPC Support

Support WebSocket connections and gRPC protocols. For gRPC, set the target group protocol version to HTTP/2. Configure a TCP health check for WebSocket and gRPC targets; an HTTP health check must not be used when WebSocket or gRPC support is intended.

Best For

Key Considerations

Billing & Costs

• Main billing: Per forwarding rule per hour (no separate per-ALB-instance fee); a minimum charge equal to one rule applies even if none are configured.
• Additional costs: Public IP address reservation (if using public listeners)
• Per Forwarding Rule: The first 5 forwarding rules are billed at 0,02 EUR/hour each, additional rules at 0,01 EUR/hour each, with a minimum charge equivalent to one rule
• Egress Traffic not included in the ALB price: Egress traffic is billed separately and will come on top of the ALB price

Limitations

• Source NAT (SNAT) not supported (targets cannot initiate connections through ALB)
• TLS termination occurs at listener (backend receives plain HTTP by default). No end-to-end encryption
• Public listeners require reserved public IPv4 address
• Health checks defined per target group, not per forwarding rule

Management Options

• Data Center Designer (DCD)
• Cloud API
• Configure listeners, forwarding rules, target groups, and health checks
• Access logging via central Logging Service (Grafana).
• Flow Logs can be stored in IONOS S3 buckets.