Cloudfront Caching for Performance

Creative Commons License cod_gabriel
After making the legwork to get your static resources running on S3, it’s really just a matter of throwing a few digital switches to get them into Amazon’s Cloudfront CDN. And why would you want to do this? Simple answer – performance. Amazon’s CDN has enough strategically located datacenters throughout the world to reach your audience with the least amount of lag and fewest hops.

But, there are some definite caveats with such heavy caching of your web application’s resources. Namely, how to flush these caches – or should you go the “” route? And what about SSL requests? Read on to see how I solved these challenges.

Provisioning your CDN

Log into your AWS Management Console and click on the Cloudfront tab. Then click “Create Distribution”:

Choose the S3 bucket as the origin and make sure you enter your static resource domain name in the CNAME field. This let’s Amazon know from which domain to expect incoming requests. After saving, you’ll be given a * domain name. Finally, point your static domain DNS entry (i.e. to the assigned domain. Wait until the DNS dust settles and do a couple GET requests on your resource file. You should eventually see X-Cache:Hit from cloudfront in the response header. Congratulations, you’re in the cloud!

Cache flushing and SSL considerations

As we’re not quite living in Nirvana, there are problems to consider. If you change your static resources, you’ll need to either create dynamic names at deploy time, or flush the cloud cache. As we don’t touch our static resources so often, we use boto to do the AWS heavy lifting and manually delete what’s been changed ($0.005 per item after the 1000th deletion in a month).

SSL is problematic. Looking back, I should have just stuck with our own servers to serve static SSL content (as we don’t have that many requests). Instead, I decided to be holier than the Pope and have everything served from AWS. To accomplish this, I needed to add our URL to our application configuration for SSL requests. Not pretty.

What did it bring us?

Making the pingdom check on our CSS file before migrating to AWS makes your sales pitch to management trivial. Pretty simple (and convincing) graph:

S3 and Cloudfront were my first experiences of the “Cloud” and I have to say there’s nothing fluffy or insubstantial at all about it. We’ve realized increased performance to end users and more throughput for our internal servers – all for about the cost of one additional server in our current data center. What have your experiences been?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.