Three Use Cases Where You Should Use Amazon CloudFront

Amazon CloudFront is likely not the most common and known service in the AWS family. Nevertheless, it proves to be a very interesting alternative to S3 or other products alike when you aim not to the storage in itself, rather to delivering content for your appliance. Indeed, CloudFront is a content delivery web service with “low latency, high data transfer speeds, and no commitments”. Despite that, I see that CloudFront is often poorly used or unused at all. So, to make clear what it is thought for and how to take advantage of it, let’s see 3 typical use cases where you should use Amazon CloudFront.

Three use cases where you should use Amazon CloudFront

Replace S3 with CloudFront when your userbase is geographically distributed

S3 is typically used to store and deliver data for your appliance. Unfortunately, this is a poor choice when the userbase is geographically distributed and you can’t focus your storage on a particular area of the world to achieve the lowest possible latency. On the other hand, CloudFront has a global network of so-called “edge locations”, which are data centers spread around the world, all replicating the content you would like to deliver to your user. Every time a resource is asked for by end users, the request is automatically routed to the nearest edge location, in order to achieve high-performance delivery of the content. In addition to that, you can even set different domain aliases for your CloudFront distribution, that is, having cdn1.mydomain.com, cdn2.mydomain.com, and so on, all pointing to the same CloudFront distribution. This allows parallel downloads and improves, even more, the performance of your appliance.

Harness the Origin Servers feature to cache dynamically generated content

When Cloud Front was launched, it was a feeder of content stored on S3 only. You put your objects on Amazon S3, CloudFront takes and caches them on the edge locations, then delivers them from there. This was quite a strong limitation for certain applications, but later on, Amazon introduced a feature called “Origin Servers” that quite changed the game.

Adding a Custom Origin Server allows CloudFront to feed content from anywhere, even from your on-premises web server, or a machine from another cloud provider. The great thing behind that is that you can deliver even automatically generated content via CloudFront, and use CloudFront to replace a custom caching solution. CloudFront allows you to tune quite finely its behavior, especially thanks to HTTP headers like Cache-Control, who control how long CloudFront should cache a given resource. Another nice feature is that CloudFront supports Etag headers.

Do you know what Etag is? They are a sort of a hash, or a digest, of the given resource. Modern browser uses them to save bandwidth. When a browser requests something that is available in browser’s cache, it will send a special If-Match header with the ETag of the resource from the cache. CloudFront will compare this ETag with ETag from his cache and will respond with HTTP 304 Not Modified without sending the resource again. Just add Etag’s to your content on CloudFront and this behavior will be automatically triggered.

CloudFront caching on steroids: Whole-Site Delivery

If we can deliver even dynamically generated content, why not taking full advantage of it and move to a Whole-Site Delivery approach? In the typical usage pattern, CloudFront act as a CDN for static content only, typically hosted either on S3 or on your Custom Origin server. Nevertheless, we have just seen how you can use it to cache dynamic content from your origin server. So, what blocks from using CloudFront as a CDN for your whole website? The key idea here is to use CloudFront as a proxy for both S3 (where your static assets are stored) and your EC2 instance, or your on-premises Custom Origin server (where dynamic content is generated).

If this seems a bite off more than you can chew, fear not: a lot of websites already use an approach like this, with a significant improvement of their performance. The idea that user-personalized pages can’t be delivered via CDNs is simply a myth. Truth is that network and path optimizations allow CloudFront to speed up dynamic content without losing a bit in customization. Setting up this architecture isn’t difficult at all, you will probably need some time to perfectly tune it, but your profits in term of performance, better scalability, improved availability, and reduced costs will go way beyond that.

Cloud Academy