Should TLS terminate at the load balancer, or should encrypted traffic pass all the way through to the backend servers? What's the actual security and operational trade-off?

TLS termination at the load balancer is operationally simpler (certificate management in one place, backends don't need their own TLS setup, and the load balancer can do content-aware Layer 7 routing since it can see the decrypted traffic) but means traffic between the load balancer and backends is unencrypted unless you separately re-encrypt it. End-to-end TLS (passthrough, or re-encryption to backends) keeps data encrypted for the entire path, which matters more as your internal network trust boundary shrinks — but costs more operational complexity (certificates on every backend) and, for pure passthrough, gives up Layer 7 routing capability since the load balancer can't see inside the still-encrypted traffic.

The comparison centers on where you draw your trust boundary and how much operational complexity you're willing to accept for extending encryption past it.

TLS termination at the load balancer is the simpler, more common default: the load balancer holds the certificate and private key, handles the TLS handshake, and forwards decrypted traffic to backends over plain HTTP — this centralizes certificate management (renewal, rotation) in one place rather than distributing it across every backend, and importantly, lets the load balancer actually read the decrypted request content, enabling Layer 7 routing decisions (path-based routing, header inspection) that require seeing inside the traffic.

This assumes the network between the load balancer and backends is itself trusted: the security trade-off of termination is that anyone who could intercept traffic on that internal segment (a compromised host on the same network, a misconfigured network boundary) would see plaintext — a reasonable assumption within a well-segmented private network or VPC, but a real gap in a zero-trust model where internal network segments aren't assumed trustworthy just because they're internal.

End-to-end encryption (re-encryption at the load balancer, or full passthrough) closes that gap: re-encryption means the load balancer terminates the client's TLS connection, then establishes a separate, new encrypted connection to the backend — this keeps the entire path encrypted while still letting the load balancer see the decrypted content for Layer 7 routing (since it decrypts, routes, then re-encrypts). Full TCP passthrough (the load balancer never decrypts at all, just forwards encrypted packets) preserves true end-to-end encryption but gives up Layer 7 routing entirely, since the load balancer genuinely can't see inside the still-encrypted stream — it's limited to Layer 4-style routing decisions.

The operational cost of end-to-end approaches is real: every backend needs its own valid certificate (or the internal traffic needs its own internal CA/certificate infrastructure), adding certificate management and rotation overhead across many more endpoints than centralized termination requires — this is a genuine ongoing operational investment, not a one-time setup cost.

The practical decision: termination-only is reasonable for most applications within a properly segmented, trusted internal network; re-encryption is the common middle ground when you want both Layer 7 routing and end-to-end encryption; full passthrough is appropriate when you specifically need true end-to-end encryption (e.g., compliance requirements) and can accept giving up content-aware routing, or when routing decisions don't need to be content-aware anyway.

• TLS termination at the load balancer is operationally simplest and enables Layer 7 routing, but leaves the load-balancer-to-backend segment unencrypted unless separately addressed.
• Re-encryption (decrypt, route, re-encrypt to backend) preserves end-to-end encryption while keeping Layer 7 routing capability, at the cost of certificate management on every backend.
• Full TCP passthrough preserves true end-to-end encryption but gives up Layer 7 routing entirely, since the load balancer can't see inside still-encrypted traffic.
• The right choice depends on whether your internal network segment is genuinely trusted, and whether you need content-aware routing — not a universal default.

• AWS: SSL/TLS Certificates for Elastic Load Balancing
• NIST SP 800-52: Guidelines for TLS Implementations