On an AWS Network Load Balancer, what is the difference between configuring a TLS listener and a plain TCP listener for an encrypted backend, and how do you decide between them?
answer
- who owns the handshake?
- ACM certificate versus a key on every host
- does the app need the client certificate?
- TLS target group re-encrypts the second leg
- access logs only exist for TLS listeners
basics
~20 sA TLS listener makes the NLB terminate the handshake using an AWS Certificate Manager certificate and a security policy; a TCP listener passes the encrypted bytes through untouched so the target terminates. Choose termination for central certificate management, passthrough when the application must handle the handshake.
solid answer
~50 sWith a `TLS` listener, the NLB completes the TLS handshake itself using a certificate from AWS Certificate Manager and a chosen `ELBSecurityPolicy-*` security policy, then forwards to targets — in cleartext if the target group is `TCP`, or re-encrypted if the target group protocol is `TLS`. With a `TCP` listener the load balancer is blind: it forwards the encrypted stream and the application terminates. I terminate at the NLB when I want ACM to handle issuance and renewal, want one place to enforce a TLS version floor, want to offload handshake cost from the instances, or want negotiation control such as an ALPN policy for HTTP/2. I pass through when the application itself must participate in the handshake — mutual TLS where the app authorises on the client certificate, certificate pinning, or a protocol that negotiates its own TLS — and when a compliance rule says only the workload may hold the private key.
go deeper
Know that a TLS listener means the load balancer holds the certificate and completes the handshake, while a TCP listener just forwards encrypted bytes to your application.
Explain the mechanics: ACM certificates and an ELBSecurityPolicy on the listener, SNI selection among several certificates, an ALPN policy, and a TLS target group to re-encrypt the second leg.
Drive the decision from requirements — mutual TLS, pinning, key custody, cipher-floor enforcement, handshake CPU — and name the operational cost of pushing certificate renewal out to every target.
Own where the trust boundary sits organization-wide: who may hold private keys, whether internal legs are re-encrypted, and how a TLS version floor is raised across every service without a coordinated fleet rollout.
## Two listener protocols, two owners of the handshake NLB listeners can be `TCP`, `UDP`, `TCP_UDP` or `TLS`. The choice between `TLS` and `TCP` for encrypted traffic is really the choice of *who owns the TLS handshake*. **TLS listener — the load balancer owns it.** You attach one or more ACM certificates and a security policy. Clients handshake with the NLB. The load balancer then forwards to the target group, and what happens on that second leg depends on the target group's protocol: a `TCP` target group receives cleartext, a `TLS` target group receives a freshly encrypted connection. **TCP listener — the application owns it.** The NLB forwards the encrypted bytes as opaque payload. It cannot read the SNI, cannot present a certificate, cannot enforce a cipher policy. From the application's point of view the client is talking directly to it. ```bash aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:eu-west-1:111122223333:loadbalancer/net/edge/abc \ --protocol TLS --port 443 \ --certificates CertificateArn=arn:aws:acm:eu-west-1:111122223333:certificate/1111-2222 \ --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:eu-west-1:111122223333:targetgroup/app/def ``` ## What terminating at the NLB buys you **Certificate lifecycle.** ACM issues and renews public certificates automatically and the private key never leaves AWS. Compare that with distributing a key and a renewal process to every instance or container image, which is where real outages come from — a certificate expiring on one host at 3am. **One enforcement point.** The security policy sets the protocol versions and cipher suites for everyone behind that listener. Raising a TLS floor becomes one change, not a fleet rollout. **Offload.** Handshakes cost CPU. Moving them off the targets matters most for short-lived connections at high rates. **Negotiation control.** An ALPN policy on the TLS listener lets the load balancer negotiate the application protocol — the standard way to get HTTP/2 to targets through an NLB. **Multiple certificates.** A TLS listener can hold several certificates and select one per connection using SNI, so several hostnames share a listener. **Visibility.** NLB access logs are produced only for TLS listeners. With a TCP listener you get no per-connection log from the load balancer at all — a genuine operational difference that surprises people. ## What passthrough buys you **The application sees the handshake.** This is the decisive one. If the service authenticates clients by their certificate — mutual TLS where authorisation depends on the certificate subject — the code needs the handshake. Passing TCP through is the direct way to give it that. **Pinning and custom trust.** Clients that pin to your leaf certificate, or that trust a private CA the load balancer is not part of, keep working when the load balancer never interposes. **Key custody.** Where policy says the private key exists only inside the workload boundary, passthrough is the only shape that satisfies it. **Protocol-native TLS.** Protocols that begin in cleartext and upgrade — the STARTTLS family — do not fit a TLS listener's model. TCP passthrough handles them. ## The decision in practice Ask what has to see the certificate. If nothing in the application depends on the client certificate or the handshake itself, terminate at the NLB: you get free renewal, one cipher policy and access logs, and you give up nothing you were using. If the application authorises on the client certificate, or the key may not leave the workload, pass through and accept that certificate management and TLS-version enforcement become your problem on every target. And note the middle option that people forget: terminate at the NLB *and* re-encrypt to the targets with a `TLS` target group. Traffic is then encrypted on both legs, the client-facing certificate is managed by ACM, and the internal leg can use a private certificate. That is often the right answer to "we need end-to-end encryption" — it is not the same as passthrough, because the load balancer still sees plaintext momentarily, but it satisfies the wire-encryption requirement without pushing public certificate lifecycle onto every target.
- How do you keep traffic encrypted all the way to the target while still terminating TLS at the NLB?Use a `TLS` listener with a target group whose protocol is also `TLS`. The load balancer terminates the client handshake with an ACM certificate and opens a new encrypted connection to the target, so both legs are on the wire encrypted. The load balancer does see plaintext in between, so this satisfies wire-encryption requirements but not key-custody ones.
- Your application authorises callers by the certificate they present. Which listener do you choose?A TCP listener, so the encrypted stream reaches the application untouched and the handshake — including the client certificate — happens in your code. If the load balancer terminated instead, the application would never see the client certificate and the authorisation decision would have nowhere to run.
- What visibility do you lose by choosing a TCP listener over a TLS listener?NLB access logs are generated only for TLS listeners, so a TCP listener leaves you with CloudWatch metrics and flow-level data but no per-connection load balancer log. If connection-level auditing matters, that is an argument for terminating TLS at the load balancer, or for logging comprehensively in the application instead.
saying these in an interview costs you the question
- Thinks a TCP listener can still enforce a cipher policy
- Believes an NLB reads SNI on a plain TCP listener
- Assumes terminating TLS means the backend leg is cleartext by necessity
- Says passthrough and re-encryption are the same thing
- Expects ACM to auto-renew certificates installed on instances