From S3 to CloudFront: Caching for Performance
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 “resource.name.build_id” 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 *.cloudfront.net domain name. Finally, point your static domain DNS entry (i.e. t.ndimg.de) to the assigned cloudfront.net 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 cloudfront.net 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?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)