When HTTPS traffic reaches your load balancer, someone has to decrypt it. Where that happens decides what the load balancer can see, how much CPU your servers spend on encryption, and whether traffic is ever unencrypted inside your network. (People still say "SSL", but modern systems use its successor, TLS. The ideas are the same.) There are three standard options.
Picture a post office (the load balancer) handling sealed letters (encrypted requests) addressed to houses (your backend servers).
1. TLS termination: open and sort#
The most common setup. The load balancer ends the encrypted connection at the front door.
- How: the balancer decrypts the request, reads it, and forwards plain HTTP to a backend server.
- Pros: the balancer can route on content (for example, sending
/commentsto the comments service). Backends don't spend CPU on decryption. Certificates live in one place. - Cons: traffic is unencrypted inside your private network, so you are trusting that nobody can snoop between the balancer and the servers.
2. TLS passthrough: blind relay#
The load balancer is just a pipe and never sees inside.
- How: the balancer doesn't hold the keys. It looks only at the IP and port, as an L4 balancer does, and forwards the encrypted stream to a server, which decrypts it.
- Pros: end-to-end encryption. Data is never in plain text anywhere between client and server.
- Cons: the balancer can't read cookies, headers or URLs, so no content-based routing. Every backend does its own decryption and needs its own certificate.
3. TLS bridging: secure inspection#
Combines the smarts of termination with encryption all the way to the servers. Common where compliance forbids unencrypted internal traffic, as in finance and healthcare.
- How: the balancer decrypts the request, inspects it (routing, web application firewall checks), then re-encrypts it and sends HTTPS to the backend.
- Pros: content-based routing and traffic that is encrypted on every hop.
- Cons: the most CPU-hungry option, since traffic is decrypted and encrypted twice. Certificates are needed on both the balancer and the servers.
Comparison#
Side by side, the three options trade visibility against end-to-end encryption.
| Termination | Passthrough | Bridging | |
|---|---|---|---|
| Balancer can read traffic | Yes | No | Yes, then re-encrypts |
| Balancer to backend | Plain HTTP | HTTPS | HTTPS |
| Backend CPU cost | Lowest (offloaded) | Higher (servers decrypt) | Higher (servers decrypt again) |
| Content-based routing | Yes | No | Yes |
| Certificate management | Easy, one place | Hard, every server | Hardest, balancer and servers |
Choosing#
Most systems pick based on routing needs and compliance rules.
- Default to termination at the edge for a typical consumer app. You get path-based routing and offload the decryption work.
- Use bridging when rules require that traffic is never unencrypted, even inside your private network, but you still want L7 routing and inspection.
- Use passthrough when the balancer must never see plaintext, or when you're using an L4 balancer and don't need content routing.
Key takeaways#
- Termination decrypts at the balancer and sends plain HTTP inside. Simple and efficient, but internal traffic is unencrypted.
- Passthrough leaves traffic encrypted end to end, but the balancer is blind and can't route on content.
- Bridging decrypts, inspects and re-encrypts, giving both smart routing and encryption on every hop, at the highest CPU cost.
- Pick based on routing needs, compliance requirements and how much certificate management you can handle.