How do you enforce HTTPS on an AWS Application Load Balancer?

Why HTTPS enforcement on an Application Load Balancer is really a listener policy decision

On an AWS Application Load Balancer, HTTPS enforcement is not a single switch so much as a routing posture. The ALB must terminate TLS on an HTTPS listener, and any HTTP listener should exist only to redirect clients to the secure endpoint. That keeps the control at the entry point, where you can standardise certificate use, eliminate accidental plain-text exposure, and keep downstream application logic from having to guess which scheme the user arrived on.

That approach fits a broader AWS hardening pattern: put the security decision at the edge and make the insecure path intentionally unusable. The same operational logic shows up in AWS Security Guide, where front-door controls, logging, and configuration hygiene are treated as baseline controls rather than optional extras.

What has to be in place for the redirect to work cleanly

The HTTPS listener needs a valid certificate that matches the hostname users actually visit, otherwise browsers will warn or fail before any redirect logic can help. Once the secure listener is active, HTTP should do one thing only: send a redirect to HTTPS and preserve the original destination where possible so users do not land on the wrong page. If the application uses absolute links, canonical URLs, or HSTS, those settings should be aligned with the redirect behavior rather than layered on separately and left inconsistent.

This is also where load balancer behavior needs to be checked against application expectations. Health checks should continue to succeed, redirect targets should resolve correctly, and any upstream service that depends on the original protocol should be reviewed so the redirect does not break callback flows, login sequences, or mixed-content handling.

For infrastructure that sits at the internet edge, Edge Device Security Guide is a useful companion because it treats load balancers and gateways as exposed control points that need deliberate configuration, logging, and change discipline.

Where HTTPS enforcement usually fails in practice

The most common failure is partial enforcement, where one listener is redirected but another listener, path, or target group still accepts plain HTTP. That creates a false sense of safety because users may appear to land on HTTPS while some application paths remain reachable over cleartext. Another failure mode is broken trust chaining, where the certificate is valid but the application still generates HTTP links, redirects to the wrong host, or loses session state after the protocol switch.

There is also an exposure issue when teams assume the redirect alone is enough and do not check whether the backend application, its health checks, or any intermediary proxies still expose HTTP internally or externally. That matters because the user-facing endpoint may be secured while monitoring, callbacks, or alternate routes remain weaker than intended.

If you are testing edge-hardening patterns more broadly, the attack surface lesson behind 230M AWS environment compromise is that exposed or misconfigured cloud entry points can become the path of least resistance, even when the original issue looks operational rather than malicious.

Risk and Threat Considerations

When HTTPS is not enforced, the main risk is not just eavesdropping. Cleartext access can expose session identifiers, credentials in poorly designed flows, or sensitive request data, and it can also let an active attacker tamper with redirects or downgrade a user onto an insecure path. At the edge, that turns a configuration gap into a trust boundary failure.

Failure mechanism: HTTP remains reachable through a listener, path, or alternate hostname, so users, bots, or intermediaries can still connect without TLS and may follow insecure redirects or consume application responses over plain text.

Impact: Confidentiality, integrity, and session trust all weaken at the first hop, and the organisation may believe the site is encrypted while some traffic still traverses an exposed route.

Practitioner Guidance

What to verify: Confirm that the ALB has an HTTPS listener with the correct certificate, that the HTTP listener returns a redirect rather than serving content, and that every hostname and path users can reach lands on the secure scheme. Validate this with a browser, curl, and your normal monitoring path, not just with the obvious homepage.

Decision rule: If any business-critical flow still depends on HTTP after the change, treat that as a design defect rather than an acceptable exception. The safe pattern is to remove or redirect the HTTP path, then adjust the application, health checks, and callbacks so they operate cleanly over HTTPS.

Practitioner takeaway: HTTPS enforcement on an ALB is successful only when the insecure route is no longer a usable route, not merely when the secure route exists.

Related resources from NHI Mgmt Group

• How do you protect Amazon API Gateway, Application Load Balancer and CloudFront with AWS WAF?
• How do you mitigate HTTP desync attacks on AWS Application Load Balancers?
• How should security teams prevent Kubernetes load balancer annotations from exposing AWS security groups to the internet?
• Why does using the wrong AWS load balancer annotation create a larger exposure than teams expect?