Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm thinking of pushing out new versions of our web application using a DNS.

We are currently hosting our application using EC2 so my thinking is that we can launch a new instance, deploy the new application version to that instance, run some tests to ensure everything will run smoothly, and then point our domain to the new instance's IP.

Is this something we should consider? To me it seems like a good idea, but I'm also new to server hosting. If you've tried this have you run into any problems?

Thanks for any feedback.

share|improve this question
up vote 8 down vote accepted

Amazon has support for the exact feature you should use to switch live service from one instance to another. It is called "Elastic IP Address" and is described here:

The initial steps involved are:

  1. Allocate an Elastic IP address.

  2. Associate the Elastic IP address with your instance.

  3. Set your DNS to permanently point to the Elastic IP Address (so there is no DNS caching/propagation delay).

Steps 1 and 2 can be done with the EC2 command line or the web console. Step 3 is done with your usual DNS service.

When you are ready to switch to a different EC2 instance, simply change the Elastic IP Address to be associated with the new instance. It takes some seconds for the change to filter through the EC2 network devices and then you're back in business.

It's also possible to do this with an Elastic Load Balancer, but for single instances Elastic IP Address is probably simpler.

Elastic IP Addresses can also be used to resolve to the (changing) internal IP address of the current instance using a CNAME trick. Here's an article I wrote about that:

Using Elastic IP to Identify Internal Instances on Amazon EC2

share|improve this answer
Awesome reply, I really have no experience with EC2, and this sounds like its a much better option. – Matthew Oct 14 '11 at 20:11
This is the "correct" answer. The OP's scenario is exactly the sort of thing Elastic IPs were designed for. – Aaron Oct 15 '11 at 2:50
Awesome, thanks for the reply. This simplifies things a lot. – Brian D. Oct 20 '11 at 19:02

It can work, however you need to remember that DNS takes time to propagate. Plus, users may be using their local DNS cache. You can do it, but temporarily take down the front page of the "old version" server and set up a redirect to go to the "new" server's IP. That should cover the corner cases.

share|improve this answer
DNS does not PROPAGATE! Records are cached, it takes time for the caches to expire. – Zoredache Oct 14 '11 at 17:38
No need to be pedantic, @Zoredache. The functional result is the same. – ceejayoz Oct 14 '11 at 17:55
And as they expire, they refresh with updated information. The ultimate effect is propagation. RFC 1034/1912 both refer to it as propagation. Let's keep it simple - the OP stated he is new to server hosting. – Matthew Oct 14 '11 at 17:57
RFC1034 is referring to Wildcard RRs not propagating across zone boundaries and RFC1912 is referring to zone transfers between primary and secondary name servers when it refers to propagation. Yes, it's pedantic to argue the point about the difference between propagation and caching but I believe that we do a disservice to the IT and end user community when we continue to refer to DNS caching as propagation. We all know it's not correct yet some of us continue to use the term propagation when we really mean caching, and we should stop doing so. – joeqwerty Oct 14 '11 at 19:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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