-1

I'm testing a virtual load balancer which is running on an EC2 instance. I'd like to be able to alter the setup and test the balancer under various conditions. In order to simulate a physical load balancer I've assigned three network interfaces to the instance:

  1. External (Primary) - An exposed interface to the web. The AWS rules will be set to allow all traffic to this interface. The load balancer will set up its own IP/port rules to filter this traffic internally. Connections to this interface will arrive from both inside and outside the VPC.
  2. Management - A dedicated interface with rules set to allow HTTPS traffic to the Load balancer's web interface or SSH traffic to a management shell running on the load balancer. Management connections will be established from computers which are outside the VPC.
  3. Internal - The interface through which all instances behind the load balancer will connect. Connections on this interface will be mapped to connections on the external interface by the load balancer. Connections to the internal interface will only arrive from instances which are inside the VPC.

In order to simulate physical connections I'd like to apply some AWS security group rules to these interfaces so that only connections between certain instances in the VPC are allowed (IE: they're plugged into each other). In order to do this I've created a separate security group for each interface (internal, management, and external).

My understanding is that rules within a security group are applied to all inbound and outbound traffic on the interfaces which belong to them. Since each interface in this setup serves a distinct role I'd like each interface to belong to one (and only one) security group.

What's unclear to me is what it means for an instance itself (as opposed to its interfaces) to belong to a security group. My thinking is that since the load balancer instance will be communicating on all three interfaces that it should belong to all three security groups.

Unfortunately, when I apply the internal and management security groups to the instance it forces the external interface to also be in the internal and management security groups.

Likewise, when I remove the internal and management security groups from the external interface it removes the instance from those security groups too.

Are security groups applied to an instance just a superfluous configuration shortcut (IE: only the security groups applied to the network interfaces actually matter), is there some other way to achieve the configuration that I want, or am I thinking about the problem wrong and there's a reason for AWS to prevent this configuration?

Alex Jansen
  • 123
  • 5
  • 1
    Can you describe *what* are you trying to achieve from the *high level perspective* instead of focusing on the *how* to do it with security groups? Your setup looks very complicated - perhaps we can design something simpler and easier to implement if we knew what are you trying to achieve? – MLu Nov 20 '18 at 21:04
  • @MLu alright I've added more details. – Alex Jansen Dec 13 '18 at 21:34

2 Answers2

3

While it might be implied that AWS instances have security groups, in practice network interfaces have security groups. Each interface (provided with the instance or an ENI) can have its own security groups. Any security group can be applied to as many network interfaces as you need.

Tim
  • 31,888
  • 7
  • 52
  • 78
2

Because that's how it works, and how it's documented to work.

The ability to apply a security group to an instance is just syntactic sugar. As documented, it applies the security group to that instance's primary network interface.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • Yes, the documentation states that "you can change the security groups associated with the instance, which changes the security groups associated with the primary network interface (eth0)" - Unfortunately, it was never clear to me after reading the documentation that this is just syntactic sugar. – Alex Jansen Dec 13 '18 at 21:41
  • Oh, it gets more confusing still. EC2 Classic (without VPC) actually did work that way years ago. So there's some outdated stuff on the Internet that you might have read. – Michael Hampton Dec 13 '18 at 21:44