CDN redux: Rackspace v CloudFront

Back at the very end of 2008, I posted about my CDN experiences with CacheFly and Amazon’s CloudFront. A few things have changed since then.

First, Amazon added the ‘custom origin’ feature to CloudFront, so their CDN will accelerate any webserver you like, not just an S3 storage bucket. Meanwhile, they added two key features to S3 which enable you to use it to host an entire static website, not just individual files: a DirectoryIndex equivalent, so requests for directories will return the index.html file from inside that directory instead of an XML file listing or error message, and a custom error page to replace the bald text errors.

Combining the two allows you to have a static website delivered over CDN, without paying the eye-watering prices demanded by the established players, or indeed to do anything besides sign up online and pay Amazon some small change each month. Nice and simple, so as of today, this website is being delivered in exactly this way: an Amazon S3 bucket via CloudFront.

Performance overall may not quite be on Akamai’s level – yet – but I am impressed; my two (non-Amazon) colocated servers in California see ping times to the nearest CloudFront edge node of 1.0 and 1.8 milliseconds respectively, while my cable modem in Scotland is 38 ms. (For comparison, Akamai’s nearest nodes are 0.8, 8.4 and 66 ms from these three locations respectively.)

Having said that, Amazon’s geographical coverage still seems weaker, being less established: their coverage for the UK and California is very impressive – but when it comes to Australia, Africa and Latin America, the contrast is stark: Akamai have servers there, Amazon don’t.

The other development is Rackspace’s Cloud Files offering switching from Limelight Networks to Akamai for CDN services. My earlier performance comparisons had suggested Akamai should perform far better than CloudFront for downloads, so I migrated the ‘assets’ of this site (the CSS and associated images) over to a CloudFiles account.

One advantage of Rackspace’s service is support for compression. Currently, CloudFront can only serve up exactly the data you store in S3,

The major downside to the CloudFiles/Akamai service remains the restrictive namespace. With Amazon, I can serve up a file as ‘www.deadnode.org/example/page/’ though their CDN – with Rackspace, I am stuck with a hostname like ‘c379038.r38.cf2.rackcdn.com/example.txt’.

CloudFront/S3 advantages:

Akamai/CloudFiles advantages:

The last point deserves a bigger mention. With Amazon, you pay per Gb for the CloudFront traffic (15 cents per Gb for the US and Europe, 19 cents for Hong Kong/Singapoe, 20.1 cents for Japan, plus just under a cent per 10,000 HTTP requests) then pay on top of that for the traffic between S3 and CloudFront; Rackspace just charge a flat 18 cents per Gb. With very popular larger objects accessed from the US or Europe, Amazon might just come out slightly cheaper, but in general Rackspace will have the edge here.

I expect that these differences will disappear in time: Amazon are building out new edge locations for CloudFront, while one of the reasons Rackspace switched from Limelight to Akamai was to get greater flexibility.

Subscribe via FeedBurner Add to Technorati Favorites

blog comments powered by Disqus