Load balancers in AWS

ELB (Elastic Load Balancer) is somewhat of a misnomer. While it does provide a way to distribute load across a server farm, it can be used for far more than that. The most important use of an ELB is simply to provide a manageable, external facing end point – so that your web server does not have to be exposed (directly) to the internet. This is desirable for several reasons – security being the first and foremost. This also implies that even if you DO NOT have a server farm (i.e. only ONE Web Server instance), you may still be better off with an ELB on the front.

AWS ELBs can be used in two different network configurations  – EXTERNAL facing – and INTERNAL facing.

1. An Internet-facing load balancer has a publicly resolvable DNS name.
2. An internal load balancer does not have a publicly resolvable DNS name, so it can only route requests from clients with access to the VPC for the load balancer.

Inbound Traffic – Web and Database Servers – Use ELBs.

Typically, only your web servers need to be internet ‘facing’ – the database servers are usually on your intranet – and do not need any publicly routable traffic. The database servers only need traffic from the Web Servers.

To accommodate this design, we provide TWO load balancers – an EXTERNAL ELB – for the web servers – and an INTERNAL ELB – solely to route traffic from the web servers to the intranet DB Servers. See the diagram below.

The web SERVER itself can still reside on your intranet – it is just the ELB that will be public facing. As long as clients can reach the ELB, they should be correctly routed to the web server (even if it is on an intranet).

Internal Load Balancer to protect the private instances

Use a SEPARATE Security Group for your ELB

In AWS, we can set up a security group that contains the ELB and accepts only TCP port 80 and 443 from the Internet.  See the table below for how this security groups needs to be configured.

What about outbound traffic ?  – Use a NAT security group

Your web and database servers will typically live inside your intranet (on a private subnet). This means that they will not have a DIRECT route – in from or out to the Internet (the only route IN is via an ELB).

At times, it may be necessary to allow internal instances to connect to the Internet  (e.g. for OS security updates). Enter NATs. 

To allow the internal EC2 instances (web and database servers) to access the Internet, we can use a Network address translation (NAT) instance. This is typically created inside its own security group.

With a NAT instance, you can securely route traffic from private subnets out to the Internet, while denying any inbound connectivity from the Internet.

Security Features of ELBs – DDos Prevention etc.

As stated at the start of this post, an ELB is much more than a load balancer. It provides certain security features out of the box.

Denial of Service (DoS) attacks – An ELB will only allow well-formed connections to your web application on ports and protocols that you specify. This provides an additional layer of DDoS resiliency.

All access to the web servers needs to be via an ELB.  In AWS, we can set up a security group that contains the ELB and accepts only TCP port 80 and 443 from the Internet.

It then distributes these requests to EC2 instances in the web application server security group.

Some things to consider when using ELBs

While ELBs may be the greatest thing since sliced bread, they are not without a few downsides. The first one is cost  – and although this isn’t significant, it is still more expensive than an Elastic IP (which accomplishes the same thing – for free).

The second disadvantage of ELBs is that they can be ‘over protective’. If they sense a DDoS attack, they simply shut themselves down. Worse, we do not have any control over when they come back up.

Summary

ELBs are a useful AWS construct that help ‘hide’ your public facing assets from the internet.  This is actually the more common use case – as opposed to actual LOAD balancing (which is what they were designed for).  Some best practices include ‘Separate Security Group for ELB’, ‘Separate Security Group for WEb Servers’ ‘ Separate Security Group for DB Servers’  and ‘INTERNAL ELB for DB Servers’.

ELBs are not without their drawbacks – the primary drawback being the downtime an ELB can entail – in the event of an unknown DoS attack.