Written by Jon Berg <jon.berg|a|turtlemeat.com>

Created: June 2011

What is Amazon Cloudfront

Amazon Cloudfront is a CDN (Content Delivery Network). The machines that deliver the content is located in countries or cities that are close to user and thus improving latency problems. It can also be thought of as web caches that are close to the user.

The site you are reading now, fragments.turtlemeat.com, uses Amazon Cloudfront.

The machines in the CDN gets a copy of the file from the website's originating server where the original copy of the html/css/javascript file is stored. When the user tries to connect to the website that uses Cloudfront it transparently connects to a machine that is close to the user and serves him the file.

What CDN can be used for

CDN are for distribution of static content. Images, CSS files, Javascript files and good old html files with nothing dynamic content in them. It should not be used for the php files that create dynamic content like forums, blogs. Even on a blog or forum there are probably a lot of static content such as images and css files that can be shifted off to another subdomain. This subdomain with static content can then be served through a CDN such as Amazon Cloudfront to improve the load time of a webpage.

The benefits of Amazon Cloudfront

1. You get less latency because of physically closer servers.
2. You get fast transfers (kilobytes per second).
3. Pay as you use and no setup fees. You pay for what you use. Fits big and small.
4. It handles traffic spikes. It is a solution that scales in the face of sudden traffic spikes.
5. It scales down. If you see long down periods of traffic you only pay for what you use. No need to pay for servers running idle.

Who needs a CDN

Static content is the easiest web content to get to scale.

If you are a big site with dedicated servers you are probably already Ok with your static content. You are able to monitor your traffic and server and scale accordingly. You just clone the static content to another server and add it to DNS. The benefit for a big site would be to have lower latency replies to the web requests. Being able to scale could perhaps be interesting, but how many machines serving static content do one need?

For small sites living under the tyranny of shared hosting all of the benefits in the list are interesting. You are basically under the mercy of the hosting company and the other users on the server. If you try to optimize your site for speed it will only make room for more customers on the server. It is great if some of your static content can load fast.

Any drawbacks?

Deployment of the site can become more complicated. Changes to static files may not be seen for 48 hours. So if you upload a modified CSS to the same filename on the server combined with redesigned html in your dynamic content. Your site may end up a mess for 48 hours. The solution is to use some kind of versioning scheme where you use a version number inside the URL. And never update content in the CDN, always upload changes with new URLs.

Setup steps for moving a host from shared hosting to Cloudfront

Here are the steps needed to move an entire subdomain over to Amazon Cloudfront. It should not take more than 40 min to complete.

Getting started is pretty straight forward. You have to jump through some hoops first. You need to have your credit card and phone ready. Amazon require that you verify yourself by calling your phone and you have you enter a code on your phone to the machine lady in the phone. After you are done you go to: https://console.aws.amazon.com/s3/home sign in, and click the CloudFront tab.

So we are going to move: myhost.hosting.com to Cloudfront. 123.0.1.1 is the shared hosting server. The original DNS setup looks something like:
A myhost.hosting.com 123.0.1.1

A few things are needed to be done on your old hosting provider first. Create a new subdomain, call it "myhost-origin.hosting.com". Copy all your files from myhost.hosting.com to myhost-origin.hosting.com. You are basically renaming the host to be able to use myhost for the Cloudfront servers.

Update DNS. add: A myhost-origin.hosting.com 123.0.1.1

Create a Cloudfront distribution. Click "Create distribution". What is needed: Delivery method=Download, Custom Orgin: Origin DNS name=myhost-origin.hosting.com, Allowed Connection=HTTP, CNAME=myhost.hosting.com
CNAME is important and it did not work without it.

Update DNS: Remove: A myhost.hosting.com 123.0.1.1, add: CNAME myhost.hosting.com yourcloudhostdomainname63467asdf.cloudfront.net
The strange looking cloudfront domain name is the name of the just created Cloudfront distribution.

Then it should be set up correctly, it may take some 15 minutes before it starts working. When you go to myhost.hosting.com you should get a Cloudfront server that fetches the content from myhost-origin.hosting.com (which is your shared hosting server).

Simple performance test of Cloudfront versus shared hosting

The site seems indeed to get better performance on Cloudfront than on shared hosting. From Norway one seems to get a server in Germany with Cloudfront. The shared hosting is in the USA east cost so it is a long distance.

Ping:

ping turtlemeat.com (shared hosting)
PING turtlemeat.com (216.17.110.18) 56(84) bytes of data.
64 bytes from 216.17.110.18: icmp_req=1 ttl=58 time=180 ms
64 bytes from 216.17.110.18: icmp_req=2 ttl=58 time=172 ms
64 bytes from 216.17.110.18: icmp_req=3 ttl=58 time=175 ms
64 bytes from 216.17.110.18: icmp_req=4 ttl=58 time=178 ms

ping fragments.turtlemeat.com (Cloudfront)
PING dk6qj2puvqfww.fra2.cloudfront.net (216.137.61.44) 56(84) bytes of data.
64 bytes from server-216-137-61-44.fra2.cloudfront.net (216.137.61.44): icmp_req=1 ttl=55 time=37.0 ms
64 bytes from server-216-137-61-44.fra2.cloudfront.net (216.137.61.44): icmp_req=2 ttl=55 time=39.1 ms
64 bytes from server-216-137-61-44.fra2.cloudfront.net (216.137.61.44): icmp_req=3 ttl=55 time=45.1 ms

Traceroute:

turtlemeat.com (Shared hosting)
 3  cm-84.208.26.10.getinternet.no (84.208.26.10)  26.516 ms  14.715 ms  12.514 ms
 4  cm-84.208.26.13.getinternet.no (84.208.26.13)  8.225 ms  7.544 ms  13.457 ms
 5  64.213.76.97 (64.213.76.97)  139.573 ms  9.195 ms  16.757 ms
 6  HIGHWINDS-NETWORK-GROUP.TenGigabitEthernet2-4.sar2.phx1.gblx.net ... 159.630 ms
 7  1-4.r2.ph.hwng.net (69.16.191.74)  168.067 ms  157.418 ms  167.905 ms
 8  209.197.4.142 (209.197.4.142)  176.617 ms  189.574 ms  179.927 ms
 9  216.17.110.18 (216.17.110.18)  192.140 ms 209.197.4.142 (209.197.4.142)  173.384 ms  176.566 ms

fragments.turtlemeat.com (Cloudfront)
 3  cm-84.208.26.10.getinternet.no (84.208.26.10)  8.869 ms  8.541 ms  18.916 ms
 4  te3-8.213.ccr01.osl01.atlas.cogentco.com (149.6.116.77)  9.009 ms  7.458 ms  20.043 ms
 5  te0-1-0-5.ccr21.ham01.atlas.cogentco.com (130.117.2.177)  25.643 ms  26.809 ms  24.240 ms
 6  te0-1-0-3.mpd21.fra03.atlas.cogentco.com (130.117.49.209)  ....  36.655 ms
 7  tiscali.fra03.atlas.cogentco.com (130.117.14.86) ...  44.342 ms
 8  xe-0-2-0.fra44.ip4.tinet.net (89.149.185.62)   ...  40.587 ms
 9  a100-gw.ip4.tinet.net (77.67.66.98)  36.207 ms a100-row.gw.ip4.tinet.net (77.67.82.50)  33.750 ms  34.232 ms
10  server-216-137-61-217.fra2.cloudfront.net (216.137.61.217)  36.126 ms  35.567 ms  37.252 ms

So one hop more with Cloudfront, but better time.

Loading a real webpage: I did "clear recent history" and clear cache on the browser. But I did mess around with this a bit so it was probably a cache hit in the Cloudfront server. I did try this several times and the numbers did not change much each time I loaded it. Shared hosting: Cloudfront: So one can see that the shared hosting sucks. Cloudfront loads everything faster. The html file first and then the large images. Shared hosting is perhaps 3 times slower in this case.
I am not sure if it is just that it is far away that is the problem. Maybe there is some bandwidth trickery on the shared host. There is probably a lot going on on the shared host. Php scripts running, Mysql and bad code. It is not something that I can control. The machine is probably loaded pretty heavy to make the most money for the hosting company. It is a bit surprising that the big images took so long to load on shared hosting. The actual transfer rate seems to be slower on shared hosting.

Great webpage load time as the next big thing

What you write on your webpage is the most important, but user experience is also very important. And the load time is a factor in user experience. Both Google Trends and Alexa have numbers for page load time. For Google it is probably also in their search engine rankings. There is no use of sending more traffic to an already overloaded site that does not care enough to fix their performance problems.
Here is a screenshot from Google Trends on this sub-domain with just some static files! This is pre-Cloudfront. Obviously there are issues here with this shared hosting.

The maximum load time of a webpage should be nothing more than 2-3 seconds. One should strive for 1 second. The expert Jakob Nielsen about: Website response times and Response time limits (that he wrote 18 years ago).

Conclusion

In short I look very favorable upon Amazon Cloudfront. It is easy to use, you pay for what you use. One should perhaps compare Amazon Cloudfront to another CDN provider and review if Amazon is the best CDN. It is perhaps wrong to compare it to shared hosting, it is a bit like comparing a Ferrari to a rusty malfunctioning bike.

For static content and a way to improve things it is great. It is great that you can use it even if you just have a small site.

Linux
Setup Software Raid 1 with LVM
Setup Linux with Desktop

Turtlmeat.com 2004-2011 ©