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, 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.


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:

worker-1   IN  CNAME  xx-xx-xx-xx.compute-1.amazonaws.com.

Now, worker-1.company.com will resolve to the private IP if queried from inside, and the public IP from outside.

  • when instance launched with, --private-ip-address, the ip stays the same, and is seen as such across all instances in all zones (and regions, if you set that up) – nandoP Dec 19 '13 at 16:53

It's not perfect, but you can add explicit mappings from the FQDNs to the private IPs in the hosts file of each of the instances. So your code will use an FQDN but networking will actually use private communications (which is more secure anyway).

This is a reasonable option if you have a small, relatively fixed, set of instances. You should probably automate this process, if possible.

You can also use Route 53, Amazon's DNS as a service. Map your FQDN to the public DNS name of the instance. Inside EC2, this will map to the private IP. You will still need to automate this using the route 53 API.

  • i dont think the OP is trying to spoof public dns names to private instance IPs,.... which is a good trick with /etc/hosts, but not relevant here i think – nandoP Dec 19 '13 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.