Amazon S3 and CloudFront limitations

Author: Andy Hartwell

I’ve been playing around with Amazon S3 (an ever-expanding hard-drive in the sky that expands as you need it), and CloudFront (a system for distributing the content you store in S3, over the Web). It’s worked well, but this morning I came across a limitation that’s worth detailing for any other techies embarking on a similar project. This won’t be über-technical, so if you’re at all interested in cloud hosting but don’t know all the ins and outs, no problem.

If you have a website or application that has a lot of images, JavaScript and CSS, you might find that the more you add, the slower your site is to load. That’s because most web servers will only serve two or three files at a time, from the same domain. So if your HTML, CSS, images and scripts are all served from the same domain, your visitors’ web servers can end up having to cue up several requests. Serving static content from another domain can help, especially if you’re hosting those static files in the Cloud.

Twitter uses Amazon’s storage for its avatar images, so that their servers don’t have to get bogged down in the repetitive task of serving the same images many, many times over. So I thought I’d give it a go on my own site – ‘cos if it breaks, no-one’s really going to be too upset – so I could bring some of the knowledge back here. And so far it’s worked pretty well.

In S3 you create “buckets” (folders at the root of your S3 account) that hold your content. I told my web server to work with one of those buckets as if it were a normal folder on that computer, so when I upload files through Django – or WordPress, or Drupal, or anything like that – the server actually sends them over to Amazon to serve them. It takes a bit longer to upload, but the benefits are greater in the longrun.

This works great for images, CSS and JavaScript, but not, it seems for web fonts.

Over the last 18 months or so we at Substrakt have played with a variety of ways to provide more than the usual set of available fonts (Arial/Helvetica, Times New Roman, Courier, and all the rest). sIFR, Cufón, and latterly – and most effectively – @font-face. Rather than a product, as such, this is a way of using legal, open fonts in a variety of formats for a variety of browsers. It’s great, because even the oldest of browsers supports it, and it doesn’t alter the page by adding SVG glyphs or inline Flash content. It’s embeddable via CSS, and completely brilliant.

The problem, however, is that since Firefox 3.5, Mozilla have stopped allowing certain requests to be passed between domains. Flash has a similar system (using a crossdomain.xml file), and it wouldn’t normally be a problem as the system that Firefox wants (a piece of information sent before the font arrives) can be provided by any web server.

However, Amazon CloudFront isn’t a standard web server, and so doesn’t allow the setting of HTTP headers that Firefox is looking for. And more unfortunately, Amazon aren’t that fussed about adding it. This means that serving fonts via their service is currently not available. A real shame, and something I’ve started to nag Amazon about.

If you’re looking to serve images, CSS and JavaScript via the Cloud to remove some of the heavy lifting from your server, I’d definitely recommend S3 and CloudFront. But if you’re looking to move towards using the @font-face technique of embedding fonts, and you also want to serve those fonts via the Cloud, for the time being, you’ll need to find another provider.