Build Your Own CDN On Aws With Route 53

Instant Domain Search is fast because it keeps an in-memory index of several domain name zone files and runs on fast servers. Each zone query is answered in microseconds. The slowest part of the domain search is the link between the client and the server. This is especially true for mobile networks. We are obsessed with speed, and are always looking for ways to make this site even faster.

If you want to learn how to build your own CDN using AWS, keep reading to see how we structured one for Instant Domain search. Building a CDN from scratch was a difficult process until recently, but new technologies have made it easy for anyone to accomplish.

How to Make a CDN

A few years ago, we started to use JavaScript to determine which server was closest to you. This technique significantly improved search performance, but does nothing to make the initial page load faster. Recently, we started serving all pages over HTTPS by default. This adds even more latency to the initial page load because we need to negotiate an HTTPS connection before the browser knows where to download static resources like CSS and JavaScript.

Using a content delivery network (CDN) to host the site can make it hard to propagate changes, use custom redirect rules, and be expensive to host with your own secure certificate. We also wanted to roll out HTTP/2 (formerly SPDY). The HTTP/2 protocol is much more efficient than traditional HTTPS because it can negotiate a secure connection with fewer network round trips. Google has shown that HTTP/2 is 23% faster on mobile networks than HTTPS.

The Advantages of a CDN

A CDN works by caching copies of your resources in data centers around the world. These are the edge servers. The edge servers usually cache content on an on-demand basis. This means that the CDN fetches data to store in an edge server from your server (the origin server) only when a nearby client requests it. If you have a relatively low-traffic site like this one, your data will probably be frequently evicted from its cache. This can introduce a bit more latency when the CDN’s edge server fetches fresh data from your origin server.

Amazon’s Route 53 service added latency-based routing in March 2012. This means you can host servers in several Amazon data centers, and Route 53 will use DNS to connect users to the server closest to them. CloudFront does something similar to connect users to the closest edge node. Amazing, right? This is the reason why it makes so much sense to host your own CDN.

Speed Comparison

Over a 30-day period, we used Pingdom to monitor latency to a CloudFront URL that served a gzipped version of our home page over HTTPS. Pingdom uses servers located all over the world to monitor uptime, and to provide latency reports. Over the same period, we served the identical page over HTTPS, letting Route 53’s latency-based routing direct load to one of our servers in Virginia, California, Singapore, or Ireland. Overall, our custom CDN is about as fast as CloudFront:

Even though there are far more CloudFront edge nodes than Instant Domain Search servers, we’re still able to place servers relatively close to the majority of our users. Route 53 will only send traffic to servers that are online. Since switching to this system, Pingdom tells us we’ve had 100.00% uptime for our home page, static content, and search interface.

When you build your own cdn network, take some time to compare your numbers like we have here and monitor them at different times on a variety of days. This will give you a clear view of how well your cdn servers are working.

Less Complexity = Faster Results

By serving everything from one domain, we can eliminate the DNS query, TCP connection, and TLS/SSL handshake made with the CDN. This network chatter adds latency to a critical part of the user’s experience: the first page load. When a user starts searching, they are still talking to the server closest to them. This eliminates the need for the JavaScript hack we’d used earlier.

It's incredible that a relatively small site like ours has access to the global infrastructure provided by AWS. We were able to build a custom CDN from the command line, something that was only available to the largest providers and at great expense when this site launched in 2005.

As you can see, there aren’t too many steps to create your own CDN server. Hopefully this post makes it a little less scary to tackle if you’ve never tried it before. But once you get a CDN domain set up and running, you’ll be glad you did.