I have several instances running in the same security group(Say: Group-A) that needs to talk with each other, in particular, port 4369.
Each instance has a different Elastic IP.
The Security Group is configured to allow inbound traffic via TCP:4369 Soruce:sg-XXXXX (Group-A)
However, instances can only talk to each other via internal IP (10.xxx.xxx.xx) or Amazon Public DNS: ec2-ELASTIC-IP.compute-1.amazonaws.com(Apparently Amazon will translate this to the internal IP).
If I use Elastic IP, it won't work. If I use my own FQDN that pointed to the Elastic IP, it won't work.
If I change the source in inbound rule from sg-XXXXX (Group-A) to 0.0.0.0, it works with my own FQDN and the Elastic IP. But we won't use this for security concerns.
If I remove the inbound rule, nothing works, even use the internal IP.
So what should I do if I want to use my own FQDN? (worker-1.company.com -> Elastic IP), which is much more readable and easier to manage.
Best Answer
The behavior you describe is normal, since when communicating between instances via elastic IP, the identity of the machine within the security group -- for purposes of security group configurations relying on an sg-xxxxxxxx source -- can't really be established with full confidence, because translating the addresses sends the traffic (presumably) through intermediate hardware and the traffic no longer is being seen as originated directly from the instance.
The solution is to name your hosts in DNS with CNAME records pointing to the public DNS record, instead of A records pointing to a specific IP address.
In the company.com DNS zone:
Now, worker-1.company.com will resolve to the private IP if queried from inside, and the public IP from outside.