Load Balancer and EC2 in same subnet?

Question

I have a custom VPC with 3 public subnets and 3 private subnets. I have three ec2 instances with elastic IP addresses in the public subnets taking traffic on port 80 (security group is configured to allow access on port 80 in public subnets which are behind an Internet Gateway). I created an Auto Scaling Group and linked it with the three public subnets to increase/decrease instances dependent on traffic. I attached a Target Group to the Auto Scaling Group with access to port 80. Now I plan to create an Application Load Balancer and attach that Target Group to it so that the Load Balancer can distribute load using the Auto Scaler.

In the AWS docs 'Application Load Balancer Getting Started', it states the following:

Before you begin: Decide which two Availability Zones you will use for your EC2 instances. Configure your virtual private cloud (VPC) with at least one public subnet in each of these Availability Zones. These public subnets are used to configure the load balancer. You can launch your EC2 instances in other subnets of these Availability Zones instead.

Notice at the end of the paragraph it says 'instead', as if you should not have EC2 instances configured in the same public subnets as your Load Balancer. Am I interpreting this correctly? You should not have EC2 instances and Load Balancers in the same subnet?

Answer 1

The best practice is to have your web, app and db servers in private subnets and only the actual front end - which is ALB in your case - in the public subnet. The reason is that web, app and db servers shouldn't be accessible from outside even if by accident (e.g. through security group left too open).

Technically it will still work to have both the ALB and the instances in public subnet but it's not recommended for the above reason. Also make sure to lock down access to the instance port 80 and 443 only from the ALB SG if you don't want any direct traffic.

Hope that helps :)

Answer 2

To add a little extra to @MLu's answer, and to be even more paranoid...

You may wish to set up a tiny server in yet another subnet as a "jump box". Allow SSH access to the jumpbox subnet from the outside (port 22), but only allow SSH access to your app server subnet from this jumpbox subnet.

With this set up the only way to access your app server is by first logging into the jumpbox, and then doing an extra ssh hop to your app server. There is no other path for ssh from the outside world to your app server.

If this becomes a nuisance for initial set up or debugging, you can invest 15 minutes (or more, it's fiddly the first time) setting up twin ssh tunnels to go from your local machine straight through to the app server.

Most of the time you can leave the jumpbox shut down, so there is no ssh path through to the app server. For extra paranoia, you can restrict access to the jumpbox subnet to your specific (whitelisted) IP address.

If you are still concerned about hackers, you can also set up sshd on the jumpbox to listen on other than the default port 22, so a hacker's port scanner is slightly less likely to find it when your jumpbox is running.

Ideally, leave no information on the jumpbox to suggest the IP address of your app server (i.e. no scripts), so a hacker that somehow does get into the jumpbox will have no clues how to proceed further.