RightScale Blog

Cloud Management Blog
RightScale 2015 State of the Cloud Report
Cloud Management Blog

Amazon Releases CloudFront Cloud Content Distribution Network

Amazon Releases CloudFront Cloud Content Distribution Network

cloudfront menuAmazon just made its 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.

The folks at AWS have listened to users. 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 scalable and can sustain 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 (that is, 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 lying around:

cloudfront new

And now let's look at the result:

cloudfront show

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. You can also 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, 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 supports only 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.

CloudFront pricing is confusing at first. 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 data centers 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 umpteen logistical nightmares it takes to deploy infrastructure around the world. Of course every time Amazon brings out a new service there are always more features we'd love to have, and I'm sure many will be forthcoming. In the meantime, I'm off figuring out where we'll use CloudFront ourselves.


[...] was announced on the Amazon Web Services blog, and discussed in a blog post by Amazon’s CTO. The RightScale blog has a deeper look, [...]
Michael: SSL would use significantly more processing resources than HTTP as you're alluding to. Also, it creates whole cert/key distribution fun. Plus, at that point CloudFront doesn't just have public content anymore: the cert/key need to be safeguarded carefully. Brandon: you did sign up for CloudFront at Amazon, right? E.g. on http://aws.amazon.com/cloudfront/ hit the big yellow "sign up for CloudFront" button. If that's not the issue, please email support@rightscale.com and we'll look into it for you.
[...] You can learn more about CloudFront at the AWS blog. Amazon CTO Werner Vogels has more here, as does RightScale. [...]
Hmmm I have one bucket in particular that I'd like to use with cloudfront named "cdn" (without quotes). It doesn't like that bucket and won't let me use it with CloudFront. I wonder why. Anyways, thanks for making this service available -- it's the only web based solution that works with CloudFront.
The service looks great. And it works nicely. In the morning we had a few problems because DNS data for cloudfront.net has not been distributed properly, but the problem disappeared now. A pity it does not support SSL, but this would not be in the same price range I guess.
Are you aware if you can set future expires headers on the content in CloudFront? This has pretty much become essential if you want any level of top line performance for CDN hosted content.
Posted by Lee (not verified)   Ι   November 18, 2008   Ι   12:26 AM
Lee, the answer is 'yes'. Some cut&paste from the tech docs: "An object stays in an edge location until it expires. After the object expires, CloudFront must go back to the origin server the next time that edge location needs to serve that object. By default, all objects automatically expire after 24 hours. You can specify a longer expiration time by using the Cache-Control, Pragma, or Expires header on the object in the origin server. [...] maximum values for the headers; CloudFront does not restrict their maximum values. You cannot specify a shorter expiration time (CloudFront ignores the headers if you set them to values less than 24 hours)."
[...] Amazon releases CloudFront: a cloud content distribution network: Amazon added a new service called CloudFront to its suite of Amazon Web Services (AWS). CloudFront is a Content Delivery Network (CDN) service that loads content from the Amazon Simple Storage Service (S3) and then caches the across servers on its network so that it can be loaded quickly and evenly from a large number of geographic locations. The service is very competitively priced and can be used with existing domains. [...]
Does it have something similar to ESI for splitting the HTML content in a page to several small modules that can get loaded separately?
Posted by Jay (not verified)   Ι   December 29, 2008   Ι   07:05 PM
[...] Amazon releases CloudFront 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). [...]

Post a comment