Amazon CloudFront

For the past three months we’ve been beta-testing a new Amazon web service now named CloudFront. The best way to think of CloudFront is a high-performance front end for Amazon’s S3, based upon edge servers located closer to your web site’s visitors.

I’ve been favorably impressed with the new service. To try it out, I went for the low-hanging fruit by simply changing delivery of our CSS and JavaScript files to CloudFront. Performance-wise, these are our most-critical files because browsers run single-threaded while fetching and processing CSS/JS files. After the change, the download speeds of these files fluctuated between 3x and 4x faster than when delivered from our dedicated servers at The Planet in Texas. The key, in looking at the network histograms, is the all-important ‘first-byte delivery time.’ Net improvement: ~750 milliseconds for the load of any of our pages, based on measurements here, 12 miles north of San Francisco. The entire change took only about 15 minutes of effort, including creating a new S3 bucket, copying the files, modifying our code — all the changes were in one file — and establishing a new CNAME, which is optional.

Amazon calls CloudFront a “web service for content delivery,” which isn’t quite the same thing as a content-delivery network (CDN). The difference (for us) is that CloudFront doesn’t (yet?) operate as a pure cache, running off our “origin server” in the same way as we deliver our media files via Limelight Networks, a true CDN. In the case of Limelight, we just maintain the files on our own server, setup a CNAME that refers to Limelight’s edge servers and that’s it. When we add or modify a file on the origin server, that’s all we have to do. Limelight instantly (and I mean that literally) begins to deliver the new version worldwide. We don’t have to do anything manual or otherwise to keep the CDN copies of our files fresh. In the case of CloudFront, you still have to take certain actions (which could be automated, of course) to get new and updated assets from your primary servers pushed to their edge servers.

But while CloudFront may not be a pure CDN at this time, it’s extraordinarily cost-effective. It’s a no-brainer way to speed up almost any web site. For those assets like CSS, JavaScript files, frequently used images, icons, etc., the performance is as good as any CDN I’ve used but at a fraction of the cost. Pricing has two components. For assets served from U.S. edge locations:

  1. $0.170/GB data transfer out
  2. $0.010 per 1,000 GET requests

Charges are lower as volume increases, but higher for delivery from their European and Asian edge locations.

(Aside: One thing I love about all of the AWS services is that by publishing their prices so clearly, they set a very public bar against which all other providers are instantly measured. This happened with S3, and it’s going to happen with CloudFront. Pricing of storage, hosting, servers and now content delivery was previously mysterious and highly negotiable — like by an order of magnitude. AWS has brought transparency to the world of web-service pricing.)

Consider, too, that CloudFront is a completely self-service offering with no minimums, setup costs or hassles once you’re into the whole AWS world. As far as reliability, we never had a single failure or outage that I’m aware of during the entire three-month test period.

2 thoughts on “Amazon CloudFront

  1. We are looking into using CloudFront with S3 so serve our CSS, JS and image files here in Singapore. Is it recommended even if the Amazon servers are located in US and Europe?

    Thanks.

    Like

  2. For a slightly higher cost you can use the Cloudfront servers in HongKong and Japan. The only way to know is to give it a try. And since it’s so inexpensive to get started, that’s easy to do.

    Like

Leave a comment