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

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2023-06-13T16:16:16.630Z
With Amazon's Session Manager, as well as the direct serial port access to instances, it's possible to get a shell session into both ECS containers and EC2 servers without needing to punch holes in security groups or run bastion servers/jumpboxes. We now do that for everything, and it's a breeze once you're past the uphill setup.
Per
CC BY-SA 4.0
2020-01-07T08:48:55.950Z
2020-01-07T08:48:55.950Z
Philip Callender
<p>The best practice is to have your <strong>web, app and db servers</strong> in <strong>private</strong> subnets and only the actual <strong>front end</strong> - which is <em>ALB</em> in your case - in the <strong>public</strong> 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).</p>

<p>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.</p>

<p>Hope that helps :)</p>

CC BY-SA 4.0
2020-01-07T00:50:38.030Z
Yes, you're right. I already had the db server in private subnet, but I thought to have web server in public subnet. But since traffic will be handled by the ALB, it does not make sense to have the web server in public subnet accessible to outside world.
Daniel Viglione
CC BY-SA 4.0
2020-01-07T00:43:44.460Z
2020-01-07T00:43:44.460Z
MLu
<p>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.</p>

<p>In the AWS docs 'Application Load Balancer Getting Started', it states the following:</p>

<p>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.</p>

<p>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?</p>

<amazon-web-services><load-balance>
Load Balancer and EC2 in same subnet?
Daniel Viglione
# Load Balancer and EC2 in same subnet?

(Asked by: username_0 on 2020-01-07)

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?

**Tags:** amazon-web-services, load-balance


---

## 2 answers

### Answer by username_3 on 2020-01-07. Score: 4 | Accepted answer

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 :)

> **Comments:**
> **username_0**: Yes, you're right. I already had the db server in private subnet, but I thought to have web server in public subnet. But since traffic will be handled by the ALB, it does not make sense to have the web server in public subnet accessible to outside world.  

---

### Answer by username_1 on 2020-01-07. Score: 1

To add a little extra to @username_3'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.

> **Comments:**
> **username_2**: With Amazon's Session Manager, as well as the direct serial port access to instances, it's possible to get a shell session into both ECS containers and EC2 servers without needing to punch holes in security groups or run bastion servers/jumpboxes. We now do that for everything, and it's a breeze once you're past the uphill setup.  

---

