Recent AWS Customer Success Stories & Videos

More AWS Customer Success Stories...

« New AMI Catalog and New AMI Launch Button Are Now Available | Main | Cost Savings in the Cloud - foursquare and Global Blue »


TrackBack URL for this entry:

Listed below are links to weblogs that reference Multi-Region Latency Based Routing now Available for AWS:


Feed You can follow this conversation by subscribing to the comment feed for this post.

David Phillips

Does Route 53 support the recent "Client subnet in DNS requests" specification (, allowing Latency Based Routing to work properly with OpenDNS and Google Public DNS?

Anh-Tuan Gai

Nice feature, but a lot of information is missing to be able to compare to competitors:
- How latency measurements are done (by servers or end-users) ?
- How latency measurements are aggregated (country, city, ISP) ?
- How dynamic is it? Does the measure change every 10s, 1mn, 30mn, 1h? What is the sample time (10s, 1mn, 30mn) ?

Other questions:
- Will simple GeoIP routing be available soon? (it should be simpler to implement than LBR while more flexible)
- Will availability monitoring of any IP/host be available soon... so we can use Route53 with fallback routing?
- Will performance monitoring of any IP/host be available soon... so we can use Route53 for performance routing?

Colm MacCárthaigh

@David At this time Amazon Route 53 does not support the edns-client-subnet feature. Route 53 is under constant improvement, so please stay tuned.

@Anh-Tuan Latency measurements are to end-users, we measure the round-trip time between the TCP SYN|ACK and ACK packets of an anonymized client-initiated measurement connection. We also have a mechanism to correlate these measurements with the DNS resolver used, and all latency measurements are then aggregated by DNS resolver. The measurements are on-going all of the time with many millions of samples per day.

We'd love to hear more about the specific use-cases you have in mind for GeoIP routing, availability monitoring and performance monitoring. We are constantly working to improve Route 53 and really value feedback that helps us design each feature. Feel free to reach out to our team directly via our page at (You can ignore the limit fields).


It's unclear to me whether or not this will work with non-AWS endpoints. Can you clarify?

Colm MacCárthaigh


It is possible to use Route 53's Latency Based Routing feature with non-AWS endpoints. We don't restrict what IPs or CNAMEs you can tag with a region, and we will route traffic to those IPs or CNAMEs "as if" those IPs or CNAMEs were hosted in whichever AWS region you choose to tag.

Because our on-going network latency measurements are specific to the AWS regions themselves, the routing decisions made for non-AWS endpoints may not be optimal, however we've left it open to use our latency based routing as an approximation.

Marco Slot

Hi Anh-Tuan Gai,

We are constantly gathering latency measurements between most /24 subnets on the Internet and AWS regions to construct the dataset for latency-based routing. Users of latency-based routing are not directly involved in taking these measurements. The latency measurements are aggregated per DNS resolver, which in most cases corresponds to an ISP. The routing decision is based on the resolver making the request.

In response to David's question, we do not currently support the edns-client-subnet extension, which would allow separate routing decisions per subnet, but may consider adding it in the future.

The rate of change depends on conditions on the Internet. For the majority of end-users, the region with the lowest latency will not change very often. However, you should keep in mind that users may "suddenly" be routed to a different region when designing your application.

Thank you for your feature suggestions. We don't have any specific timelines to share, but would love it if you could elaborate on specific use-case or ideas here or on the Route 53 forums:


Marco Slot

Hi Rob,

You can point a latency record at any endpoint and assign it to the nearest AWS region. Routing will be based on measurements between Internet users and the AWS regions, but if your servers are not too far from the AWS region this should only lead to sub-optimal routing decisions for a small percentage of end-users for whom the difference between different endpoints is small to begin with.


Jeremy Bowers

Would the frequency of those latency measurements and the speed of aggregation/routing adjustments make for an automated failover? What kind of timeframe would it take for a regional outage (such as a problem with say, us-east, producing time-outs or extremely high latency) to result in traffic being routed to another region? Seconds? Minutes? Hours?


Colm MacCárthaigh


At this time, a regional outage wouldn't have a direct effect on the routing decisions; the absence of measurements doesn't contribute towards the averages observed. Adding features to Route 53 to handle regional outages is definitely a priority, and we're interested to hear any feedback you have around how it may be used.

The time periods it can take for measurement data to turn into meaningful routing changes varies by resolver and client networks. Changes in routing for busier networks with more users can be detected more quickly than less busy networks - but for the moment; hours and days is where to set expectations. We're always working on hard on making the process as fast as we can make it, but our experiences with CloudFront have taught us that the vast majority of internet paths are stable over many weeks.

Jeremy Bowers

Thanks for the quick response. That's extremely helpful to know. Rapid automated failover at this layer can also have it's drawbacks if detected poor performance is due to application, system issues, and/or poor scaling vs. a specific regional network or infrastructure issue. (rapidly moving traffic to another region could just cause more regional failures with the resulting load spikes). It's probably better that this is a bit on the slower side without some well-thought or highly customizable failover logic when working with auto-scaling multi-region web services.

Thanks again!

Brian Kirkbride

Love the constant stream of updates! You guys are on fire!

What I want to know is when will Route53 support ALIAS records to a _different_ hosted zone? This would allow for really powerful setups where many apex domains could react to changes quickly. One API update to the source zone's records and all the ALIASed records would update after the TTL.


Nice feature - been waiting for something alike for some time now. One last feature that is still missing on my list is fail-over.
If, for example, I'm using LBR to delegate traffic either to an instance in US-West-1 zone, or to one in EU-West-1, and EU-West-1 goes offline, would everybody closest to EU-West-1 be getting errors - or would the LBR simply 'disable' the EU-Records by deciding always on US until EU-West becomes available again? (That's 'your' responsibility ;) ).
If my application in EU crashes (obviously 'my' resposibility ;) ), it would still be nice to have a 'fallback' entry - I know far from perfect as a complete failover solution - but BIND had an option that allowed you to set the RR order to fixed (I think rrset-order fixed). With this feature you could specify a second IP/Alias/CNAME to always be listed, so that the browser could contact it in the event of the first one failing.
Something like this:
web.domain is LBR record with CNAME
eu.domain for EU-West-1 and
us.domain for US-West-1

eu.domain is a fixed list of A records containing -> EC2 instance in EU-West-Zone -> EC2 instance in US-West-Zone
us.domain is a fixed list containing -> EC2 instance in US-West-Zone -> EC2 instance in EU-West-Zone

Because R53 hands out those records in Round-Robin fashion, this 'fallback' is not possible :(. Weighting would not help either,...
BTW, I think BIND settings for rrset-order are on a zone level, and can be set differently for different types of records (A,MX...). Just as a hint on how to implement such a feature ;).

Well, but not to appear as one that only nags, I like the implementation so far. It's also pretty cool that it's not restricted to target IPs within Amazon, and it's very simple to configure - nice service, I appreciate the work going on behind the scenes to make this work.



Colm MacCárthaigh


For scalability reasons, Route 53 has been designed to manage hosted zones in shards. Each Route 53 name-server and our API endpoints only have to know about hosted zones in specific shards. Hosted zones that are valid targets for ALIASes are a bit different though; since they can be referenced by any zone in any shard we have to replicate their data to all shards.

For that architectural reason, although we're open to allowing cross-hosted-zone ALIASes, today it would probably have to come at an increased cost for those hosted-zones. We'd love to hear more about the types of usage you have in mind and if they could fit in with the present architecture and cost-model, or if we should consider some architectural changes to remove the limitation.

Colm MacCárthaigh


Thanks for the feedback, we'll incorporate it right into our design process.

Anh-Tuan Gai

Colm, Marco, thank you for you answers, I understand a bit more how it works.

If we could manage our own measurement streams that could be taken into account by an MBR (Measurement Based Routing) tied to Route53 and a powerful multi-location monitoring service, this would be a great CDN solution.

Klaus Conrad


great feature - would love to start using this but we currently need the ability to use DNSSEC in our services.. is this something that is planned for inclusion in future?


Roland Turner


> Route 53 has been designed to manage hosted zones in shards
> For that architectural reason, although we're open to allowing cross-hosted-zone ALIASes, today it would probably have to come at an increased cost for those hosted-zones

This makes a few things clearer, thanks!

Would you be open to special-casing the s3-website-* domains for ALIASing? (Not hosted on Route53, I know, but they are "under the same roof".)

This would make S3-bucket-at-zone-apex hosting possible without having to (a) host an additional web-server or (b) use an external DNS service.

Slavi Nikolov

Great work and great comments guys!

OK, but how will you deal with well known open DNS resolvers (like google, or OpenDNS) ?
You will be optimizing towards the DNS resolver, not the end user then ?
How will it deal with a EU user, who has added a Google DNS as DNS resolver, after he gets his optimized answer from R53 it may be optimized towards the Google DNS server and he'll get US node instead of closer EU node ?
So how do you map end user request with the DNS resolver he used ?



@Jeff, I just wanted to thank you for such a nice write-up, it was very helpful!

The comments to this entry are closed.

Featured Events

The AWS Report

Brought to You By

Jeff Barr (@jeffbarr):

Jinesh Varia (@jinman):

Email Subscription

Enter your email address:

Delivered by FeedBurner

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30