TLS termination defines where an encrypted connection ends and where its protected application data becomes available for processing. When a load balancer terminates TLS, it presents a server certificate, negotiates protocol versions and cryptographic parameters with the client, and decrypts incoming requests. It then forwards those requests over a separate backend connection. Responses travel through the intermediary and are encrypted on the client-facing connection.
This arrangement separates public-facing security configuration from application deployment. Engineers can manage certificates, private-key access, renewal, and TLS security policies at a smaller number of ingress points rather than on every application instance. Application-aware intermediaries can inspect decrypted HTTP requests for host-based or path-based routing, authentication, and web application firewall evaluation. TLS termination alone does not provide these capabilities; the intermediary must also support them.
The backend connection determines the remaining encryption boundary. With TLS offload to a plaintext backend, a browser might connect over HTTPS to a load balancer that forwards HTTP to private application instances. This reduces backend certificate administration, but traffic on that backend segment is unencrypted. A private subnet does not itself provide encryption, so this design must match the workload’s threat model and compliance requirements.
With re-encryption, the intermediary terminates the client connection and establishes a separate TLS connection to the backend. Both network segments are encrypted, but the intermediary can still read the application data. This is not one uninterrupted client-to-application TLS session. Also distinguish encryption from backend authentication: a proxy must validate the backend certificate and expected identity to authenticate that backend. Some managed load balancers encrypt backend traffic without performing that validation.
TLS passthrough is the contrasting design. A transport-layer load balancer forwards the encrypted connection without terminating it, leaving certificates and TLS processing on the backend. Passthrough preserves the client-to-backend TLS handshake and can be necessary when the application must directly authenticate client certificates. However, the forwarding load balancer cannot inspect encrypted HTTP paths or headers. Do not assume that every load balancer supports application routing simply because it accepts traffic on port 443.
For example, an AWS Application Load Balancer can terminate HTTPS and route requests to HTTP or HTTPS target groups. A Network Load Balancer can terminate TLS using a TLS listener, or pass TLS through using a TCP listener. Its TLS listener does not support mutual TLS; use TCP passthrough when backend applications must perform the mutual TLS handshake. Application Load Balancer mutual TLS features are different: its client-certificate passthrough mode still terminates TLS and forwards certificate information in HTTP headers rather than preserving the original encrypted connection.
Termination also changes identity and application context. A backend sees the proxy’s connection rather than the original TLS session. Configure trusted forwarding headers so applications correctly recognize the original scheme and client information, and prevent untrusted clients from bypassing the proxy or supplying authoritative identity headers. Otherwise, HTTPS redirects, secure-cookie handling, logging, or authorization can behave incorrectly.
For high availability, use redundant termination capacity across failure domains and distribute requests only to healthy targets. Test certificate renewal, hostname coverage, client compatibility, handshake capacity, and backend encryption independently. On an exam or in a design review, identify where TLS must end, who must authenticate whom, whether HTTP inspection is required, and which network segments must remain encrypted before selecting the listener and target protocols.
Amazon CloudFront