April 3, 2013
A lot of people starting with EC2 immediately turn to Elastic IPs as the way to route traffic to instances. I did. Here’s how a newcomer would typically set up a database server:
db.example.com # your domain's DNS |-> 220.127.116.119 # Elastic IP
That’s typical when you manage DNS and the network but it isn’t optimal when you’re on something like AWS where you don’t manage all of the DNS or all of the network. The method does have its merits (see later) but for most use cases it’s not necessary. It’s also not practically scalable as Amazon prefers to limit you to 5 Elastic IPs. Once you understand how DNS resolves within EC2 you’ll likely find yourself moving away from Elastic IPs. You’ll be happier. You’ll be fine. It’s simple. And you can combine it with DNS from your own domain. Here’s how DNS would resolve to that same database server:
db.example.com # your domain's DNS |-> ec2-12-34-56-789.compute-1.amazonaws.com # public AWS DNS |-> 18.104.22.1689 # external IP |-> 10.11.12.13 # internal IP
One thing you’re seeing is conditional resolution. If the machine making the call is inside of EC2 DNS will resolve to an IP internal to EC2’s network. If you’re outside you’ll get a publicly reachable IP. Being able to use DNS is always a plus. Being able to use it within EC2 and have entries resolve to internal IPs can have cost and arguably performance benefits. It also makes it much easier to secure services using EC2’s Security Groups. (That’s another subject but you want this.)
Now imagine a case where your database server dies and you want to point your services to the failover database server. You would simply edit your domain DNS to point to the EC2 instance running the failover server. With a typical TTL of 5 minutes on your DNS entries your apps would be back online relatively quickly (given a “catastrophe” such as losing a database server).
Having said all that, if you have a small, finite and discrete set of critical services there are ways to reroute traffic from one instance to another that may be better suited to your needs. One is, indeed, re-mapping an EC2 Elastic IP from one instance to another, as could be done with the first configuration. That would likely take effect faster than using the public DNS scheme I suggested (assuming you don’t want to muck with DNS TTLs - yet another subject). But weigh the costs and don’t get hung up on Elastic IPs. You’ll run out of them quickly and they don’t do much for you. Learn and use the EC2 DNS resolution. The flexibility and security benefits are usually well worth it.