HTTP Routing with L7 Load Balancing for APIs and Apps

TL;DR

L7 load balancing distributes HTTP and HTTPS requests not only based on IP address and port but also on hostname, URL path, method, or headers. This allows for targeted routing of APIs, web applications, and versions. The ayedo Edge Cloud makes these decisions at the public entry point and decouples the backends from direct internet traffic.

Introduction

A TCP load balancer can distribute connections but does not know the application behind these connections. For modern APIs and web applications, this information is often insufficient: /api/v1 might belong to a different backend than /api/v2, and a hostname can represent a completely different application. L7 load balancing shifts the routing decision to the HTTP level. This provides more precise control options but also increases responsibility for TLS, rule sets, health checks, and error scenarios. Viewing HTTP routing merely as an additional forwarding rule underestimates its impact on architecture and operations.

1. What distinguishes L7 load balancing from TCP forwarding

L4 load balancing primarily works with network and transport information: target IP, port, and connection state. The payload of an HTTP request is generally disregarded. This method is efficient and universal but limited for application-related decisions.

L7 load balancing, on the other hand, processes HTTP or HTTPS characteristics. Typical criteria include the hostname, URL path, HTTP method, or specific headers. A rule can, for example, direct requests to api.example.com to an API backend and app.example.com to a web backend. Similarly, /v1 and /v2 can be assigned to separate backend pools.

This additional context information enables API load balancing and differentiated HTTP routing. It also means that the load balancer must understand HTTP and, if necessary, terminate TLS. This makes it a part of the application topology, not just a network component.

2. Routing rules are part of the application architecture

An L7 rule set should be derived from the structure and operational requirements of the application. Host-based routing is suitable when multiple applications or API domains are accessible via a common public entry point. Path-based routing is useful when a service is divided into clearly separated functional areas. The HTTP method can provide additional differentiation, for example, with different processing paths for read and write accesses.

Routing becomes problematic when rules contain implicit dependencies. A new API version, an additional tenant, or a changed path can inadvertently redirect existing requests. Therefore, order, priority, and fallback behavior are part of the architectural decision. An unmatched request should not randomly end up in a general backend.

Security requirements are also tied to routing. Different APIs may require their own protection rules, access controls, or operational limits. The L7 rule set does not replace authentication but creates the necessary separation for security and operational measures to be applied specifically.

3. TLS Termination and Backend Cloaking change the data path

For HTTPS traffic, the routing instance must either understand the encrypted request itself or delegate the decision to a downstream system. TLS termination at the edge allows certificates and HTTP routing to be bundled at a public entry point. Afterward, the request can be forwarded to the appropriate backend based on its application characteristics. The specific encryption between edge and backend remains a separate architectural decision.

This separation reduces the direct exposure of the compute infrastructure. Backend cloaking ensures that internal target systems do not have to appear as public endpoints. Thus, the backend does not necessarily require its own public IP addresses or publicly accessible listeners. This limits the attack surface and simplifies control of incoming data traffic.

The cost is an additional component in the request path. Certificate management, header forwarding, logging, timeouts, and handling of client IP addresses must be clearly defined. Proxy Protocol may become relevant if downstream systems need information about the original connection. L7 routing is only robust if the entire data path is documented and tested.

4. Availability arises from routing plus backend state

A correct routing target is not automatically an available target. Backends can be reachable but unable to process requests, or only individual endpoints may be disrupted. Health checks must therefore match the application. A TCP check merely confirms that a port responds; an application-specific check can additionally verify whether a defined HTTP endpoint responds functionally.

With multiple backend pools, behavior in the event of a failure determines actual availability. If a target fails, traffic must be controlled to healthy backends. This affects not only individual instances but also regions, clusters, or providers. However, a failover can have side effects if sessions, data storage, or capacities are not designed for it.

The ayedo Edge Cloud forms the public entry point in front of applications and APIs. It combines Anycast-based Layer-7 load balancing with backend health checks and failover. Its distributed multi-PoP architecture and active-active principle do not assign traffic distribution to a single location. The backends can be operated in ayedo Managed Kubernetes , in own clusters, or with other providers.

Practical Scenario: An API with Two Versions

A company operates a web application and two API versions. The domains app.example.com and api.example.com are published via a common public entry point. Requests to /v1 initially go to the stable backend pool, while /v2 reaches a separately operated pool. A health check verifies an application-specific endpoint for both pools.

In the event of a /v2 pool failure, the entire domain is not considered faulty. Routing can specifically direct the affected version to a defined alternative backend or return an error in a controlled manner. The web application and /v1 remain unaffected. It is crucial that the path structure, fallbacks, and capacity limits are predetermined.

FAQ

Is L7 load balancing only relevant for Kubernetes ?

No. L7 load balancing is independent of the compute platform. It can route applications and APIs in front of Kubernetes clusters, virtual machines, or other backend environments.

When is L4 load balancing sufficient?

L4 is sufficient when connections are to be distributed solely based on network characteristics and no decisions based on hostname, path, or HTTP method are required.

What happens with faulty routing rules?

Incorrectly prioritized or too general rules can send requests to inappropriate backends. Therefore, rule testing, clear fallbacks, and monitoring of actual traffic distribution are necessary.

Conclusion

L7 load balancing turns the public traffic entry point into an application-related control layer. Hostnames, paths, and other HTTP characteristics enable precise separation of APIs and apps but require clear rules for TLS, health checks, fallbacks, and backend security. The ayedo Edge Cloud places these functions in front of the actual backends and remains independent of where the applications are operated. The crucial factor is not the number of routing rules but their technical manageability.