How to make Route53 up to 10x faster in one single step

Many startups use Amazon Route53 today — it’s affordable and got a great set of features. One side that many developers avoid discussing though is Route53’s performance, and believe me (or believe this site) it doesn’t perform well!

Luckily, we found a way to make it way, way faster. If most of your users reside in the same geographical area (eg. Europe) it will give you a 10x boost!


We live in the world of fast pace and low latency. Things in Internet are getting faster and faster — practically every major website uses a global content delivery network to display your image or video as quickly as possible. Most DNS providers use AnyCast technology meaning that each nameserver has, in fact, multiple instances, and user will be routed to the closest one. Well, that’s the idea in general but it seems to be not the case with Amazon’s Route53! :)

Route53: the problem

If you ever created a zone in Route53, you are pretty familiar with the following tab:

This is how your zone typically looks in Route53

Amazon assigns four weird looking nameservers to every zone it creates. These nameservers are supposed to be AnyCast so if you are asking “what’s the IP address of” from Australia — you normally expect to receive a reply from within Australia itself or from somewhere nearby. Let’s see if that’s true?

Let’s do some traceroutes, and let’s do them from Amazon EC2 instance in Sydney to avoid “but it’s probably a peering problem” arguments:

traceroute to (, 30 hops max, 60 byte packets
6 vl2928.sw-1– ( 1.101 ms 0.470 ms 3.722 ms
7– ( 3.802 ms 3.352 ms 3.523 ms
8 ( 3.381 ms 3.378 ms 3.371 ms
9 xe-0–0– ( 3.350 ms 3.351 ms 3.348 ms
10 ( 3.717 ms 3.874 ms 3.973 ms
11 xe-0–0– ( 140.201 ms 140.205 ms 140.185 ms
12 ( 146.452 ms 140.086 ms 140.085 ms
13 ( 175.559 ms 182.553 ms 175.542 ms
14 ( 169.283 ms 171.902 ms 177.460 ms
15 ( 207.058 ms 198.091 ms

As we can see, Atlanta was chosen in this case. Distance between Sydney and Atlanta is roughly 15,000 km. If you are not good with networking and traceroutes, you could do this:

$ time dig

And you will get nearly the same latency — 220ms. So, doesn’t matter how cool is your CDN or how close your API is, your users will spend extra 220ms resolving your domain name. It’s a common trend today to set DNS TTL pretty low, so you can expect users to do this query again and again!

The second nameserver is in Atlanta as well, while third and fourth are in Australia (hooray!)

You can use this one-liner in the terminal to test all 4 at once:

$ while read -r host; do ping -c 1 $host; done <<< $’\\\’ |egrep “rtt|statistics”
 — — ping statistics — -
rtt min/avg/max/mdev = 202.203/202.203/202.203/0.000 ms
— — ping statistics — -
rtt min/avg/max/mdev = 219.252/219.252/219.252/0.000 ms
— — ping statistics — -
rtt min/avg/max/mdev = 13.949/13.949/13.949/0.000 ms
— — ping statistics — -
rtt min/avg/max/mdev = 0.902/0.902/0.902/0.000 ms

Let’s test from another few points in Australia (different providers) and compare.

Vultr Sydney:

 — — ping statistics — -
rtt min/avg/max/mdev = 209.292/209.292/209.292/0.000 ms
— — ping statistics — -
rtt min/avg/max/mdev = 227.579/227.579/227.579/0.000 ms
— — ping statistics — -
rtt min/avg/max/mdev = 12.426/12.426/12.426/0.000 ms
— — ping statistics — -
rtt min/avg/max/mdev = 0.845/0.845/0.845/0.000 ms

My office connection in Melbourne:

— — ping statistics — -
round-trip min/avg/max/stddev = 219.359/219.359/219.359/0.000 ms
— — ping statistics — -
round-trip min/avg/max/stddev = 203.459/203.459/203.459/0.000 ms
— — ping statistics — -
round-trip min/avg/max/stddev = 10.071/10.071/10.071/0.000 ms
— — ping statistics — -
round-trip min/avg/max/stddev = 14.901/14.901/14.901/0.000 ms

Telstra Melbourne: 193ms 157ms 1ms 11ms

AARNet Sydney: 184ms 316ms (routed to Marseille!) 11ms 1ms

InterNode Melbourne: 220ms 8ms 1ms 12ms

AAPT Sydney: 216ms 1ms 12ms 1ms

Optus Sydney: 250ms 196ms 12ms 1ms

We can see a pretty clear pattern now — somehow first two nameservers are always far-far away, while the latter two are somewhere nearby.

Therefore, removing .com and .net nameservers from both your domain record and Route53 zone will give you a very tangible performance boost — from ~100+ms average latency down to just ~10ms.


As shown above, Route53 always assigns two ‘sucker’ nameservers and two performant (network-wise) nameservers. By getting rid of two of them (and you don’t actually need four anyway — Cloudflare, world’s best DNS provider, uses 2) you can increase your DNS performance dramatically.

Asia and Australia should use .org and nameservers. Europe should use .com and .net nameservers. All nameservers work reasonably ok in the US (would be surprised if they didn’t). Therefore, you can’t use this hack to boost performance in Asia and Europe at the same time.

.org is the best performant nameserver on average, but I don’t suppose you are going to leave just one nameserver in the zone? :)

About us

PoweredLocal is a Melbourne-based wi-fi innovation startup. We host PHP, Ruby and Node.js microservices behind our newly baked API gateway.

About author

Written by Denis Mysenko, Chief Technical Officer at PoweredLocal

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.