- Newest
- Most votes
- Most comments
Hi,
Based on your requirements I believe you will benefit from this solution of placing an NLB in front of an ALB - https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/
It wouldn't be possible to offload SSL on the NLB and also have HTTP to HTTPS redirection on the webserver as the webserver would see HTTP traffic in this case and cause an infinite loop. Normally we handle this by redirecting based on the X-Forwarded-Proto header but that is unavailable on NLB.
The other option is to have an NLB with TCP:80 and TLS:443 listeners forwarding to TCP:80 and TLS:443 target groups respectively and handle SSL and redirection on the instance. You can use a self-signed certificate on the instance and and ACM certificate (which the client sees) on the NLB.
NLB works at layer 4 (TCP/TLS) and does not see Layer 7 (HTTP) data so sticky sessions would not work. New TCP connections from the client will be load balanced based on the NLBs routing algorithm.
Hi,
I was using the solution suggested below but with a tweaks like adding X-Forwarded-Proto header and handling redirects on webserver.
https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/
However, now I tried the second option of having an NLB with TCP:80 and TLS:443 listeners forwarding to TCP:80 and TLS:443 target groups pointing to a internal ALB's ip and using the lambda function to update the NLB -> ALB bindings. This works like a charm and now SSL offloading is taken care at the ALB.
Relevant content
- asked 2 years ago
- asked 2 years ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 2 years ago