By using AWS re:Post, you agree to the Terms of Use

Adding a static IP to ELB


Hello all,
Currently I am using application ELB. I want to add a static IP to my ELB as I wish to point a top level domain of a website (, whoes domain registrar is not Route53 (& cannot be) to my ELB. As far as I know, this won't work without a static IP as top level domain can't be pointed to by a CNAME. From documentation, I understand that adding a static IP is only possible on Network ELB. I have a few queries regarding this.

  1. Recently SSL termination has been enabled on Network ELB and it does not support Http to Https redirects so is there a workarount to enable Http to Https redirection using a Network ELB?
  2. If I enable Http to Https redirection on webserver (apache), it doesn't work as SSL certificate terminates at the Network ELB?
  3. Is it possible to disable SSL termination on Network ELB so that I can use a Network ELB in front of a Application ELB?
  4. Does Network ELB also handle sticky sessions?
  5. Does anyone know if there are there any near future plans to handle these issues?
2 Answers


Based on your requirements I believe you will benefit from this solution of placing an NLB in front of an ALB -

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.

answered 3 years ago


I was using the solution suggested below but with a tweaks like adding X-Forwarded-Proto header and handling redirects on webserver.

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.

answered 3 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions