Amazon just made it’s CloudFront service public and in time-honored tradition RightScale offers full support for the new service in its dashboard. You can read Jeff Barr’s announcement and Werner’s blog post for the details. I must say that the folks at AWS have been very consistent in listening to users and reacting to it: many, many users of S3, the Simple Storage Service, have been serving up web assets directly from S3 as if it were a CDN. This works reasonably well in that S3 is very scalable and can sustain very high request rates. But it also has its limitations and lack of geographic replication is one of them in the context of CDN use. So offering a true solution to getting web content rapidly to browsers across the world is most welcome.
CloudFront is a content distribution service that caches S3 content at 14 locations on three continents based on the access patterns to the individual S3 objects. As far as I can tell, it’s a service that is quite distinct from S3, except that it currently uses S3 as the origin server (i.e. the original objects to be cached must reside on S3). To use CloudFront you create what is called a distribution for an S3 bucket and it returns you a DNS name you then use to refer to the cached version of that bucket. For example, let me create a distribution for a test bucket I have laying around:
And now let’s look at the result:
As you can see, CloudFront returned the domain dc5eg4un365fp.cloudfront.net to access the bucket content. To make URLs a bit prettier to look at, I specified a CNAME of blog-demo.rightscale.com and I could now go into my DNS service and create that CNAME so I could refer to the cached content using this nicer domain name. The info also shows that CloudFront is in the process of setting up the distribution, which in this case took a couple of minutes at most. The RightScale dashboard provides access to all the CloudFront functions and shows the status of all your distributions. Plus you can give distributions nicknames and write down some notes to jog your memory later on.
As a user of CloudFront you don’t really have control over the caching, you just put links to CloudFront in your pages and it does the rest. When a browser tries to access an object it gets directed to the “best” location through the DNS lookup process. The CloudFront server it hits either returns the content from cache, or if it’s not there, it requests it from S3 and adds it to its cache. Eventually infrequently accessed content is evicted from the cache.
There are number of restrictions on CloudFront. First of all, as mentioned above, the origin server has to be S3. Second, all the objects must be publicly accessible from S3, which makes sense although in some scenarios it would be convenient if this were not required. Third, CloudFront only supports HTTP, not HTTPS, which is an issue for SSL sites because including non-SSL images brings up annoying browser warning pop-ups. Lastly, CloudFront doesn’t provide the type of detailed usage reports that other CDNs offer.
Something that is confusing at first is the pricing. The key to understanding the pricing is to think of CloudFront as a service that is completely separate from S3. Imagine it were running on your own servers that you placed in 14 datacenters around the world and you were computing what it’d cost you. When a CloudFront server first gets a request for an object it has to retrieve it from S3, which incurs the normal S3 per-request and bandwidth charges. And then there are the per-request and bandwidth charges for the CloudFront server itself every time it serves an object up to a browser. I’ll leave the details to the Amazon docs, but if you keep in mind that they’re separate services it’ll make sense.
I can’t comment much on the performance of CloudFront as I’m lacking the infrastructure (and time) to test the service. Early reports indicate that download times with CloudFront are lower than directly from S3 and show less jitter. I’m sure there will be a hot debate about whether Amazon has enough sites around the world and whether the routing from users to CloudFront is as good as it needs to be.
All summed-up, this is a service a lot of S3 users have been asking for and Amazon now delivers. It’s also a service that is difficult for cloud users to implement on their own: we really need an organization like Amazon to solve the upteen logistical nightmares it takes to deploy infrastructure around the world. Of course every time Amazon brings out a new cool service there are always more features we’d love to have and I’m sure many of them will be forthcoming. In the meantime, I’m off figuring out where we’ll use CloudFront ourselves…