With an AWS Application Load Balancer (ALB) in front of your infrastructure, the cleanest place to enforce HTTPS is a listener rule at the load balancer itself, rather than application-level redirect logic.
Setting it up
- Create an HTTPS listener (port 443) on the ALB with your ACM-issued certificate attached.
- On the existing HTTP listener (port 80), replace or add a rule with action type "Redirect to" → HTTPS, port 443, status code 301.
- Ensure your target group's health checks and your application itself are configured correctly, since the app behind the ALB will receive plain HTTP from the load balancer (TLS terminates at the ALB) unless you've also configured end-to-end encryption to the targets.
Application-level considerations
Because TLS terminates at the ALB, your application will see every request as HTTP internally — check the X-Forwarded-Proto header (which ALB sets automatically) if your application needs to know the original protocol, rather than relying on a direct HTTPS check that will always read as false behind the load balancer.
Why ACM-issued certificates simplify renewal compared to manually uploaded ones
Certificates issued through AWS Certificate Manager and attached to a load balancer renew automatically as long as the required DNS validation records remain in place, removing the manual renewal tracking that a separately purchased and manually uploaded certificate would otherwise require.
What target group health checks have to do with an apparent redirect failure
If your ALB's health checks against backend targets are misconfigured, expecting HTTPS from a target that only serves HTTP, for example, the load balancer can mark targets unhealthy and stop routing traffic entirely, producing a connection failure that looks redirect-related but is actually a health check misconfiguration with nothing to do with the redirect rule itself.
Why checking the listener rule order matters on an ALB with multiple rules
An Application Load Balancer evaluates listener rules in priority order, meaning a redirect rule with lower priority than another matching rule may never actually execute — reviewing rule priority explicitly is worth doing on any listener with more than the basic default rule configured.
What CloudFront adds to this picture if you're using it in front of your ALB
If CloudFront sits in front of your ALB as a CDN layer, CloudFront has its own separate SSL/TLS configuration and its own certificate (also typically via ACM) — the redirect and certificate configuration then needs to be correct at both the CloudFront and ALB layers, not just one or the other.
How Route 53 health checks interact with your redirect configuration
Route 53 health checks configured to verify your endpoint's availability should be pointed at a path that correctly handles the redirect, or directly at the HTTPS endpoint, to avoid a health check incorrectly reporting failure due to receiving a redirect response rather than the expected success status.
Why tagging your ALB listener rules helps with long-term infrastructure management
As AWS infrastructure grows more complex over time, tagging listener rules with clear, descriptive names documenting their purpose (the specific redirect they implement, for instance) makes future troubleshooting and infrastructure audits considerably faster than trying to reverse-engineer undocumented rule configurations.
Why AWS's approach reflects a broader pattern in cloud infrastructure generally
Centralizing certificate management through a managed service like ACM, integrated directly with load balancing infrastructure, reflects a broader pattern across major cloud providers generally — removing manual certificate handling from individual application deployment concerns and centralizing it at the infrastructure layer instead.
What Elastic Beanstalk changes about this configuration if you're using it
Elastic Beanstalk environments typically use an Application Load Balancer under the hood, meaning the same ALB listener rule approach covered in this guide applies directly, accessible either through the EB console's load balancer configuration or by managing the underlying ALB directly through the EC2 console.
How this guide's steps apply to a Network Load Balancer instead of an Application Load Balancer
A Network Load Balancer operates at a lower network layer and doesn't support the same application-layer redirect rules an ALB does — achieving an HTTPS redirect behind an NLB typically requires handling the redirect at the application level instead, using the framework-specific approaches covered elsewhere in this category.