Compliance

Enforce TLS on load balancer listeners

One capability across Classic, Application and Network Load Balancers: every public listener terminates TLS, plain HTTP redirects to HTTPS, and weak ciphers are off.

13 min·10 sections·AWS

Last reviewed 16 June 2026

Remediates AWS Security Hub: ELB.1 ELB.3 ELB.8 ELB.18 ELBv2.1

Encrypted listeners: the basics

What makes a load balancer listener "unencrypted"?

A load balancer listener is a port-plus-protocol pair that accepts incoming traffic on behalf of a target group. Application Load Balancers (ALBs) speak HTTP or HTTPS; Network Load Balancers (NLBs) speak TCP, UDP or TLS; Classic Load Balancers (CLBs) speak HTTP, HTTPS, TCP or SSL. The protocol decides one thing above all: whether the hop between the client and the load balancer is encrypted. An HTTP listener on an internet-facing ALB sends every credential, session cookie and payload across the public network in clear text.

Security Hub turns this single idea into several controls because the load balancer family is sprawling. ELB.1 and ELBv2.1 fail an ALB whose HTTP requests are not redirected to HTTPS; ELB.18 fails ALB and NLB listeners that are not configured with HTTPS or TLS termination; ELB.3 fails a Classic Load Balancer listener that does not use HTTPS or SSL; and ELB.8 fails a Classic SSL listener that is not using a recommended, strong security policy. They look like separate findings, but they are one capability: no listener in front of users should accept plaintext, and the ones that terminate TLS should do it with a modern cipher set.

The fix is cheap and standard. AWS Certificate Manager issues free, auto-renewing TLS certificates, and TLS termination on a modern load balancer adds a rounding-error amount of compute. The work is not the cost, it is the sequence: add the HTTPS or TLS listener with a strong SslPolicy first, then redirect the HTTP listener rather than deleting it, so old links and bookmarks keep working while the cleartext path closes.

In this lesson you will learn how AWS expresses listener encryption across Classic, Application and Network load balancers, how to provision an ACM certificate and attach it to an HTTPS or TLS listener with a strong security policy, and how to use the HTTP-to-HTTPS redirect pattern so old links keep working without leaving cleartext on the wire. The Controls this lesson covers section lists every Security Hub control in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

Free certs, cached redirects, no excuses

Before AWS Certificate Manager launched in 2016, a wildcard TLS certificate from a public CA cost hundreds to over a thousand dollars a year and had to be renewed by hand, which is why so many sites just shipped HTTP. ACM made certificates free, auto-renewing and tied to DNS validation, removing the single most common excuse for cleartext listeners. The second detail teams miss is the redirect status code: an HTTP 301 (Moved Permanently) is cached by the browser, so the next visit jumps straight to HTTPS without ever touching port 80, while a 302 is temporary and never cached, so every visit still makes a plaintext request first. Always use HTTP_301.

Finding plaintext listeners across an estate

Marco runs the platform team at a fintech. A quarterly compliance review lights up with ELB findings across the marketing and staging accounts: ALBs running plain HTTP:80 listeners and a Classic Load Balancer still on an SSL listener with a stale security policy.

Rather than work each finding alone, he lists the listeners on the worst offender first, a production-adjacent ALB fronting the corporate website, so he can see the protocol, port and any attached certificate, the three things that decide whether the listener controls fail.

List the listeners on the flagged ALB, sliced to protocol, port and any attached certs.

$ aws elbv2 describe-listeners --load-balancer-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:loadbalancer/app/marketing-www/abc123 --query 'Listeners[*].{Proto:Protocol,Port:Port,Certs:Certificates[*].CertificateArn}' --output table

------------------------------------------

| Proto | Port | Certs |

------------------------------------------

| HTTP | 80 | None |

------------------------------------------

# Single HTTP listener, no HTTPS sibling, no certificate. Textbook listener failure.

An HTTP listener with no HTTPS sibling and no cert is exactly what the listener controls fail on.

How encrypted listeners actually workdeep dive

An HTTPS listener on an ALB, or a TLS listener on an NLB, terminates TLS at the load balancer itself. The load balancer holds the private key, presents the certificate during the handshake, decrypts the traffic and forwards it to the target group. The certificate is attached to the listener by its ACM ARN; ACM keeps the private key out of your hands entirely, which is also why ACM certificates can only be used with AWS-integrated services. ALB and NLB listeners support Server Name Indication, so a single listener can serve many certificates and pick the right one per hostname at handshake time.

Each TLS listener also carries an SslPolicy that pins the allowed protocol versions and cipher suites. AWS publishes named policies; ELBSecurityPolicy-TLS13-1-2-2021-06 is the current sensible default, enabling TLS 1.3 and disabling deprecated ciphers. This is why the capability has two layers: ELB.18 and ELBv2.1 are about whether the listener encrypts at all, while ELB.8 (Classic) is about whether the policy it uses is strong. Pinning a stale policy with TLS 1.0/1.1, RC4 or 3DES fails the policy check even after you have added an encrypted listener.

The redirect controls work on the data plane. An ALB listener's default action can be forward, fixed-response or redirect; ELBv2.1 and ELB.1 fail when an HTTP:80 listener's default action is anything other than a redirect to HTTPS. The redirect runs entirely on the load balancer with no compute or Lambda, and the RedirectConfig placeholders #{host}, #{path} and #{query} are substituted at request time so one rule preserves the full URL. The check is on the default action, so path-based rules (for example an ACME HTTP-01 challenge) can still forward without failing the control.

What is the impact of an unencrypted listener?

The direct impact is interception. Any network hop between the client and the load balancer, a coffee-shop wifi access point, a hostile ISP, a misconfigured corporate proxy, can read every request and response. Session cookies are the highest-value target: an attacker with a cookie can impersonate the user without ever needing the password, and the application cannot tell the difference. A single plaintext request after login leaks the session cookie unless the cookie is marked Secure, which most frameworks do not set by default.

The second-order impact is regulatory and contractual. PCI DSS requirement 4 mandates strong cryptography for cardholder data in transit over public networks; HIPAA's transmission-security rule requires it for PHI; SOC 2 CC6.7 and GDPR Article 32 cover it too. A plaintext listener on an internet-facing load balancer is one of the easiest audit findings a regulator or QSA will ever write up, and it blocks attestations until it is closed.

There is also a usability and trust impact. Browsers mark HTTP pages as Not secure, search ranking has used HTTPS as a signal for a decade, and modern web APIs refuse to run on insecure origins. Even when the data is not sensitive, a plaintext listener degrades the product and the brand.

The cost story is the easy one. ACM certificates are free, TLS termination overhead on a modern load balancer is typically under a dollar a month, and the migration, adding HTTPS plus a redirect, is non-disruptive to existing traffic. There is no infrastructure rebuild and no material budget ask, which is exactly why leaving the HTTP listener in place is never a cost decision.

How do you safely move listeners to HTTPS/TLS?

Work the capability as one loop. The order matters: add the encrypted listener before removing the plaintext one, redirect rather than delete so old links survive, and pick a strong security policy so you do not trip the cipher check.

1. Inventory every plaintext listener across the account

Walk every ALB, NLB and Classic Load Balancer and list listeners where the protocol is HTTP or TCP, or where a Classic SSL listener uses a stale security policy. Tag each load balancer with the public DNS name it serves, because you will need that name when requesting the certificate. Separate internet-facing production load balancers from internal and staging ones so the regulated exposure is clear.

2. Provision an ACM certificate with DNS validation

Request the certificate with aws acm request-certificate --validation-method DNS, drop the validation CNAME into Route 53 and wait for ISSUED. DNS validation auto-renews the certificate as long as the record stays in place, with no human in the loop. If the domain lives outside Route 53 the CNAME still works, you just publish it manually.

3. Add the encrypted listener with a strong policy, then redirect HTTP

Create the HTTPS:443 (or TLS) listener with the certificate attached and SslPolicy set to a current TLS 1.2/1.3 policy such as ELBSecurityPolicy-TLS13-1-2-2021-06. Then, instead of deleting the HTTP:80 listener, modify its default action to a 301 redirect to https://#{host}#{path}?#{query}. Old links and bookmarks bounce to HTTPS automatically, and the listener controls pass because there is now an encrypted sibling and a strong policy.

4. Prevent recurrence with AWS Config and IaC defaults

Enable the managed Config rule alb-http-to-https-redirection-check so any new ALB without a redirect fires within minutes, and pair it with elb-tls-https-listeners-only for NLBs. For prevention rather than detection, codify the listener in your IaC module so an HTTP listener cannot ship without a redirect, and an SCP can deny creating an HTTP listener on an internet-facing load balancer outright.

# 1. Create the HTTPS listener with the issued ACM cert and a strong TLS policy.
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:loadbalancer/app/marketing-www/abc123 \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=arn:aws:acm:eu-west-1:123456789012:certificate/d4f8c1a2 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:eu-west-1:123456789012:targetgroup/marketing-www/tg789

# 2. Convert the existing HTTP listener into a 301 redirect to HTTPS (preserves the URL).
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:listener/app/marketing-www/abc123/def456 \
  --default-actions 'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,Host="#{host}",Path="/#{path}",Query="#{query}",StatusCode=HTTP_301}'

Quick quiz

Question 1 of 5

Security Hub shows listener findings across ALBs, an NLB and a Classic Load Balancer. What is the most efficient way to think about them?

Keep learning

Go deeper on load balancer encryption and the TLS termination story on AWS.

You can now treat load balancer encryption as one capability rather than a scatter of findings: inventory every plaintext listener across ALB, NLB and Classic load balancers, provision a free ACM certificate, add the encrypted listener with a strong security policy, redirect HTTP to HTTPS with a 301 so old links survive, and codify the standard in AWS Config and IaC so new load balancers ship compliant. The Controls this lesson covers section below links every control in this group to its deep page and fix.

Back to the library

Encrypted listeners: the cost and compliance view

A near-zero-cost fix that closes one of the cleanest audit findings a regulator writes up

A load balancer is the front door of a web application. If that front door listens on plain HTTP, every request and response crosses the public internet in readable plaintext: passwords, session tokens, payment data, anything. This whole capability costs almost nothing to close. ACM certificates are free with automated renewal, and the TLS termination overhead on an ALB rounds to cents per month in Load Balancer Capacity Units.

The cost of not fixing it is on the audit report, not the bill. PCI DSS requirement 4 mandates strong cryptography for cardholder data over open, public networks; HIPAA's transmission-security rule and SOC 2 CC6.7 require the same; GDPR Article 32 covers it under appropriate technical measures. An HTTP listener on a production load balancer is one of the most clear-cut findings an auditor or QSA will ever write up, because it is binary: the listener either encrypts or it does not.

Treat every failing internet-facing listener as an open compliance liability with a known cost to close, not routine security backlog. For any load balancer fronting regulated data, the annual exposure dwarfs the cents-per-month cost of TLS by orders of magnitude, which makes this one of the few controls where every failing production instance should be approved on the spot.

This lesson is for the finance partner who wants to understand why listener findings on internet-facing load balancers carry real compliance liability and almost no remediation cost. It explains what an unencrypted listener exposes, why ACM certificates are free, how to frame the cost-benefit when engineering asks for approval, which standards this maps to, and the governance approach of treating every unresolved HTTP listener on a production load balancer as an open audit item.

Fun fact

Free certs, cached redirects, no excuses

How a finance partner frames the listener findings

Priya, the finance partner for the fintech's platform team, sits down with the quarterly compliance export ahead of the PCI assessment. The room's first reflex is to ask what closing the ELB findings will cost. The honest answer reframes the whole conversation: ACM certificates are free with automated renewal, and the TLS termination overhead on an ALB rounds to cents per month in Load Balancer Capacity Units. There is no certificate to buy, no licence, no rebuild. So this is not a cost-optimisation item at all, it is a compliance-exposure item that belongs on the controls register, not the invoice.

What Priya does need to size is exposure and ownership, and it is not uniform across the failing listeners. The marketing ALB on plain HTTP:80 fronts the corporate website, no cardholder data, real reputational and search-ranking cost but a low regulatory weight. The Classic Load Balancer on a stale SSL policy and any listener fronting the payments flow are the urgent ones, because those carry the data that puts them in PCI scope. She ranks the failing listeners by what flows through them, gives the regulated entry points committed dates, and asks engineering to fund the provisioning default so the same HTTP listener cannot reappear at the next audit cycle.

Why listener encryption belongs on the compliance register

The cost model here is almost uniquely favourable. ACM certificates are free, TLS termination overhead is typically under a dollar a month per load balancer, and the migration is non-disruptive. There is no rebuild, no downtime window and no material budget ask, so this is a compliance-exposure item, not a cost one.

On the exposure side, a plaintext listener on an internet-facing load balancer is a direct PCI DSS requirement 4 violation if cardholder data flows through it, a HIPAA transmission-security gap if health data does, and a GDPR Article 32 finding in any data-protection audit. Audit remediation costs, external auditor time, internal engineering time and potential fines, are predictably far higher than the cost of just fixing it.

The finance framing is therefore simple: every unresolved listener finding on a production internet-facing load balancer is an open liability with a known, near-zero cost to close. Put it on the risk register with an estimated audit exposure value rather than just a finding count, and make HTTPS the provisioning default so deviations require justification rather than approval.

What finance can do about the plaintext listener gap

Finance cannot create the HTTPS listener, but it can set the framing that turns a scatter of red ELB findings into a governed, risk-ordered plan with predictable cost and clear ownership. Three levers.

1. Treat the listener fixes as near-zero cost, not a project to budget

Make the cost picture explicit so nobody pads an estimate. The ACM certificate is free and auto-renewing, TLS termination is cents per month in Load Balancer Capacity Units, and adding an HTTPS listener plus a 301 redirect is non-disruptive to live traffic. There is no infrastructure to buy and no downtime window to schedule against. The only real input is a slice of engineering time, so the right finance posture is to approve the work on sight rather than wait for a budget cycle.

2. Risk-weight the listeners by the data that crosses them, not the finding count

The raw count of failing ELB controls is misleading because one capability scatters across ALB, NLB and Classic and one load balancer can trip several at once. The number that matters for finance is which failing internet-facing listeners carry regulated or authentication data, since those are the ones whose open finding can stall a PCI attestation or a SOC 2 report. Put the payments-flow and login-path load balancers at the top of the order with committed dates, and treat a plaintext listener on a disposable staging site as lower-priority clean-up.

3. Fund the provisioning default so the HTTP listener cannot recur

The failure mode is drift: a new ALB ships with an HTTP listener because the IaC module allowed it, and the same finding reappears every audit cycle. The finance move is to fund the shared load balancer module so listeners are born as HTTPS with a strong SslPolicy and a redirect, backed by the alb-http-to-https-redirection-check Config rule and an SCP that denies creating a plaintext listener on an internet-facing load balancer. That converts an open-ended audit line into a one-time remediation plus a guardrail, far cheaper over time than re-discovering the gap each year.

Quick quiz

Question 1 of 5

What is the direct AWS spend impact of moving a load balancer listener from HTTP to HTTPS?

Keep learning

Go deeper on load balancer encryption and the TLS termination story on AWS.

You have finished the finance view of load balancer encryption. You know the AWS spend is effectively zero, ACM certificates are free and TLS termination is cents per month, and that the real exposure is attestation risk against PCI DSS requirement 4, HIPAA and SOC 2 rather than a line on the bill. Next time a cluster of ELB listener findings appears, you will approve the near-free fix on sight, risk-weight the listeners by the data that crosses them, and fund the provisioning default that stops the plaintext listener coming back.

Back to the library

Encrypted listeners: the headline

Whether the company is transmitting customer data in cleartext over the public internet

Every internet-facing application routes traffic through a load balancer. If that load balancer listens on HTTP instead of HTTPS, the organisation is transmitting user credentials, session tokens and potentially payment or health data in readable plaintext, visible to anyone between the user and the application. The report surfaces this as a scatter of ELB controls across ALB, NLB and Classic load balancers.

This is an executive item because of the compliance exposure, not the technology. The fix is cheap and operationally simple. PCI DSS, HIPAA and GDPR all explicitly require encryption in transit, so a plaintext listener on a production load balancer is the kind of finding that blocks an attestation or stalls a deal in security review.

The defensible end state is HTTPS by default on every internet-facing entry point, with weak TLS policies disabled and any exception a deliberate, documented decision rather than an overlooked configuration. It is a governance standard, not a budget line.

A concise read for the leader who wants to know what the listener controls protect and what the right accountability question is. You will see why a plaintext listener is a compliance liability rather than a technical nicety, why the fix costs almost nothing, and what a healthy posture looks like: HTTPS by default on every customer-facing entry point, with every exception documented.

Fun fact

Free certs, cached redirects, no excuses

What it looks like when HTTPS-by-default is governance, not luck

After a prospect's security review stalled on a single line, are all customer-facing endpoints encrypted in transit, the executive team stopped treating the scatter of ELB findings as an engineering backlog item. The failures across ALB, NLB and Classic load balancers were not a dozen separate problems; they were one question the company could not answer with a clean yes. HTTPS-required-by-configuration is a control the business can attest to. Trusting whoever last touched a load balancer to choose HTTPS is an assumption written on an audit finding.

Leadership set the end state rather than the implementation: every internet-facing listener encrypts, plain HTTP redirects to HTTPS rather than serving content, weak TLS policies are disabled, and any exception is a deliberate, recorded decision. Because the fix is free in AWS terms, this was never a budget conversation. It was a decision about whether the company could say yes, every customer-facing entry point is HTTPS, without hedging, in front of an auditor, a QSA, or a prospect's security team.

Why this is a board-level risk

An unencrypted internet-facing listener means anything a user sends or receives, passwords, session cookies, form data, API responses, travels in readable plaintext between them and the company's infrastructure. Any attacker on the network path can capture it without breaking any encryption. This is the scenario PCI DSS, HIPAA and GDPR were each designed to prevent, which is why it is one of the cleanest audit findings a regulator writes up.

The leadership relevance is the asymmetry: the fix costs almost nothing while the exposure it removes is real. The goal is HTTPS as the unconditional default on every customer-facing entry point, recorded as policy rather than left to the judgement of whoever last touched the load balancer configuration.

The leadership move on load balancer encryption

The executive handle is not to approve each listener change, it is to require HTTPS by default on every internet-facing entry point and insist that any plaintext exception is a deliberate, recorded decision with a date attached.

1. Set a deadline for the regulated entry points

The fix is cheap and standard but it drifts without pressure, because adding an HTTPS listener and a redirect always loses to feature work when nobody is asking. Give the load balancers fronting regulated or authentication traffic a committed date to be HTTPS-enforcing with a strong TLS policy, and ask to see that date met. This is the one place leadership insistence changes the outcome, since the engineering is not hard, only unscheduled.

2. Require HTTPS by default for new load balancers

Make HTTPS-with-a-strong-policy the default position for every new internet-facing listener, enforced in the shared provisioning modules rather than remembered per launch. The right end state is that a freshly created load balancer cannot serve plain HTTP without a redirect, so the ELB findings can only ever appear for a known list of legacy listeners being migrated, never for something new.

3. Treat any plaintext-serving listener as a recorded exception

An internet-facing listener intentionally left on HTTP should carry a documented, governance-visible reason, not a silently suppressed finding. The distinction between we reviewed this and accepted the risk and we never looked is exactly what makes the encryption posture defensible in a SOC 2 review, a PCI assessment, or a customer security questionnaire. Ask for the exception list, not just the pass rate.

Quick quiz

Question 1 of 5

What is the right leadership question about load balancer encryption?

Keep learning

Go deeper on load balancer encryption and the TLS termination story on AWS.

Two takeaways: a plaintext internet-facing listener is a clean, ownable audit exception that can stall a deal, and the fix is free in AWS terms but drifts without a deadline. The leadership outcome is the regulated entry points closed on a committed schedule and a provisioning default so the HTTP listener cannot reappear from a freshly created load balancer. The question to ask is not what will it cost, it is do our customer-facing endpoints require HTTPS or only permit it.

Back to the library

Controls this lesson covers

One capability, many AWS Security Hub controls. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

ELB

ELBv2

ELBv2.1 Medium ALB serves HTTP without redirecting to HTTPS

Part of the learning path Encrypt everything

Enforce TLS on load balancer listeners

Encrypted listeners: the basics

Free certs, cached redirects, no excuses

Finding plaintext listeners across an estate

How encrypted listeners actually workdeep dive

What is the impact of an unencrypted listener?

How do you safely move listeners to HTTPS/TLS?

1. Inventory every plaintext listener across the account

2. Provision an ACM certificate with DNS validation

3. Add the encrypted listener with a strong policy, then redirect HTTP

4. Prevent recurrence with AWS Config and IaC defaults

Quick quiz

Keep learning

Encrypted listeners: the cost and compliance view

Free certs, cached redirects, no excuses

How a finance partner frames the listener findings

Why listener encryption belongs on the compliance register

What finance can do about the plaintext listener gap

1. Treat the listener fixes as near-zero cost, not a project to budget

2. Risk-weight the listeners by the data that crosses them, not the finding count

3. Fund the provisioning default so the HTTP listener cannot recur

Quick quiz

Keep learning

Encrypted listeners: the headline

Free certs, cached redirects, no excuses

What it looks like when HTTPS-by-default is governance, not luck

Why this is a board-level risk

The leadership move on load balancer encryption

1. Set a deadline for the regulated entry points

2. Require HTTPS by default for new load balancers

3. Treat any plaintext-serving listener as a recorded exception

Quick quiz

Keep learning

Controls this lesson covers

ELB

ELBv2

Related compliance lessons