Moving Ahead With Amazon Route 53

As you may know from my previous post, Amazon Route 53 is a highly available and highly scalable DNS service.

Today we have some big news for users and fans of Route 53:

• You can use a new alias feature to map the root or apex of your hosted zone to your Elastic Load Balancer.
• Route 53 is now considered Generally Available, and now has a Service Level Agreement, or SLA.
• You can now provide multiple answers to a single DNS question using a Weighted Round Robin model.

Aliases and the Zone Apex
A number of our customers use an Elastic Load Balancer in front of a fleet of EC2 instances. The EC2 instances host the web tier of their application. Unfortunately, due to the way that the DNS protocol works, there was no way to refer to the Elastic Load Balancer from the root (also known as the apex) of the domain. In Plain English, you could create a DNS entry that maps http://www.example.com to an Elastic Load Balancer but you couldn't do the same for http://example.com.

Because short, memorable URLs are always desirable, we've created a new aliasing system for Route 53. You can now map the apex of a hosted zone to an Elastic Load Balancer using an Alias record. When Route 53 encounters an Alias record, it looks up the A records associated with the target DNS name in the Alias, and returns the IP addresses from that name.

The DNS entries associated with an Elastic Load Balancer have a short (60 second) time to live, or TTL. This means that changes to the entries will be recognized and respected as quickly as possible. In order to allow all of our customers to benefit from this new feature, there is no charge for queries to alias records when the target is an Elastic Load Balancer (the only allowable target in this release).

General Availability and SLA
We launched Route 53 in beta form in December of 2010. Developers all over the world have eagerly adopted Route 53 and it now provides DNS services for a multitude of websites. The service is now officially generally available. The Route 53 Service Level Agreement offers 100% availability (measured at 5 minute intervals) and provides service credits as follows:

• A one day credit for 5-30 minutes of unavailability.
• A one week credit for 31 minutes to 4 hours of unavailability.
• A one month credit for more than 4 hours of unavailability.

Weighted Round Robin
A primary task of a DNS service like Route 53 is to answer the question "What is the IP address associated with this name?" You can now provide multiple answers for a name, and you can also control the relative frequency with which each one is used. This model is called Weighted Round Robin (WRR) DNS. You can use this new feature to implement a variety of different scenarios. For example, you could route different amounts of traffic to EC2 instances with varied amounts of processing power. Or, you could do some A/B or functional testing.

You can learn more about aliasing and WRR in the Route 53 documentation.

-- Jeff;

Comments

[Jesper Mortensen]

With regards to DNS Round Robin, I'm sorry to see the sentence: "you can also control the relative frequency with which each one is used."

No, you cannot. You can control how frequently a specific IP address is _emitted_ by Route 53. But DNS uses several layers of caching, and you cannot control how frequently downstream clients _use_ the records.

DNS Round Robin is a rough but workable hack at best. DNS Weighted Round Robin is worse. Basic example: You have 3 IPs for your website www.company.com . One of these is given out to the downstream DNS cache for HugeISP. HugeISP has very many customers; so now this IP address gets a disproportionally high share of the load, ignoring Route 53's weighting.

A classic piece on this is the Frequently Given Answer regarding DNS Round Robin:
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-round-robin-is-useless.html

[Mike]

I was very excited to start using it then i noticed there was no tab for it in the console, when is this coming?

[Pchaganti]

Released support for these features today - http://blog.ylastic.com/weighted-resource-record-sets-with-route53 and http://blog.ylastic.com/alias-resource-record-sets-with-route53

[Jeff Barr]

Here's a roundup of tools that include support for Route 53:

http://aws.typepad.com/aws/2011/02/new-location-for-route-53-and-cloudfront-route-53-tool-roundup.html

[Eric]

How would this work with Beanstalk? Can you provide any tips?

[Augusto Rosa]

Thanks for this but this does not address a main requirement for 50% of your audience. We need the ability to assign EIP to ELBs. Please.

I can't move my DNS into Amazon, that is not an option as I do not control it.

[Luigi Montanez]

The apex aliases are awesome. Please consider enabling them for S3 buckets as well. It sounds like this would solve the problem where static sites hosted on S3 can't use the apex.

[Derrick Martinez]

Support for this was added to the Interstate53 GUI (http://www.interstate53.com) last week. Thanks AWS for these great features!

[Ossip]

Good additions, zone apex works nicely, using Interstate53 :)

One thing: it does not work with the dualstack names for ipv6 compatibility.

To make it consistent the zone aliases should also work for S3 & CloudFront.

And a huge +1 to add GEO IP! Any timeline on this? The new weighted round robin support is not a feasible solution for multiple data center use.

[Alan D]

I'm really psyched to get "this stuff" working, and it's great that we can point a hostname (or apex) directly to a ELB instance, but what I'm looking for is tying a hostname directly to an _EC2_ instance, without having to go through the 'process' (hassle) of allocating and assigning an Elastic IP to the instance, and then setting up an A record to that Elastic IP.

Any plans (or way to that I've missed) create a Resource Record Set pointing to an EC2 Instance ID? (I've already searched the documentation and forums and didn't see anything, but that doesn't mean I didn't just miss it.)