How to serve your website on port 80 or 443 using AWS Load Balancers

Tim Fogarty
tfogo
Published in
6 min readJan 22, 2017

Linux servers limit non-root processes from binding to ports less than 1024. That’s a problem if you want to serve a website over HTTP or HTTPS which have default ports of 80 and 443. If you try to run code which attempts to bind to port 80 for example, you may receive an error like Error: listen EACCES 0.0.0.0:80.

One way to solve this problem is by using iptables — the linux firewall. You can run an iptables command to open ports 80. Alternatively, you can use an iptables prerouting command to forward all incoming requests on port 80 to the port you’re running your server on. If you want to look into using iptables here are a few resources.

A simpler solution on AWS

However, if you are running your server on an EC2 instance on AWS, you can more easily solve this problem without having to deal with complex iptables. By creating an AWS Load Balancer, you can let the load balancer listen on port 80 or 443 and have it route traffic to another port on your EC2 instance.

Usually, a load balancer sits in front of multiple EC2 instances and manages traffic coming in. It distributes the traffic evenly among instances so one instance doesn’t get overloaded. AWS Load Balancers can also do a bunch of other clever things, such as making sure that connections from Asia get sent to EC2 instances based in Singapore. If you’re interested in finding out more about what they can do, check out the Application Load Balancer page. But even if we only have one EC2 instance, load balancers are still a handy way to just forward ports.

Setting up the Load Balancer

I’m going to assume you have an EC2 instance running with a webserver listening on port 3000. If you’re not sure how to get to that point, check out this tutorial.

From your EC2 console, click Load Balancers in the side menu then click the Create Load Balancers button.

You’ll now be presented with a choice of creating an Application Load Balancer or a Classic Load Balancer. You can use either one. The Application Load Balancer has a bunch more features but the Classic Load Balancer is slightly quicker to set up. Since the Classic Load Balancer does everything we need for this use case, we’ll just use that.

Next, choose a name for your load balancer. Here I’ve used the name load-balancer-1. By default your load balancer will have a rule to forward incoming traffic on port 80 to port 80 on your EC2 instances. Go ahead and change that to forward to port 3000 on your EC2 instances (or whatever port your webserver is listening on).

You can also add rules here. For example, if you wanted to create a rule for HTTPS, you can add that now. Once you’re done, go on to the next step by clicking the Next: Assign Security Groups button.

Just like your EC2 instances, your load balancers belong to security groups which dictate which ports they are allowed to receive data on. For our load balancer to work, it has to be in a security group that allows connections on port 80. You can choose a security group you already have. Alternatively, select Create a new security group and AWS will automatically create a group with the rules you need. Once you’ve done that, click Next: Configure Security Settings.

You won’t see anything on this page unless you’re setting up your load balancer to accept traffic on port 443 (HTTPS). If you are setting up HTTPS on your load balancer, this is the page where you set up your SSL certificate. You need to set up an SSL certificate in order to use HTTPS. Learn more about setting this up here. Click Next: Configure Health Check to move on.

Only visible if you’re setting up HTTPS

The load balancer will ping your webserver every 30 seconds to check to see if it’s responding. This is called the health check. When the load balancer is managing traffic for multiple instances, if one of the instances fails for some reason, it will reroute traffic to the other instances.

We’ll make the load balancer ping / to see if our server is alive. Make sure that the route you put in here will send a 200 OK response when a GET request is made to it. Otherwise the load balancer will think your webserver is broken and won’t forward any traffic to it.

Next you get to decide what EC2 instances will be in the load balancer. If you choose multiple instances, the load balancer will attempt to split traffic equally between them. But you can just add one instance and the load balancer will do its job just forwarding traffic to that one instance.

You can now pass through the Add Tags stage, and move on to the Review stage.

Here you can review your load balancer and launch it.

After you launch your load balancer, you can see it on the Load Balancers tab of the EC2 console. Under the description tab you can see a DNS name for your load balancer. Navigate to that URL in your browser to see your website. If you see your website, congratulations! You successfully set up a load balancer for your server.

If you get an error going to that URL, a common problem is the load balancer thinks your server isn’t working. If your instance is listed as OutOfService in the Instances tab, that means your instance isn’t responding to the load balancer’s health check.

Make sure your webserver is running correctly on your instance. You may have to wait for the health check to recognize your instance is healthy. By default it needs 10 healthy responses which takes 5 minutes. Finally your health check may not be pinging the correct URL. You can review and change the health check settings on the Health Check tab. Hopefully this should sort out any issues with your health check.

Your instance status should say InService.

Next Steps

Now that you have a load balancer set up, you might want to set it up to use your own custom domain name. You can find out more about how to do that here. Load balancers are a key part of production grade applications. You can find out more about the kinds of problems load balancers can solve on AWS’s documentation.

--

--

Tim Fogarty
tfogo
Editor for

Developer Advocate at MongoDB, Previously DevRel at mLab, Commissioner at Major League Hacking. I like to code things.