I was facing massive issues with an ELB configuration which had the following set up:
- All instance were part of an AWS VPC
- Three subnets, one public, two privates
- Both private subnet contained the web containers (tomcat) in two different availability zones
The issue that I was facing was that whatever I did, the LB wasn’t routing requests to my instances. The initial configuration was such that my ELB instances were part of the same subnets as my tomcat instances. As such, using curl against those always worked, but not using the ELB’s public address.
After some frustrating googling, I came up with the solution:
1. Your ELB instances cannot be launched in a private network attached to an Internet Gateway (NAT instance).
2. Conversely, you need to set up public networks which “shadow” your private networks in the same respective availability zones. In my case, I had two private subnets 10.0.1.0 and 10.0.2.0; I created two public subnets 10.0.10.0 and 10.0.20.0 to accomodate my ELB instances.
3. You need to add routing from those new public subnets to your private original subnets, i.e. add the public route to these subnets and add the internet gateway for accessing the private networks. You can set this up in VPC -> Subnets. Here’s an example:
In your subnet view, it should look like this:
Remember that the public shadow subnets (10.0.10.x and 10.0.20.x) are connected to the public route, while the private subnets (10.0.1.x and 10.0.2.x) are attached to the nat interface.
4. You also need to adjust your security groups. The new subnets need to have explicit access to your application’s ports in your private networks.
When you’ve done all that, you can create your ELB – if you already have an ELB that doesn’t work, delete it. Amazon will not properly clean up ELB instances in private subnets and you’ll end up with more nodes than you asked for, some of them not working.
These are screenshots describing the relevant sections of the ELB creation process: