In my current line of work, dealing with Amazon’s “Elastic” Computer Cloud, I had to cope with the problem of getting a stable hostname for a “master” instance when dealing with “slaves”. I was appalled by the fact that Amazon does not provide a way to assign a “role” or “class name” to their instances, so to have them recognized from within their network.
When I was pointed out at multiple documentation showing how to achieve that feature, I knew that the problem wasn’t that Amazon failed to to think that through, but rather that they are most likely trying to get more money out of the users with these need. The common suggestion to solve the need to identify a particular instance, between executions, is to use their “Elastic IP” feature (which – like many other things they call “Elastic” – is not really elastic at all).
The idea behind this solution is that by assigning a public IPv4 (and keep in mind this is a precious resource nowadays) to the instance, you can pick up the reverse DNS for it (for instance 188.8.131.52 will reverse-resolve to ec2-184-73-246-248.compute-1.amazonaws.com), and use that in your intra-EC2 requests… once using EC2’s own nameservers, ec2-184-73-246-248.compute-1.amazonaws.com will resolve to the (dynamic) internal IP address (10.0.0.0/8) of the instance the IP was assigned to.
All fine and dandy, and this can be set up cleanly with Rudy as well. The problem here is… the IP is not free. Oh yes, the documentation will try to tell you that you won’t have to pay for it… as long as you use it. But it’s definitely not free, especially during the development phase of a project. As long as the address is assigned to an instance, you won’t pay for the Elastic IP service (but you will pay for the running instance); if you don’t have an assigned instance, you’ll end up paying $2.4 per day for the IP address to be reserved.
This is definitely one of the cases where Amazon’s limitation seem totally artificial to get you more money, as much money as they can get from you. D’oh!
What is my solution to this problem? It’s very simple:
net-misc/ddclient. The IP address you’re looking for is the one, inside the instance, that is assigned to the eth0 interface. Just tell ddclient to fetch the address and use it on a classic DynDNS (or similar) hostname service. It doesn’t matter that you’re feeding them a local IP address (in the 10.0.0.0/8 range); you won’t be able to use the same hostname for external and internal dealing, but it’ll definitely cost you less.