Source security group isn't working as expected in AWS

Question

I have an EC2 node, node1 (security group SG1) which should be accessible from another EC2 node, node2 (security group SG2) on port 9200. Now, when I add an inbound rule in SG1

Answer 1

Are you attempting to connect to node1's public or private address? From the documentation:

When you specify a security group as the source or destination for a rule, the rule affects all instances associated with the security group. For example, incoming traffic is allowed based on the private IP addresses of the instances that are associated with the source security group.

I've been burned on this before by trying to connect to an EC2 instance's public address... sounds very similar to your setup, actually. When you wire up the inbound rule so that the source is a security group, you must communicate through the source instance's private address.

Some things to be aware of:

• In EC2 Classic, private IP addresses can change on stop/start of an EC2 instance. If you're using EC2 classic you may want to look into this discussion on Elastic DNS Names for a more static addressing solution.
• If you set up your environment in VPC, private IP addresses are static. You can also change security group membership of running instances.

Answer 2

Reason: Inter security-group communication works over private addressing. If you use the public IP address the firewall rule will not recognise the source security group.

Solution: You should address your instances using the Public DNS record - this will actually be pointed at the private IP address when one of your instances queries the DNS name.

e.g. if your instance has public IP 203.0.113.185 and private IP 10.1.234.12, you are given a public DNS name like ec2-203-0-113-185.eu-west-1.compute.amazonaws.com.

ec2-203-0-113-185.eu-west-1.compute.amazonaws.com will resolve to 203.0.113.185 if queried externally, or 10.1.234.12 if queried internally. This will enable your security groups to work as intended.

This will enable you to use an elastic IP as you simply use the Public DNS entry of the elastic IP. Also, having the DNS resolve to the internal IP means that you are not incurring bandwidth charges for your data between instances:

Instances that access other instances through their public NAT IP address are charged for regional or Internet data transfer, depending on whether the instances are in the same region.

Answer 3

The Public DNS didn't work for me. What I did instead was create a custom inbound rule using the security group of the other instance.